mirror of
https://github.com/EDCD/EDMarketConnector.git
synced 2025-05-24 02:47:40 +03:00
fda91df04f
* An aborted attempt was made to use a thread worker, but:
1. sqlite3 doesn't allow cross-thread use of the same sqlite3 connection.
2. Having an on-going query on one cursor, e.g. gathering all the
outstanding message `id`, whilst trying to DELETE a row hits a
"database is locked" error.
* So, back to tk `after()`. `send_message_by_id()` has been audited to ensure
its boolean return is accurate. So there shouldn't be any way in which to
get hung up on a single message *other than if the EDDN Gateway is having
issues, and thus it should be retried anyway*. Any reason for a 'bad
message' will cause `True` return and thus deletion of the message in
*this* call to `queue_check_and_send()`.
* There is a new `reschedule` parameter to `queue_check_and_send()`. If
`True` then at the end it should re-schedule.
There is a check in `journal_entry()` for the `Docked` event, and if this
occurs it will schedule `queue_check_and_send()` with `reschedule` set to
`False` so that we don't end up with multiple parallel schedulings.
It's still possible for a docking to have coincided with a scheduled run
and thus cause double-rate sending to EDDN, but we can live with that.
* The same scheduling mechanism is used, with a much smaller delay, to
process more than one queued message per run.
Hence the `have_rescheduled` bool *in* the function to indicate if a 'fast'
reschedule has already been set. This prevents the slow one *also* being
set in this scenario. The latter will be scheduled when the fast one
found no more rows to process.