cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alessio Soldano <>
Subject Re: WS-Addressing asynch MEP, CXF-2167 and WSTF tests
Date Sat, 25 Sep 2010 23:48:30 GMT
  Hi Dan,

On 09/24/2010 08:58 PM, Daniel Kulp wrote:
> I'm not sure I understand.   Does the RelatesTo on the response properly match
> the message id of the request?
Yes, it does; here is an example of request and response:

POST /wstf/sc003/Sc003Service HTTP/1.1







POST /wstf/sc003/Sc003ResponseService HTTP/1.1






>    If so, why is the MAPCodec not able to
> correlate the message?
Because we have 2 MAPCodec instances involved in the process

> I guess my concern is around a potential memory leak if the MAPCodec is
> holding onto messages waiting for a response.
mmh... I see what you mean, that's an issue related to this kind of 
scenario though, not to the change I'd do for preventing the abort on 
response receipt. I need to look better at the code next week, perhaps 
the memory leak can be prevented early detecting this kind of message 
exchange when sending the request...?


>     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 ( The application uses
>> JBossWS-CXF, currently leveraging Apache CXF trunk.
>> The third scenario of those WSTF tests is about WS-Addressing
>> interoperability, see
>> 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")."

Alessio Soldano
Web Service Lead, JBoss

View raw message