doThreading in the connection strategy

[Andrew Perepelytsya]

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:

1. It is false by default (and that's important for the connector to reconnect properly, and not random number of times)
2. AbstractMessageDispatcher forcefully sets it to false in the constructor (here's the comment):
1. // 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
3. 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

[Ross Mason-3]

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

[Andrew Perepelytsya]

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

[Ross Mason-3]

On 19 Mar 2007, at 06:40, Andrew Perepelytsya wrote:

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.

That zombie thread is created from the the UMOManager so *really* that thread should be destroyed when the manager is disposed. Is this not happening

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?

I agree this makes sense: http://mule.mulesource.org/jira/browse/MULE-1285.

For this to work we probably do need to define Connection strategies on the endpoints (receiver/dispatcher) but also on the connector itself since sometimes the connector also needs to connect to an underlying resource. So it does make sense to have connection strategies on the the connector AND endpoints.

Ultimately we need to remove the recursion craziness with the current implementation and cleanly separate the connection on the connector and endpoints -

- to allow easier debugging

- Enable different strategies for differnet endpoints/protocols

Holger suggested that 'doThreading' should be replaced with 'asynchronous' which I think makes sense.

The current state of connection strategies is pretty good thanks to Andrew's changes and there are only a couple f fringe cases still failing. We should hold off any architecture changes on this stuff until we can all sit in front of a whiteboard next week.

Cheers,

Ross

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