mersenneforum.org - View Single Post

Peter Nelson · 2005-02-17, 18:05

Thanks sdbardwick for pointing out the other thread where others had the same problem.

I did have a look around before posting but didn't spot it.

With hindsight I probably ought to have posted under the server topic rather than software. (About the server being down).

I'm pleased to report the server appears to be back now. A manual communication with the same exponent that gave error 3 now completes without the error 3 so things seem to be healthy as normal.

So whatever server downtime or SQL offline-ness was going on, that is resolved.

However, I maintain that there is an ongoing SOFTWARE issue. That is that when certain processes/parts of the backend are down, the software parts that remain up behave unpredictably/incorrectly.

There may be other effects, but certainly the "ERROR 3" to the client is an out of order response.

If the assignment data cannot be obtained, it ought to produce a message along the lines of ERROR11213: Cannot currently ascertain whether that exponent was assigned to you or not.

This ought to be clearly distinguishable from a conventional error 3: YOU POACHED THAT EXPONENT. OR someone poached it from you an reported the result before you did.

People may get error 3 for other reasons because of bugs in / problems with the server. These may be easier to debug if the backend could detect a failed lookup and report accordingly rather than report "it wasn't assigned to you". Just requires a little error trapping code. Obviously when it was written originally the database was assumed to be always there/accessible but in the real world life is not so simple.

So, with even more hindsight, SOFTWARE was the right forum topic!

Enhancement / bugfix request for primenet server 5.0:
Add some detection code for the scenario the sql backend is offline to supress the misleading error 3 response to clients and replace with some intelligent message. Error 3 should only be generated for situations when it truly applies.

Thanks!

2005-02-17, 18:05	#3
Peter Nelson Oct 2004 1000010001₂ Posts	Server is back now but same software Thanks sdbardwick for pointing out the other thread where others had the same problem. I did have a look around before posting but didn't spot it. With hindsight I probably ought to have posted under the server topic rather than software. (About the server being down). I'm pleased to report the server appears to be back now. A manual communication with the same exponent that gave error 3 now completes without the error 3 so things seem to be healthy as normal. So whatever server downtime or SQL offline-ness was going on, that is resolved. However, I maintain that there is an ongoing SOFTWARE issue. That is that when certain processes/parts of the backend are down, the software parts that remain up behave unpredictably/incorrectly. There may be other effects, but certainly the "ERROR 3" to the client is an out of order response. If the assignment data cannot be obtained, it ought to produce a message along the lines of ERROR11213: Cannot currently ascertain whether that exponent was assigned to you or not. This ought to be clearly distinguishable from a conventional error 3: YOU POACHED THAT EXPONENT. OR someone poached it from you an reported the result before you did. People may get error 3 for other reasons because of bugs in / problems with the server. These may be easier to debug if the backend could detect a failed lookup and report accordingly rather than report "it wasn't assigned to you". Just requires a little error trapping code. Obviously when it was written originally the database was assumed to be always there/accessible but in the real world life is not so simple. So, with even more hindsight, SOFTWARE was the right forum topic! Enhancement / bugfix request for primenet server 5.0: Add some detection code for the scenario the sql backend is offline to supress the misleading error 3 response to clients and replace with some intelligent message. Error 3 should only be generated for situations when it truly applies. Thanks!