search

CoinRoster / slotmachine

fruitgame
0 stars 0 forks source link

database error #31

Closed RiskingTime closed 6 years ago

RiskingTime commented 6 years ago

@Patrick-Bay I opened a new issue for this"database error". So far I've checked the usage and see no problems there

Patrick-Bay commented 6 years ago

Unfortunately there are a few additional problems here that seem to be at play. At present it looks like the server is crashing with some errors and PM2 is restarting it but without closing any open database connections.

In addition to this, the errors being thrown are from the BigNumber library which appears to have been recently updated and a number of the mathematical function names have changed. I will need an additional 2 hours on top of the hour I've spent in order to make the changes I think will be necessary to fix this issue.

Patrick-Bay commented 6 years ago

I should mention that, unfortunately, we won't be able to review additional issues until this one is fixed as it's preventing much of the data from being returned to the front end to be displayed (stats, game play, etc.)

RiskingTime commented 6 years ago

ok please proceed, keep me in the loop

Patrick-Bay commented 6 years ago

There were a number of problems involved with this issue, as noted, which involved database connectivity issues as well as out-dated code bases. All of the necessary parts have been updated and appear to be working correctly and PM2 has been disabled as a precaution. Changes are current as of commit: https://github.com/CoinRoster/slotmachine/commit/8442410453b3a5304955b8d9ebf2c0a4d140ad31

In the meantime we can start and stop the server using the old method (https://github.com/CoinRoster/slotmachine/wiki/Starting-&-Stopping-the-Game-Server), and a new global internal error handler should keep the server online if runtime errors occur. Unfortunately we will need to manually start the server if the droplet is reset so we will most likely need to revisit crash recovery.

I also made changes to keep all database transactions atomic, meaning that every request should now use a unique connection which should be closed as soon as the reply is received from the MySQL database. I haven't noted any additional connectivity problems in the MySQL log since this change was implemented so I believe that this issue is now addressed, but we should keep an eye on it nevertheless.

You can see the MySQL error log by typing the following command at the remote terminal command prompt:

cat /var/log/mysql/error.log