Bug: server/statubot starts to output missing/crippled database after some time #168
Closed
2 tasks done
Assignees
Labels
bug
Something isn't working
mumble-plugin
Affecting mumble plugin
Status Page
Affecting the status page implementation
Milestone
Comments
|
|
After callsign change: Maybe the USR data packet is not ever actively sent to new users when joining the server? |
hbeni
added
mumble-plugin
|
Reconnecting a disconnected client (mumble instance was still running all the time) yielded this: The LOC package was not registered server side. Server log did not record dropped packages |
|
Reconnect shows that the plugin justs sends
|
With a fresh restart of mumble, initial connection was established OK. |
|
The issue with the reconnecting to a already running mumble client: fgcom-mumble/client/mumble-plugin/lib/io_UDPServer.cpp Lines 688 to 692 in 8c03be7 A solution could be that the statusbot looks into its state on ping packages, and if locstate is missing, ask for data. |
🐞 The local last notified state is not cleared when the IID is collected from the garbage collector. |
hbeni
added a commit
that referenced
this issue
Jul 10, 2023
So reestablishing udp connections will transmit location data again. This is a solution to #168
|
commit 306ec32 fixes the notification bug from the plugin that occurs when the udp connection is closed, the garbage collector erased the local state and then new local state is reestablished. If the location did not change significantly (as aircraft sitting idle, or ATC client), the location information was not shared to remote clients, leading to missing data. |
|
The last testing did not trigger that issue, and work has been done to fix related problems. |
|
Tested with a replay bot and could trigger the issue again: The bot was running for some time already and spawning a new replay bot resulted not in correct output of the status bot to the db. Interestingly; the internal state of the statusbot was OK; something went wrong when generating the JSON output: Killing the statusbot and letting the botmanager spawn a fresh one was enough to fix it: |
|
So, after it ran a playback bot about the half day, we now get the following output: I already added debug code o we get a good output, but this i what the result is. |
|
Maybe we should try http://dkolf.de/src/dkjson-lua.fsl/home? Edit: Made that change in branch |
|
Looks good now wit the new json module. Merged and closed. |
|
Related problem appeared again. Sometime, the database was not written to anymore; the file had an days-old timestamp. 👀 Needs investigation/testing; but is a rare bug. A open question is, if there is some trigger that causes this behaviour? EDIT: Followup in #174 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
After a while(?), the statusbot does not output correct database anymore.
This leads to wrong presentation on the statuspage (php error output was adressed in 02da174 recently).
Namely, the displayed client has for example no callsign or no location information.
To Reproduce
unknown, but it was enough to connect to the system when the bot had run for a while.
Expected behavior
Normal display of the client (correct information replayed in the database)
Logfiles
Stored at test server instance, but producable with the
--slog ...botmanager directiveNoted causes:
=> The local last notified state is not cleared when the IID is collected from the garbage collector. When it is cleared,
we would send a new Locstat package once the first locstat is beeing received from the UDP server by the plugin. (306ec32 ✔️ )
=> (as fallback, low prio ⬇️) Statusbot needs to reask for missing state on incoming PING packages
=> JSON lua module seemed to be the cause
The text was updated successfully, but these errors were encountered: