You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by "Glynn, Eoghan" <eo...@iona.com> on 2007/07/11 18:23:46 UTC
Issue with the MultipleEndpointObserver
Folks,
We've run into a issue whereby a fault thrown from an implementor is
just being dropped on the floor, and an empty HTTP response returned to
the client.
After digging into it, it turns out that the problem is in the
MultipleEndpointObserver. Unlike the single-endpoint
ChainInitiationObserver, the MEO does not call setFaultObserver() on the
in-interceptor-chain. As a result, predictably, when an exception is
thrown from any interceptor in the in-chain, there's no fault observer
available to dispatch a fault response, so the fault is just lost.
In my case, the fault-throwing interceptor is the
ServiceInvokerInterceptor, but I guess the same issue would impact on
any other interceptor in the server-side in-chain.
I guess the reason for this over-sight is that within MOE.onMessage()
its not yet clear which of the multiple endpoints maintained by the MOE
should provide the fault observer to set on the in-chain.
The obvious fix is to call setFaultObserver() on the
in-interceptor-chain in
AbstractEndpointSelectionInterceptor.handleMessage(). However, my
concern is that there's still a window into the dispatch before the
endpoint selector interceptor is traversed ... e.g. the
AttachmentInInterceptor, StaxInInterceptor, ReadHeadersInterceptor ...
So rather than closing off a big gaping hole, I've just tightened it up
to a small non-gaping hole :)
Thoughts?
/Eoghan
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
RE: Issue with the MultipleEndpointObserver
Posted by "Glynn, Eoghan" <eo...@iona.com>.
OK, yeah I see the point about not even knowing that we've received a
valid SOAP message, so I guess it may not even make sense to respond
with a SOAP fault.
Reminds me of some WCF behaviour that seemed odd to me when I saw it
first ... for certain error scenarios, WCF just throws up its hands and
responds with a HTTP 400 containing a snippet of HTML in the payload
(e.g. "<h1>Bad Request (Invalid Header Name)</h1>"). Sortta implying
that HTML is like a canonical format to fallback on when the intended
MEP protocol isn't clear.
/Eoghan
> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com]
> Sent: 11 July 2007 23:10
> To: cxf-dev@incubator.apache.org
> Subject: Re: Issue with the MultipleEndpointObserver
>
> Good catch Eoghan.
>
> So I guess my philosophy is this. If we throw a fault before
> we decide on the service - which will typically be just after
> we read the headers, we're pretty screwed anyway. The
> incoming message may not have even been a valid soap message.
> Given the realm of possible exceptions, there was probably an
> IO error. So what we should do there is kind of undefined. T
>
> Maybe we should have some type of default faultobserver for
> when no service has been found which simply constructs a
> fault message and sends it on the back channel (if there is one).
>
> Thoughts?
> - Dan
>
> On 7/11/07, Glynn, Eoghan <eo...@iona.com> wrote:
> >
> >
> >
> > Folks,
> >
> > We've run into a issue whereby a fault thrown from an
> implementor is
> > just being dropped on the floor, and an empty HTTP response
> returned
> > to the client.
> >
> > After digging into it, it turns out that the problem is in the
> > MultipleEndpointObserver. Unlike the single-endpoint
> > ChainInitiationObserver, the MEO does not call
> setFaultObserver() on
> > the in-interceptor-chain. As a result, predictably, when an
> exception
> > is thrown from any interceptor in the in-chain, there's no fault
> > observer available to dispatch a fault response, so the
> fault is just lost.
> >
> > In my case, the fault-throwing interceptor is the
> > ServiceInvokerInterceptor, but I guess the same issue would
> impact on
> > any other interceptor in the server-side in-chain.
> >
> > I guess the reason for this over-sight is that within
> MOE.onMessage()
> > its not yet clear which of the multiple endpoints maintained by the
> > MOE should provide the fault observer to set on the in-chain.
> >
> > The obvious fix is to call setFaultObserver() on the
> > in-interceptor-chain in
> > AbstractEndpointSelectionInterceptor.handleMessage(). However, my
> > concern is that there's still a window into the dispatch before the
> > endpoint selector interceptor is traversed ... e.g. the
> > AttachmentInInterceptor, StaxInInterceptor,
> ReadHeadersInterceptor ...
> > So rather than closing off a big gaping hole, I've just
> tightened it
> > up to a small non-gaping hole :)
> >
> > Thoughts?
> >
> > /Eoghan
> >
> > ----------------------------
> > IONA Technologies PLC (registered in Ireland) Registered Number:
> > 171387 Registered Address: The IONA Building, Shelbourne
> Road, Dublin
> > 4, Ireland
> >
>
>
>
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
>
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: Issue with the MultipleEndpointObserver
Posted by Dan Diephouse <da...@envoisolutions.com>.
Good catch Eoghan.
So I guess my philosophy is this. If we throw a fault before we decide on
the service - which will typically be just after we read the headers, we're
pretty screwed anyway. The incoming message may not have even been a valid
soap message. Given the realm of possible exceptions, there was probably an
IO error. So what we should do there is kind of undefined. T
Maybe we should have some type of default faultobserver for when no service
has been found which simply constructs a fault message and sends it on the
back channel (if there is one).
Thoughts?
- Dan
On 7/11/07, Glynn, Eoghan <eo...@iona.com> wrote:
>
>
>
> Folks,
>
> We've run into a issue whereby a fault thrown from an implementor is
> just being dropped on the floor, and an empty HTTP response returned to
> the client.
>
> After digging into it, it turns out that the problem is in the
> MultipleEndpointObserver. Unlike the single-endpoint
> ChainInitiationObserver, the MEO does not call setFaultObserver() on the
> in-interceptor-chain. As a result, predictably, when an exception is
> thrown from any interceptor in the in-chain, there's no fault observer
> available to dispatch a fault response, so the fault is just lost.
>
> In my case, the fault-throwing interceptor is the
> ServiceInvokerInterceptor, but I guess the same issue would impact on
> any other interceptor in the server-side in-chain.
>
> I guess the reason for this over-sight is that within MOE.onMessage()
> its not yet clear which of the multiple endpoints maintained by the MOE
> should provide the fault observer to set on the in-chain.
>
> The obvious fix is to call setFaultObserver() on the
> in-interceptor-chain in
> AbstractEndpointSelectionInterceptor.handleMessage(). However, my
> concern is that there's still a window into the dispatch before the
> endpoint selector interceptor is traversed ... e.g. the
> AttachmentInInterceptor, StaxInInterceptor, ReadHeadersInterceptor ...
> So rather than closing off a big gaping hole, I've just tightened it up
> to a small non-gaping hole :)
>
> Thoughts?
>
> /Eoghan
>
> ----------------------------
> IONA Technologies PLC (registered in Ireland)
> Registered Number: 171387
> Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog