cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: Handling connection problems in WS-RM
Date Wed, 23 Feb 2011 15:47:15 GMT
On Wednesday 23 February 2011 5:11:27 AM Dennis Sosnoski wrote:
> When WS-RM is in use, some types of intermittent problems need to be
> handled by the WS-RM code without any impact on the application. These
> include all types of connection problems (after the initial WS-RM
> connection which establishes a Sequence), both where there's an actual
> I/O error in making a connection or getting a response, and where an
> incomplete message is received.
> One way of handling connection problems would be to use special handling
> in the transports, to catch and basically ignore exceptions when WS-RM
> is engaged. That's messy, with a lot of special case code. It seems like
> a simpler alternative would be to just always decouple the WS-RM send
> from the client request processing (or server response processing),
> basically treating everything as though it were a retransmission. That
> way the retransmit logic can just ignore any exceptions and continue on
> its way. Does that make sense?


> Handling incomplete receive messages looks more involved. There are many
> places in the code where XMLStreamException is caught and converted into
> a Fault. I suppose I'd need to intercept the Fault handling and look at
> whether the Fault was internally generated or received from the other
> endpoint, and only pass those received from the other endpoint on to the
> application. Is there any easy way I can tell?

On the server side, when the fault is thrown, the "type" of the Fault is 
recorded on the message.   See:
That allows us to figure out the right way to handle things.   

We probably should do something similar on the Client side.   If the exception 
is thrown from the ClientFaultConverter or Soap1?FaultInInterceptor's, it 
should probably set a FaultMode on the message that reflects that it came from 
the other side of the wire.    That would keep it consistent on client and 
server side...

Actually, looking at ClientFaultConverter, it seems to already be done.   If 
would be from the other side (and would depend on if it's wsdl defined or 
not).   If it's not one of those or is unset, it would be a local generated 

Does that help?

Daniel Kulp
Talend -

View raw message