EVE Information Portal

You missed the point ...totally....

So... is castello.is a pizza place of choice for CCP?

its not the first time that logging causes problems in distributed software projects ;)

another classic pitfall would be when you have a highly concurrent program on a single node and as soon you enable logging suddenly nothing runs concurrently anymore

Legacy code?
I'll make a prediction. The channel you used for campaign logging was used in the past for doing something else. You thought that code was removed, but some part of it still remains. When you started campaign logging, some old code woke up, tried to do something related to that channel, and "bad things" resulted.

Edit: CCP, you do not really answer one question we all kept asking over and over.

Why not roll back while you worked the issue? In the blog you stated you stated "Our test of the rollback was confirmed to work, but we still didn’t believe the code to be the issue". But, so what? Why did you let this belief stop you from doing a rollback and letting us get on the server?

I just do not see the link here. I see your thought: "we still didn’t believe the code to be the issue", and the result: No roll back, but I do not understand your reasoning for letting that thought get that result. What was your reasoning?

"I'm not a logger. I'm a pirate! Q'apla!"

When we said "Our test of the rollback was confirmed to work..." that was more referring to the fact that the rollback process would work, not that the rollback would fix the problem. So we verified that we could re-deploy the previous day's build to TQ without corrupting the game state in the DB, not that the previous day's build would manage to get past startup.

Sometimes when we deploy some new changes/feature, we have to mutute the data in the DB in some one-way fashion. Therefore such code updates cannot be rolled back in isolation without either writing an explicit revert mutation, or doing a full DB restore from backup (which can be done but takes time).

All that that comment really means is that such a code rollback would require no special DB operations to go along side it.

Pretty fascinating, thanks for the detailed explanation.

Thanks for the amusing writeup!

I totally know what its like when you run code that in theory should work but in practice doesn't. Then again, the maximum number of users waiting for my bits of programming was around 3

Windoze memory management... Could it be possible that the second call caused the server nodes to use swap space and the surge in memory requests made the harddrives go nuts?

Maybe the second call called the first one, creating 250*500*500 calls instead of 250*500 which would explain the behavior. Maybe rename a word in the second call so you can see which ones are displayed.

Or I am totally wrong and it's a MSSQL thing.

CLIFFHANGER BOYS