You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Dennis Sosnoski <dm...@sosnoski.com> on 2011/02/23 11:11:27 UTC
Handling connection problems in WS-RM
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?
Thanks for any suggestions,
- Dennis
Re: Handling connection problems in WS-RM
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
On 02/24/2011 04:47 AM, Daniel Kulp wrote:
> On Wednesday 23 February 2011 5:11:27 AM Dennis Sosnoski wrote:
>
>
>> 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?
>>
> ...
> Actually, looking at ClientFaultConverter, it seems to already be done. If
> the FaultMode is UNCHECKED_APPLICATION_FAULT or CHECKED_APPLICATION_FAULT, it
> 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
> fault.
>
>
> Does that help?
>
Sounds good. I'll give it a try and see how it works out.
Thanks!
- Dennis
Re: Handling connection problems in WS-RM
Posted by Daniel Kulp <dk...@apache.org>.
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?
Sure.
>
> 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:
org.apache.cxf.message.FaultMode
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
the FaultMode is UNCHECKED_APPLICATION_FAULT or CHECKED_APPLICATION_FAULT, it
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
fault.
Does that help?
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com