Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
From: Daniel Kulp <dkulp@apache.org>
To: dev@cxf.apache.org
Subject: Re: WS-Addressing asynch MEP, CXF-2167 and WSTF tests
Date: Fri, 24 Sep 2010 14:58:32 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.35; KDE/4.5.1; x86_64; ; )
Cc: Alessio Soldano <asoldano@redhat.com>,
 Andrew Dinn <adinn@redhat.com>
References: <4C9CC717.20705@redhat.com>
In-Reply-To: <4C9CC717.20705@redhat.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201009241458.32789.dkulp@apache.org>


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
dkulp@apache.org
http://dankulp.com/blog