I'm not sure I understand. Does the RelatesTo on the response properly match the message id of the request? If so, why is the MAPCodec not able to correlate the message?
I guess my concern is around a potential memory leak if the MAPCodec is holding onto messages waiting for a response. But then again, I'm not sure I understand the issue. :-) Dan On Friday 24 September 2010 11:43:19 am Alessio Soldano wrote: > Hi, > I'm currently dealing with an application meant for testing the > scenarios defined by WSTF (http://www.wstf.org/). The application uses > JBossWS-CXF, currently leveraging Apache CXF trunk. > The third scenario of those WSTF tests is about WS-Addressing > interoperability, see http://www.wstf.org/docs/scenarios/sc003/sc003.xml > for all the details. > Currently I'm dealing with the 1.4 test (ASynch Echo+WSA): the client > sends a non-faulting echo message with WS-Addressing headers to indicate > an asynchronous response[1] is expected. wsa:Action, wsa:To, > wsa:MessageID and wsa:ReplyTo are required. The wsa:ReplyTo must refer > to an addressable endpoint that is also part of the application. > The success criteria for the test is that the service responds with the > appropriate echo response on a new connection to the wsa:ReplyTo EPR > specified in the echo message. On the original connection an HTTP 202 is > returned. The echo response message will contain the appropriate > WS-Addressing headers (wsa:Action, wsa:To and wsa:RelatesTo). > Currently the messages going over the wire are OK, however the test is > failing because when receiving the response message on the response > endpoint, the message is discarded with an abort on the interceptor > chain performed by the MAPCodec. The reason is that MAPCodec is not able > to find a correlated request message for the id provided in the > relatesTo attribute of the response message. > This is basically the same problem explained in CXF-2167, except we're > talking about a req-res MEP, so the application developer is not meant > (at least to me) to deal with setting the RelationshipType of relatesTo > in the response. > I'm thinking about relaxing that check for the correlated Exchange in > MAPCodec::restoreExchange, basically avoiding the abort on the > interceptor chain when the id is not found, for supporting usecases like > this. > WDYT ? > Thanks > Alessio > > [1] As per WSTF definition, Asynchronous Request-Response Message > Exchange: "A SOAP message exchange in which a requester sends a SOAP > message to a service and receives a response message. "Asynchronous" in > this context refers to the manner in which the underlying transport > protocol is used to carry the request and response messages. The > response message is sent over a separate connection that is initiated by > the service to the client (a "callback")." -- Daniel Kulp [email protected] http://dankulp.com/blog
