On Tue March 24 2009 6:57:56 am Andrew Harrison wrote: > Hi Eoghan, > > Thanks for the quick response :-) > > This makes sense to me, although it seems potential overkill in some > cases. It might be nice to be able to set this somewhere if the > message protocol considers that a 202 might be the best strategy. I'm > implementing WS-Eventing.
oooooo....... Is the WS-Eventing stuff you are working on possibly a candidate to submit to CXF? :-) Dan > At the moment there is no real need for a > 202 because the messages are just control messages as opposed to > application-specific exchanges (These obviously happen via > notification in WSE). I suppose this could change. > > Have any tests been done on the impact of this with other transfer > protocols? > > The isPartialResponse(message) was the incantation I was looking for > to handle this in my interceptors - thanks for the clue. > > So when the 202 is sent, I presume the HTTP connection is closed? Then > another connection is opened to send the full response based on the > ReplyTo header? > > I presume this is the case because my sink service was not actually > deployed until the response to the subscribe operation returned - > which is where the exception was occurring. This is because you may > not want to deploy a sink unless the source actually accepts your > subscription. But this is an error on my part - you shouldn't include > a replyTo to something that's not there yet!! > > I am getting other exceptions now, but I think I can work it out. > > Thanks for you help. > > cheers, > > Andrew > > On 24 Mar 2009, at 10:05, Eoghan Glynn wrote: > > Hi Andrew, > > > > The purpose of ContextUtils.rebaseResponse() is to cause a partial > > response > > to be sent from the server-side interceptor chain when an incoming > > message > > with a non-anonymous <wsa:ReplyTo> is encountered. > > > > A partial response may have some <soap:headers> but always has an > > empty > > <soap:body/>. The purpose of sending this message is two-fold: > > > > (a) to unblock the client-side transport with a HTTP "202 Accepted" > > response > > > > (b) to optionally allow for certain headers to be passed back to the > > client > > *at the earliest possible opportunity > > > > *The motivation for (a) is to avoid tieing up a connection for the > > duration > > of time required to process the request, given that the full reponse > > is > > going to be sent on a separate server->client connection. > > > > The main motivation of (b) was the timely provision of WS-RM > > acknowledgements.Any pending ACKs may be encoded in the partial > > response to > > avoid establishing a new server->client connection just to deliver > > these > > ACKs. Waiting for the full response to be ready in order to send > > pending > > ACKs may not be feasible as the request may take an indeterminate > > amount of > > time to process. > > > > Now where is the exception on the outgoing partial response actually > > occurring? > > > > Is it in your own interceptor code? Do you need to actually do > > anything > > specific with the partial response? If not, how about just ignoring > > it and > > allowing it to complete without interference? You can check if a > > message is > > a partial response via the > > org.apache.cxf.message.MessageUtils.isPartialResponse() API. > > > > Cheers, > > Eoghan -- Daniel Kulp [email protected] http://www.dankulp.com/blog
