On Wed February 11 2009 1:56:04 pm Dennis Kieselhorst wrote: > Hi Dan, > > thanks for the quick response. > > > Would increasing the read timeout on the client solve your problem? By > > default, I think we set it to 60 seconds but there is configuration to > > increase it (or set to -1 for no timeout). That would definitely be the > > easiest to do if it works for you. > > We already tried do increase the ReceiveTimeout on client side, but then > the remote server itself returned a timeout. New requests are handled > properly while old ones are still waiting. So the retry option is only a > workaround for a bad remote implementation. > > Moreover increasing the timeout doesn't help for other network issues, e.g. > java.net.SocketException: Connection reset. > > I opened a jira issue for it > (https://issues.apache.org/jira/browse/CXF-2036). If you give me some > hints, I will try to provide a patch for it.
This MAY already be doable today with the ConduitSelector stuff and the Failover strategy things built into the clients. They already detect IO Errors and allow touch points to select a new conduit and retry. Take a look at the code in cxf-rt-core/org.apache.cxf.clustering. Most likely, you would just need a FailoverStrategy that would always return the same Endpoint. -- Daniel Kulp [email protected] http://www.dankulp.com/blog
