Re: doThreading in the connection strategy

Ok, this is pretty much in line with my findings. Currently, it works the way you mentioned, except for doThreading=true the count will be less than configured and can be unpredictable (thread scheduling).

Just for the archive record - doThreading=false will eventually terminate the Mule manager (main thread), while doThreading=true will fail and stay in a zombie uninitialized state.

A wild idea I had (though not necessarily useless) is to have distinctive connector, receiver and dispatcher connection strategies in the future, which gives us much more control of the process. E.g. dispatcher's connection strategy may retry silently a couple of times, but only if within a transaction timeout limit (if TX is present). Would such a split make sense?

Andrew

On 3/19/07, Ross Mason <themuleman@...> wrote:

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