I've been analyzing the implications of the doThreading on the AbstractConnectionStrategy, and so far can't find a reason to have it ever set to true.
The point now being is:
- It is false by default (and that's important for the connector to reconnect properly, and not random number of times)
- AbstractMessageDispatcher forcefully sets it to false in the constructor (here's the comment):
- // We don't want to do threading in the dispatcher because we're either
// already running in a worker thread (asynchronous) or we need to
// complete the operation in a single thread
- AbstractMessageReceiver leaves it as is (false), but I guess it should be also enforcing the false.
Perhaps, the recent pooling refactoring changed the original assumptions connection strategy based on, but if we have multiple receivers/threads,
we normally would want the connection strategy to re-connect individual receivers in a controlled manner, and not schedule reconnect attempts via
the Work Manager. What is the meaning of the reconnection strategy then if they don't coordinate the timeouts/frequency and attempt count between
instances?
Sure, I might be missing something here, so please correct me if I'm wrong. I'd very much like to clarify and simplify the concept, and that might mean
confining the connection strategy to the instance it is trying to reconnect.
Andrew
