Bug #254

Moscore QM database server seems to lock up at times

Added by Walter Pate over 2 years ago. Updated 6 months ago.

Status:ClosedStart date:06/04/2015
Priority:ImmediateDue date:02/29/2016
Assignee:Jamie Pate% Done:

0%

Category:databaseSpent time:29.50 h
Target version:1.3.32

Description

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

History

#1 Updated by Jamie Pate almost 2 years ago

  • Description updated (diff)
  • Due date set to 02/29/2016
  • Status changed from New to In Progress
  • Priority changed from Normal to Immediate

#2 Updated by Jamie Pate almost 2 years ago

The initial plan of attack is:

  • remove the 'reload' code from tmsqm_scoresheet.addpass()
  • Add queueing code to the TTranx which 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 TTranx

#3 Updated by Jamie Pate almost 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.

#4 Updated by Jamie Pate almost 2 years ago

Some major issues with this fix:

The timer was only triggering every 1 second, which could significantly delay outgoing passings.

Added a user option to increase or decrease the evict timeout.

#5 Updated by Walter Pate almost 2 years ago

  • Status changed from Resolved to In Progress

User option added, but will the customers be able to understand how to make changes? help file need updating in the General Options section Changed status back to In Progress

#6 Updated by Jamie Pate almost 2 years ago

  • Status changed from In Progress to Resolved

Documentation is a separate issue.

#7 Updated by Walter Pate almost 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

#8 Updated by Walter Pate over 1 year ago

  • Status changed from Resolved to Feedback

awaiting customer feedback

#9 Updated by Jamie Pate over 1 year ago

  • Status changed from Feedback to Resolved

#10 Updated by Walter Pate 6 months ago

  • Status changed from Resolved to Closed

no further reports of this issue

Also available in: Atom PDF