PacketListeners may not be invoked in delivery order
Description
Due using an ExecutorService with 2 Threads, the order in which the PacketListeners are invoked is not guaranteed to be order of delivery. We should use a single threaded ExecutorService.
Environment
None
Activity
Show:
Florian Schmaus January 6, 2015 at 6:29 PM
Edited
In Smack 4.1 the behavior was fixed again by using a single threaded executor. But as soon as there was an XMPP action that waits for an incoming stanza within a PacketListener, the listener would block until the incoming stanza was processed, which would not happen because the listener blocked in the same thread that should deliver the stanza. I believe I've fixed the issue with a new design that decouples incoming stanza processing from singled threaded listener invocation I'm currently testing.
Florian Schmaus January 6, 2015 at 2:50 PM
The used scheduled thread pool constructor is wrong.
new ScheduledThreadPoolExecutor(1, factory)
means that there will be an core thread pool size of 1, but the count of threads is still unlimited, which could cause out of order invocation of packet listeners.
Due using an ExecutorService with 2 Threads, the order in which the PacketListeners are invoked is not guaranteed to be order of delivery. We should use a single threaded ExecutorService.