=== cody-somerville_ is now known as cody-somerville | ||
=== mrevell is now known as mrevell-lunch | ||
=== mrevell-lunch is now known as mrevell | ||
andrea-bs | hello, <http://fridge.ubuntu.com/event> is inaccessible | 19:14 |
---|---|---|
beuno | Rinchen, ^^ | 19:14 |
Rinchen | well, that's interesting | 19:18 |
beuno | interesting is one way of putting it, yes :) | 19:19 |
Rinchen | hmm, I just cycled all the event modules with no change | 19:20 |
Rinchen | I got a hold of newz and he's going to look at it in a few minutes | 19:22 |
Rinchen | he didn't realize it was feeding #ubuntu-meeting | 19:22 |
beuno | yes, there is a few things that depend on it | 19:22 |
Rinchen | what else that you know of? | 19:23 |
Rinchen | it looks like the rss feed is still working though | 19:23 |
beuno | many websites | 19:23 |
beuno | some calendars | 19:23 |
beuno | and there is a notification widget that was being worked on | 19:24 |
beuno | specifically for this | 19:24 |
beuno | but I'm not sure it's out in the wild yet | 19:24 |
Rinchen | they all use the rss feed though I think | 19:25 |
Rinchen | so the only real issue is that we can't add, delete, or change entries. | 19:25 |
beuno | that's right | 19:26 |
andrea-bs | Could you please put in the <pubDate> 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:33 |
newz2000 | hi Rinchen, boredandblogging. Updating to the dev version of event didn't fix it | 19:34 |
boredandblogging | hmmm | 19:34 |
newz2000 | not surprising though, the diff was very small. | 19:34 |
Rinchen | hmm | 19:34 |
newz2000 | I'm going to ask in #drupal-support unless someone else has already done this | 19:36 |
Rinchen | +1 | 19:36 |
boredandblogging | go for it | 19:36 |
Rinchen | newz2000, I don't understand why it would have changed this week | 19:36 |
newz2000 | Rinchen: yes, that's the mystery | 19:37 |
Rinchen | newz2000, I'm not aware of anything IS did | 19:37 |
newz2000 | but I'm going to bet... | 19:37 |
newz2000 | that some event was added that's messing things up | 19:37 |
newz2000 | I should look at the data first maybe | 19:37 |
boredandblogging | we just delete the last few and see if the page works again | 19:37 |
newz2000 | doesn't that mean a lot of work for just a chance? | 19:38 |
boredandblogging | its tedious, but I don't think its a lot of events | 19:38 |
newz2000 | ok, let me poke at the db first | 19:38 |
boredandblogging | ok | 19:39 |
Rinchen | wow newz2000 ...have a look at the recent log history | 19:39 |
newz2000 | 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 |
boredandblogging | yeah, the errors are caused when you pull up the calendar, theoretically | 19:40 |
boredandblogging | but newz2000 couldn't replicate it with debugging code yesterday | 19:41 |
boredandblogging | maybe wiping out the session table could clear up the duplicate error | 19:42 |
Rinchen | gmmktime() expects parameter 6 to be long, string ... | 19:42 |
newz2000 | yeah, that doesn't seem to be fatal though | 19:44 |
newz2000 | I don't think its causing this prob | 19:44 |
Rinchen | damn,...there's 100 log pages just from today due to the theme errors | 19:44 |
newz2000 | theme errors? | 19:45 |
newz2000 | but yes, the logging is made less effective by the quantity of data | 19:45 |
newz2000 | anyone know when the prob first started happening? | 19:46 |
boredandblogging | at least after march 24th, because I created the server team meetings and checked the calendar | 19:47 |
Rinchen | I did kees's entry on Monday | 19:49 |
Rinchen | I think it was Monday | 19:49 |
Rinchen | hmm my irc log sort of suggests it was last thursday | 19:50 |
newz2000 | the last two events were modified last on the 26th, which is last Wed | 19:52 |
newz2000 | there is absolutely nothing fishy looking with the events either | 19:53 |
newz2000 | would someone delete the last two events, one by one, so we can see if they affect the problem at all? | 19:55 |
boredandblogging | yeah, I'll do it | 19:55 |
boredandblogging | deleted both security meetings, doesn't help | 19:58 |
newz2000 | it hasn't affected the rss feed | 19:59 |
boredandblogging | those 2 aren't listed under upcoming events anymore | 20:00 |
newz2000 | people in drupal-support started talking about this prob before I even got a chance to mention it | 20:04 |
newz2000 | http://drupal.org/node/158043 | 20:04 |
Rinchen | I tried swizzling the caching but there was no affect. It's off and has been | 20:10 |
newz2000 | I think its probably mem related. Our server is set to 8M max. | 20:14 |
boredandblogging | maybe eventually turn on caching too? | 20:22 |
newz2000 | 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:26 |
Rinchen | the articles on drupal suggest that caching takes even more local memory | 20:28 |
Rinchen | but it might be interesting for us since 99.9% of all access to the fridge is unauthenticated | 20:29 |
boredandblogging | right, drupal stores cached pages in the db (why?) | 20:30 |
newz2000 | 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:38 |
newz2000 | but that doesn't make it use more php ram | 20:39 |
cody-somerville | Drupal is a horrible memory hog. | 20:41 |
cody-somerville | I had the same problem with my drupal website | 20:41 |
boredandblogging | 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:41 |
newz2000 | true | 20:42 |
newz2000 | 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:43 |
boredandblogging | wow | 20:44 |
boredandblogging | anytime someone mentions reporting, I cringe | 20:45 |
newz2000 | 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:48 |
newz2000 | anyway, drupal uses no ram compared to that app | 20:49 |
newz2000 | And I've seen (and written) php apps that need far more ram than 24M | 20:49 |
boredandblogging | heh, I write java, I know bloated :-P | 20:51 |
newz2000 | yeah, this program was in java too | 20:56 |
boredandblogging | hah, figures | 20:57 |
newz2000 | events works now | 23:16 |
boredandblogging | cool | 23:16 |
newz2000 | James thought that my statement about "8M being excessively low" was funny. | 23:16 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!