LoadDistributingConduitSelector

[Jim Talbut <jt...@spudsoft.co.uk>]

Hi,

I've written a LoadDistributingConduitSelector, based on the 
FailoverTargetSelector.

Would you like me to convert it to a Feature and submit it as part of CXF?


It doesn't subclass FailoverTargetSelector because it needs access to 
the private InvocationContext stuff, but it could replace the 
FailoverTargetSelector because distribution across addresses is optional 
and by default is off.
Or, if I'm making it part of CXF I could change the appropriate bits of 
FailoverTargetSelector to protected.

When distribution is turned on it asks the FailoverStrategy for the list 
of alternate addresses in selectConduit.
It first tries calling getAlternateAddresses( null ) in order to set up 
a list of alternate addresses that will work across any exchange (and 
that is thus remembered until it runs out of addresses) - if the 
FailoverStrategy can't cope with returning alternate addresses for a 
null Exchange the LoadDistributingConduitSelector will call 
getAlternateAddresses(exchange) but obviously can't remember the result 
- which means that if the FailoverStrategy returns the same result from 
selectAlternateAddress there will be no load distribution.
All the FailoverStrategy classes that I can find handle 
getAlternateAddresses( null ).

It is no more or less thread safe than the FailoverTargetSelector.

I haven't yet tested it with multiple endpoints, just multiple addresses.

Jim

Re: LoadDistributingConduitSelector

[Jim Talbut <jt...@spudsoft.co.uk>]

On 14/03/2011 19:44, Daniel Kulp wrote:
> Sounds great!  We'd love the contribitution.

Path submitted to https://issues.apache.org/jira/browse/CXF-3424.

It can work with multiple endpoints but places more demands on the 
strategy in order to do so because endpoints are always obtained based 
upon the exchange.
It's much better with multiple addresses.

I didn't modify ReflectionServiceFactoryBean - I just made my feature 
derive from FailoverFeature.
That whole requirement (for different behaviour there) makes me uneasy, 
so I'll just be using it with multiple addresses.

Jim

Re: LoadDistributingConduitSelector

[Daniel Kulp <dk...@apache.org>]

On Saturday 12 March 2011 3:13:09 AM Jim Talbut wrote:
> Hi,
> 
> I've written a LoadDistributingConduitSelector, based on the
> FailoverTargetSelector.
> 
> Would you like me to convert it to a Feature and submit it as part of CXF?

Sure.  That would be great.  :-)

> It doesn't subclass FailoverTargetSelector because it needs access to
> the private InvocationContext stuff, but it could replace the
> FailoverTargetSelector because distribution across addresses is optional
> and by default is off.
> Or, if I'm making it part of CXF I could change the appropriate bits of
> FailoverTargetSelector to protected.

That's probably the preferred way of doing it if it's going into CXF.  In 
general, I prefer making existing classes more subclassible and extensible if 
possible.

> When distribution is turned on it asks the FailoverStrategy for the list
> of alternate addresses in selectConduit.
> It first tries calling getAlternateAddresses( null ) in order to set up
> a list of alternate addresses that will work across any exchange (and
> that is thus remembered until it runs out of addresses) - if the
> FailoverStrategy can't cope with returning alternate addresses for a
> null Exchange the LoadDistributingConduitSelector will call
> getAlternateAddresses(exchange) but obviously can't remember the result
> - which means that if the FailoverStrategy returns the same result from
> selectAlternateAddress there will be no load distribution.
> All the FailoverStrategy classes that I can find handle
> getAlternateAddresses( null ).
> 
> It is no more or less thread safe than the FailoverTargetSelector.
> 
> I haven't yet tested it with multiple endpoints, just multiple addresses.

Sounds great!  We'd love the contribitution.

-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com