> It might be nice to be able to set this somewhere if the message protocol considers that a 202 might be the best strategy.
Shouldn't the <wsa:ReplyTo> header be set to anonymous in those cases? You could provide the callback/sink reference via some other header for example, or via an explicit parameter (say in the style of the <wsrm:AcksTo>) > Have any tests been done on the impact of this with other transfer protocols? By other transfer protocols, do you mean HTTP versus FTP etc.? Not really, as HTTP is the primary target transport for WS-RM (why use RM with the JMS transport for example, as this provides its own native delivery guarantees). > So when the 202 is sent, I presume the HTTP connection is closed? Depends on whether HTTP keep-alive was enabled. But assuming it wasn't, then the client will drop the outgoing connection on receiving the 202. > Then another connection is opened to send the full response based on the ReplyTo header? Yes. That's really the nub of it. One sets <wsa:ReplyTo> to a non-anonymous address so as to cause this separate server->client connection to be established when the response is ready for delivery. Cheers, Eoghan 2009/3/24 Andrew Harrison <[email protected]> > 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. 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 >> > >
