#musicbrainz-devel

I get a stack trace on test.mb.org when I include the ratings parameter in /ws/2/release: http://paste.pocoo.org/show/452960/

ruaok: ping

pong

moin

%T!

Today I ar been kipping at a cheap hotel near work, and hence am in the office waaaaaaaay too early.

Anyway,

re gzipping, it's now enabled on test.mb

kipping?

sleep

ah.

sweet!

Yesterday I was at my desk, working, by 0715

O_o

what behooved this move?

And considering I /normally/ have a 1h45m journey to get to work, that's unusual :-)

The hotel? http://gbbf.camra.org.uk/home

ah yes.

the true motivator: beer.

So, anyway, gzip: the gzipping should now be enabled for test.musicbrainz.org, only for content >1100 bytes long, and only for text/html and application/xml

just a proxy setting, no?

I'm guessing we want to bed that in for a bit to see if it causes any problems.

front end nginx, yes

kewl.

I'll task voice with that. :)

I think what was being compressed before was only local html content, i.e. not proxied. Which is basically nothing.

I was wondering where the large drop in bandwidth went.

it should have a significant impact on our bandwidth.

so, this will be nice to see. that gives us spare bandwidth. :)

Sounds good. I like graphs that do that. :-)

srsly.

I'll just wait for the nod to apply it to more/all sites

perfect.

and when we cut it over, we can also do it for a limited time and see how things go.

sure

yay, fresh eyes.

meh, what an unproductive day so far

no progress on the 502s, and 2 hours spent spinning wheels on the (rare) unicode problems

:(

Hi guys.. awfully quit here today ...

I think I might have my Search server index builder running in an infinite loop or similar ?

pecastro: indexing does take a while .

warp: I know... But I could swear that last time I ran it on this box it took ~1h30m ... What's puzzling me is this..

Index Builder Finished:13:42:22

I don't remember how long it takes on my desktop at home. 1h 30m could be right.

pecastro: and it's stuck now? doesn't display anything more but also hasn't quit?

...and from what I see from IndexBuilder.java that's should be the last println in main after es.shutdown() ?

warp: stuck, with the process consuming half of the CPU ... though not generating any perceivable load in the machine.. :|

pecastro: odd. I don't know much about the search server, perhaps best to ask ijabz about it.

warp: I have time.. I'm going to kick it again and see what happens... I'll nudge ijabz l8rs. Tkx.

yikes. git diff master...HEAD created a horrible diff just now.

rebase that branch onto master

that'll probably solve it

or diff from the correct branch instead of next >_<

lol

could not obtain lock.

ruaok: did you read the email?

I think that's the cause of our 502s

heh. I just read the email that said you had no clues on 502s. :)

see timestamps :)

they seem to go together though

modbot problems with row locking, 502s all touch the database for transactions

it points to our database connections being problematic

who is doing the locking causing modbot to fail?

and why are we blocking the edit table in the first place?

we don't lock the edit table

scrap that

we lock rows of the edit table*

getting source link now

i've seen this before and I can't remember exactly what I did

djce has some query to show open locks

select pg_class.relname,pg_locks.* from pg_class,pg_locks where pg_class.relfilenode=pg_locks.relation;

Doesn't show anything very interesting though, I wonder if the cover art script could be responsible for it?

but I can't see how...

that wouldn't really explain why /work/create would fail

have you stopped that illustrious script to find out?

not that it seems to be doing any good. :)

well it's changed now

improved? changed how?

the order for finding releases to update has changed

since when?

Wed, 3 Aug 2011 11:25:18 +0000 (12:25 +0100)

and we you deployed it?

i'm checking the ticket now to see what's happened

-we

sort of

we/you

sort of?

I updated the code on astro, and started the loop

you don't have to restart the server for it

i can only type so fast!

:)

that coincinces with when the 502s started.

lets do this: turn off the script.

go back to 30 second timeouts

watch the logs

script stopped

we do however still have code that doesn't match exactly what is actually running

it may be worth restarting astro and pingu too

we need to restart both servers for the timeout change.

ah, that works nicely then

yes.

in that case

let me update them to have the reduced-warnings-code too

sweet

(already pushed, but not deployed)

oh man. quiet(er) logs.

hott

lol

oddly, pingu seems to get a lot more traffic than astro too

anyway, ready on astro when you are

well, I say traffic. pingu's log is noiser

astro is out

next time we should take out pingu first and see if astro is as sluggish afterwards

ok, astro done

heh. now its just loads of *one* warning.

it is? I don't see that here