Mailing-List: contact users-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cxf.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <4D7B2B15.8020806@spudsoft.co.uk>
Date: Sat, 12 Mar 2011 08:13:09 +0000
From: Jim Talbut <jtalbut@spudsoft.co.uk>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB;
 rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: "users@cxf.apache.org" <users@cxf.apache.org>
Subject: LoadDistributingConduitSelector
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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