« Return to Thread: doThreading in the connection strategy

Re: doThreading in the connection strategy

by Ross Mason-3 :: Rate this Message:

On 16 Mar 2007, at 12:26, Andrew Perepelytsya wrote:

> 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?

The problem with not using threading *sometimes* is that the [main]
thread might call the MuleManager.start() that calls start/connect on
the connector, which in turn will invoke connector on the receivers
and dispatchers. The problem here is that the main thread then gets
wrapped up waiting for a connection strategy to complete. This is
usually ok since you want all endpoints up when the starts. However,
if you don't need the endpoint to connect or you have a long running
connection strategy, the server will not start until all endpoints
have connected. Hence the option fro threading. However, we
definitely need to change the way the connect method is called since
the single recursion makes the code pretty confusing.
>
> 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.
I think you're on track but missing some of the use cases. Ultimately
we need to simplify this bit of code, but still leave the option for
threading.

Cheers,

Ross
>
> Andrew

---------------------------------------------------------------------
To unsubscribe from this list please visit:

http://xircles.codehaus.org/manage_email

« Return to Thread: doThreading in the connection strategy