Moscore QM database server seems to lock up at times
|Assignee:||Jamie Pate||% Done:|
|Category:||database||Spent time:||29.50 h|
During large races it appears that the database gets too busy and locks up. My hunch is that this is caused by poor network setup and
tmsqm_scoresheet.addpass() which currently checks for out of order passings supplied by the decoder, and initiates a reload of the entire race from the database if this happens. Certain conditions may cause the decoder to return out of order passings multiple times a second, which may cause the system to appear to lock up.
The customers are reporting it but we don't have an adequate easy method for them to capture the error and report all the necessary data to us. We need to create an easy one button report system that the customer can use and send us the one file that gives us the necessary data for easy data analysis Separate issue #272
#2 Updated by Jamie Pate about 2 years ago
The initial plan of attack is:
- remove the 'reload' code from tmsqm_scoresheet.addpass()
- Add queueing code to the
TTranxwhich would buffer passings for a short time during passing clusters to guarantee in-order data is received by the scoresheet component.
- Add unit tests to test the correct operation of
#3 Updated by Jamie Pate about 2 years ago
- Status changed from In Progress to Resolved
http://moscore.com/d3tspdata/?dbname=lqma2015&raceid=9313&status=green <- i used this race to confirm, it has 7 out of order passings during the green flag. You can use that tool to try to find races that have a high occurrence of out of order passings in other databases as well.
#7 Updated by Walter Pate about 2 years ago
If changes are made which require specific settings, Instructions should be included with the changes at the time of first release, otherwise customers who are trying to troubleshoot an issue will be working blind on setting changes there should be documentation on the changes