BuzzerBeater Forums

Sometimes it works, sometimes it doesn't, so the lock or block reappears after a certain unpredictable period.

To be fair, it's pretty easy to predict when it will reappear. Every single week..

Are you kiding??? You do like this???? No testing environment? ALL UPDATES MUST BE TESTED IN NON PRODUCTIVE VERSION. YOU DIDn't know it???

Now I know, why all this bugs and delay cames.. you go blind in the dark and want to find a needle. "nice", dear Marin, Nice :D

I am a professional developer and deadlock (what Marin is describing) is normally a very difficult problem to deal with. Every time I have experienced it in the past, it is something that occurs only in production because it is impossible to recreate the same usage in the testing environment as what happens in the production environment. The root cause of deadlock is contention over the same resource (i.e. two components trying to use/update the same piece of data at the same time). Production has hundreds of people using it at the same time, and test does not and never will. Since you cannot recreate the problem in test, the only way you know if any attempt you made to fix the symptoms succeeds is to try a fix in production and see if the symptoms go away.

So while you joke about him being blind in the dark, he is trying to fix a problem that is difficult to recreate in a test environment without knowing the root cause and that he can't study in the one environment it fails in (production) because he needs to fix immediately. The hardest part of fixing a deadlock issue is finding the root cause, until that is identified any developer would be blind in the dark.

I didn’t understand a single word, but gave me an idea of how difficult the problem may be. It’s very easy being on the judging side and just saying how bad they do their work but I bet all these smartass couldn’t stand a day in B.B.’s shoes

Thanks.

The main problem i have is not the deadlock itself (can happen, difficult to fix, fine) but the frequency of such deadlocks in BB is increasing (training every week now, standings update this week just to name a few examples) all the while the total number of users is DECREASING, puttling less strain on the servers as say 5 years ago.

Well said! Cant agree more. Talking about stuff that includes numbers of users is one, but when numbers drop and we get more problems, it must be something more :)

@Vaidas: We have a testing environment but it is not usable in cases of implementation of optimization. It's basically what Rufus Rugi said: the problem is that the testing environment doesn't have the user input load, as well as other things that only run on the live site. Yes, we can test only if something works without breaking when run for the first time, but we cannot test properly if it will have a positive effect on execution times.

@Evaristo: We can't do this as Sakiz105 already noted, because we'd have to give access to our proprietary code to strangers without having a non disclosure agreement signed. There's also an issue of trust that we have to have that the person with access won't unintentionally or intentionally do a lot of harm. Also, problems on systems like these require people to examine the whole codebase, which can take weeks, and I doubt even the most benevolent coders are prepared to work that long for free.

@EGM-Manon: Sorry for reopening the thread, I just wanted to add my last word.