Affects Version/s: 0.3.1
Fix Version/s: None
The git history seems to claim that a scheduled action is supposed to be executed only after all earlier scheduled actions have been executed. The current implementation does not ensure this however. Note that multiple threads calling runScheduledAction can pull actions almost simultaneously from the channel and interleave their execution in any order.
Possible fixes are:
(1) Have a dedicated thread per remote endpoint (heavy-weight connection) executing scheduled actions.
(2) Have a runScheduledAction read an action from the channel and execute it atomically.
What is the need to execute actions in the order they are queued? The git comment is not clear about that. It says:
But the n-t interface does not ask to ensure ordering if messages are submitted concurrently.
The only problem I see is that sending messages could be attempted on a closed socket if they are submitted concurrently with a connection close call.