Hi
2012/1/4 Sergey Beryozkin <[email protected]>:
> May be there's a bug in the FailoverTargetSelector's logic when the
> addresses are specified like this, I looked at the code and I'm not what is
> going on there, can you please experiment with setting this same
> (alternative) address in the strategy bean ?
Well, it looks like a bug
Since, we have multiple clients, which should retry a service, the
code looks like this:
FailoverFeature failoverFeature = new FailoverFeature();
RetryStrategy failoverStrategy = new RetryStrategy();
List<String> alternateAddress=new ArrayList<String>();
alternateAddress.add(props.getEndpointAddress());
failoverStrategy.setAlternateAddresses(alternateAddress);
failoverStrategy.setMaxNumberOfRetries(5);
failoverStrategy.setDelayBetweenRetries(2000);
failoverFeature.setStrategy(failoverStrategy);
failoverFeature.initialize(client,client.getBus());
where client is created by:
Client client = ClientProxy.getClient(port);
and port is the created by spring with <jaxws:client...>
With this setup, the situation is like before (service is invoked twice).
If an additional alternateAddress is added
alternateAddress.add(props.getEndpointAddress());
the service is invoked 3times (1 failure, 2 retries), so it looks like
that maxNumberOfRetries is ignored, and the list alternateAddresses
is iterated.
So the question remains, how to build an outFaultInterceptor which
retries (resets the chain?), since we won't/can't upgrade to a possible
patched cxf-release (or manually patch the sources)
tnx & regards
Ben
