=== cody-somerville_ is now known as cody-somerville === mrevell is now known as mrevell-lunch === mrevell-lunch is now known as mrevell [19:14] hello, is inaccessible [19:14] Rinchen, ^^ [19:18] well, that's interesting [19:19] interesting is one way of putting it, yes :) [19:20] hmm, I just cycled all the event modules with no change [19:22] I got a hold of newz and he's going to look at it in a few minutes [19:22] he didn't realize it was feeding #ubuntu-meeting [19:22] yes, there is a few things that depend on it [19:23] what else that you know of? [19:23] it looks like the rss feed is still working though [19:23] many websites [19:23] some calendars [19:24] and there is a notification widget that was being worked on [19:24] specifically for this [19:24] but I'm not sure it's out in the wild yet [19:25] they all use the rss feed though I think [19:25] so the only real issue is that we can't add, delete, or change entries. [19:26] that's right [19:33] Could you please put in the field of the Fridge Events Feed the datetime the event will be held? This helps me ordering the items with my feed aggregator and I think would be useful for other users too [19:34] hi Rinchen, boredandblogging. Updating to the dev version of event didn't fix it [19:34] hmmm [19:34] not surprising though, the diff was very small. [19:34] hmm [19:36] I'm going to ask in #drupal-support unless someone else has already done this [19:36] +1 [19:36] go for it [19:36] newz2000, I don't understand why it would have changed this week [19:37] Rinchen: yes, that's the mystery [19:37] newz2000, I'm not aware of anything IS did [19:37] but I'm going to bet... [19:37] that some event was added that's messing things up [19:37] I should look at the data first maybe [19:37] we just delete the last few and see if the page works again [19:38] doesn't that mean a lot of work for just a chance? [19:38] its tedious, but I don't think its a lot of events [19:38] ok, let me poke at the db first [19:39] ok [19:39] wow newz2000 ...have a look at the recent log history [19:40] what do developers feel compelled to come up with creative ways to store dates when the databse has a perfectly useable datetime field? [19:40] yeah, the errors are caused when you pull up the calendar, theoretically [19:41] but newz2000 couldn't replicate it with debugging code yesterday [19:42] maybe wiping out the session table could clear up the duplicate error [19:42] gmmktime() expects parameter 6 to be long, string ... [19:44] yeah, that doesn't seem to be fatal though [19:44] I don't think its causing this prob [19:44] damn,...there's 100 log pages just from today due to the theme errors [19:45] theme errors? [19:45] but yes, the logging is made less effective by the quantity of data [19:46] anyone know when the prob first started happening? [19:47] at least after march 24th, because I created the server team meetings and checked the calendar [19:49] I did kees's entry on Monday [19:49] I think it was Monday [19:50] hmm my irc log sort of suggests it was last thursday [19:52] the last two events were modified last on the 26th, which is last Wed [19:53] there is absolutely nothing fishy looking with the events either [19:55] would someone delete the last two events, one by one, so we can see if they affect the problem at all? [19:55] yeah, I'll do it [19:58] deleted both security meetings, doesn't help [19:59] it hasn't affected the rss feed [20:00] those 2 aren't listed under upcoming events anymore [20:04] people in drupal-support started talking about this prob before I even got a chance to mention it [20:04] http://drupal.org/node/158043 [20:10] I tried swizzling the caching but there was no affect. It's off and has been [20:14] I think its probably mem related. Our server is set to 8M max. [20:22] maybe eventually turn on caching too? [20:26] I've never felt that fridge was slow, and caching seems to be more hassle than its worth. But maybe I'm wrong and performance is lacking. [20:28] the articles on drupal suggest that caching takes even more local memory [20:29] but it might be interesting for us since 99.9% of all access to the fridge is unauthenticated [20:30] right, drupal stores cached pages in the db (why?) [20:38] I suspect it puts them in the database because its easier... since drupal doesn't have to worry about fs permissiosn when writing files [20:39] but that doesn't make it use more php ram [20:41] Drupal is a horrible memory hog. [20:41] I had the same problem with my drupal website [20:41] it might, after drupal pulls out of the cache from the db, it probably sits in php ram for a bit before its gets served up [20:42] true [20:43] My prev employer's web application software used XSL for the page generation. A typical page view used over 800M of RAM and some of our reports used over 1200M of RAM. per pageview! ;-) [20:44] wow [20:45] anytime someone mentions reporting, I cringe [20:48] My job was to make sure payroll reports worked right for our customers. It was a pain and for some reason the only time we had problems was on payday 45m before the payroll *had* to be done. [20:49] anyway, drupal uses no ram compared to that app [20:49] And I've seen (and written) php apps that need far more ram than 24M [20:51] heh, I write java, I know bloated :-P [20:56] yeah, this program was in java too [20:57] hah, figures [23:16] events works now [23:16] cool [23:16] James thought that my statement about "8M being excessively low" was funny.