#musicbrainz-devel

LOL

hehe

painful

was there cover art on that site? We could link some into musicbrainz ;)

why is it painful?

the entire concept of the cd index was painful.

I'm giving a talk about OSS/MB at Cal Poly on thu.

from my notes:

" When Slashdot asked what the replacement for CDDB was, I finished a rough version of the index and it was slashdotted. It tipped over and failed."

"- A craptastic community evolved from the screaming bitches that streamed in from Slashdot."

a slashdot borne community is *not* what you want. :)

ruaok: problem on test is back

which one. :)

postgresql is eating 100% cpu

Caught exception in MusicBrainz::Server::Controller::Root->begin "DBD::Pg::st fetchrow_array failed: no statement executing at /home/musicbrainz/perl5/lib/perl5/Catalyst/Plugin/Session/Store/DBI.pm line 32."

it's the one ollie wanted to look at, wasn't it?

but I bet he's not here now :P

this is a new one. postgres has not previously taken 100%.

oh

it's the same error message at least

yeah.

that we should leave to ocharles.

let me see what pg is doing though.

thats the newfangled empty artists query running.

uhm. ya. that query needs to be split up into something more sane.

its only been going a measley 15 hours. should finish any moment now.

whoa

processor hours. probably has been running longer in wallclock time

nikki: will you alert ocharles to the session issue when he rises?

yes

thx

arise my son!

oh, ruaok

?

do you happen to know any bandcamp people?

I asked vxjasonxv about the bandcamp cover art stuff, and he said he's not had a response from them :/

I don't, but I suspect I can dig some up.

or rather, he sent a few emails and got replies, but the latest one he asked for permission for us to link to them and got no response

can you have him forward the email he sent? I'll see if I can find a way through.

sure

k.

nn

not my query -_-'

ocharles_: I'm getting that error again about sessions

ooo

juicy fresh server explosions

i'll just get breakfast and prod it

hehe

hrm, test looks weird. it's meant to have 3 db connections open per process, but has 1 session, 2 raw data, and 5 readwrite

I think I might just switch to Memcached and see how that behaves

still pretty stumped, I've switch to memcached back stores for now

lets see how that goes

ok

oooooooooops

closed my eyes for a bit more than 10 minutes :)

oh good, now I can't login at all

warp: http://search.cpan.org/~gshank/HTML-FormHandler...

ocharles_: ah

ocharles_: is it any good? :)

no idea! gshank mentioned it last time I was moaning about something not working, but I never looked at the tests

it looks similar to how our wizard works

we're too close to release for it to be useful now

but it could be interesting to port things over to it once he considers it more stable

yea, pretty much what I was thinking

hi nikki

is http://codereview.musicbrainz.org/r/1083/diff/3... supposed to be 7 pages? o_O

ha, no

moin!

moin moin ruaok

fixed, thanks nikki

ocharles: I wasn't trying to bust your chops on MBS-1557. I was just trying to figure out why hobbes was running old code.

sorry about, that. :(

no problem :)

where were you running it from?

~musicbrainz/musicbrainz-server should have next on

it was running on hobbes. from cron

thats why I was confused.

but the only thing that could've happened is that the cron job ran, then the code was updated and some hours later I came and killed it

yea, that's a possibility

i cat'ed it earlier though and it looks right now

re db backed sessions, I'm not having much luck

have you run that script by hand on hobbes?

nope, only locally

not much luck in which way?

i couldn't work out what was happening. looking at the logs the fastcgi processes were dying and restarting

I saw that it died again last night. in a very particular and worrysome way,

and when I checked ps only 1 session db connection was open, 2 raw data, and 5 readwrite were open it

should be 5 of each

do you know which module might be at fault?

Well, I can only imagine it's Session::Store::DBI, but when I asked in #catalyst I didn't get much of a response

I may try the ML

please do.

I tried Memcached sessions in the meantime, and that also seems to be useless

this would be an excellent thing to have working.

ocharles_: hm... I don't understand the change you made for the youtube urls, it doesn't seem to do anything different

after a few hours sessions immediately expired

lame.

nikki: yea, I've just noticed I forgot the ?

bah.

what's the point of having it there if it's optional?

and you didn't update the other youtube regex

eww, duplication

time to fix that so I don't make that mistake again

ruaok: so options are to keep trying to figure out why dbi backed sessions aren't working, look into writing our own session store driver, or look at using memcached/redis/something else

memcached is nice but the moment it runs out of space it starts expiring sessions

redis could be a good middleground

but it's more server software to run

my order of preferences:

1. debug the DBI session store.

2. tinker with memcached.

3. seek something else.

for #2, we could run a separate instance in memcached that did nothing but sessions and was tuned for that.

that would be easy to try too.

that could work

just run another copy on another port and turn it to what you need.

thats easy to try.

yea

s/turn/tune

hrm, I think I know why memcached was failing... turns out the default expiry time is 0

no, no it isn't, it's 86400. hrm.

it could be full.

how much ram is allocated to it?

i think it may well be that problem

no idea, I haven't configured it at all

memcached will give you all sorts of stats.

it's set to use 64mb atm