If the paddlemgr (paddle manager) process is interrupted, by exiting and then being restored via the client_supervisor, say, the paddle, stop and trip information is reset to zero.
This has the effect of having fares show up in the billing_log with 0 entries for driver, paddle, stop and trip.
The new state_info system has stored state that is loaded by any process that needs it with writing being funneled through the client_supervisor process only to minimize race conditions.
The driver, paddle, trip and stop information can be loaded by the paddlemgr process on start (and HUP?) but this state might need to be communicated to the other processes.
priority
high
estimate
3 work units
If the `paddlemgr` (paddle manager) process is interrupted, by exiting and then being restored via the `client_supervisor`, say, the paddle, stop and trip information is reset to zero.
This has the effect of having fares show up in the `billing_log` with 0 entries for driver, paddle, stop and trip.
The new `state_info` system has stored state that is loaded by any process that needs it with writing being funneled through the `client_supervisor` process only to minimize race conditions.
The driver, paddle, trip and stop information can be loaded by the `paddlemgr` process on start (and HUP?) but this state might need to be communicated to the other processes.
| | |
|---|---|
| priority | high |
| estimate | 3 work units |
In paddlemgr.c, there is a send_status_update() function.
One possibility is to load the state information on start, then proceed
to do a send_status_update() once the line to the IPC server has been established.
My only hesitation is that if this then triggers some other paddle, trip or stop update, this could get into an infinite ping pong of messages.
In `paddlemgr.c`, there is a `send_status_update()` function.
One possibility is to load the state information on start, then proceed
to do a `send_status_update()` once the line to the IPC server has been established.
My only hesitation is that if this then triggers some other paddle, trip or stop update, this could get into an infinite ping pong of messages.
If the
paddlemgr(paddle manager) process is interrupted, by exiting and then being restored via theclient_supervisor, say, the paddle, stop and trip information is reset to zero.This has the effect of having fares show up in the
billing_logwith 0 entries for driver, paddle, stop and trip.The new
state_infosystem has stored state that is loaded by any process that needs it with writing being funneled through theclient_supervisorprocess only to minimize race conditions. The driver, paddle, trip and stop information can be loaded by thepaddlemgrprocess on start (and HUP?) but this state might need to be communicated to the other processes.In
paddlemgr.c, there is asend_status_update()function. One possibility is to load the state information on start, then proceed to do asend_status_update()once the line to the IPC server has been established.My only hesitation is that if this then triggers some other paddle, trip or stop update, this could get into an infinite ping pong of messages.