These module-level variables had historically been created such that reloading
the module wouldn't redefine the variable. However, none of our code reloads
the modules and the guard to prevent redefining the variable was broken so it
would've been redefined anyway.
Signed-off-by: James McCoy <jamessan@users.sourceforge.net>
Conflicts:
src/schedule.py
These module-level variables had historically been created such that reloading
the module wouldn't redefine the variable. However, none of our code reloads
the modules and the guard to prevent redefining the variable was broken so it
would've been redefined anyway.
Signed-off-by: James McCoy <jamessan@users.sourceforge.net>
This also fixes a long-standing failing Misc test since it was relying on the
receivedAt tag.
Signed-off-by: James McCoy <jamessan@users.sourceforge.net>
This also fixes a long-standing failing Misc test since it was relying on the
receivedAt tag.
Signed-off-by: James McCoy <jamessan@users.sourceforge.net>
All ircmsgs that takeMsg will return should be processed each time
checkIrcForMsgs is called since there may be multiple available in the
fastqueue.
Reduced the time between calls of checkIrcForMsgs so the delay between
normally queued ircmsgs stays close to the configured throttleTime.
Closes: Sf#3018148
(cherry picked from commit adc5d62bbf)
Users were occasionally hitting a situation where the socket had errored,
causing a reconnect, but the socket wasn't closed nor the driver marked as
disconnected. This resulted in run() continuing to try and use the driver,
which would cause another error, schedule another reconnect, log an error, ad
infinitum.
Closes: Sf#2965530
Signed-off-by: James Vega <jamessan@users.sourceforge.net>
(cherry picked from commit a278d17f2b)
All ircmsgs that takeMsg will return should be processed each time
checkIrcForMsgs is called since there may be multiple available in the
fastqueue.
Reduced the time between calls of checkIrcForMsgs so the delay between
normally queued ircmsgs stays close to the configured throttleTime.
Closes: Sf#3018148
Users were occasionally hitting a situation where the socket had errored,
causing a reconnect, but the socket wasn't closed nor the driver marked as
disconnected. This resulted in run() continuing to try and use the driver,
which would cause another error, schedule another reconnect, log an error, ad
infinitum.
Closes: Sf#2965530
Signed-off-by: James Vega <jamessan@users.sourceforge.net>
