You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Alessio Soldano <as...@redhat.com> on 2010/09/24 17:43:19 UTC
WS-Addressing asynch MEP, CXF-2167 and WSTF tests
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")."
--
Alessio Soldano
Web Service Lead, JBoss
Re: WS-Addressing asynch MEP, CXF-2167 and WSTF tests
Posted by Alessio Soldano <as...@redhat.com>.
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
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Header><Action
xmlns="http://www.w3.org/2005/08/addressing">http://www.wstf.org/docs/scenarios/sc002/Echo</Action><MessageID
xmlns="http://www.w3.org/2005/08/addressing">urn:11d1def534ea1be0:43941453:12b43e809f7:-7ffd</MessageID><To
xmlns="http://www.w3.org/2005/08/addressing">http://localhost:8080/wstf/sc003/Sc003Service</To><ReplyTo
xmlns="http://www.w3.org/2005/08/addressing"><Address>http://localhost:8080/wstf/sc003/Sc003ResponseService</Address></ReplyTo><SessionData
xmlns="http://www.wstf.org/docs/scenarios/sc002"
xmlns:ns2="http://www.w3.org/2005/08/addressing"><ID>0</ID></SessionData></soap:Header><soap:Body><Echo
xmlns="http://www.wstf.org/docs/scenarios/sc002"
xmlns:ns2="http://www.w3.org/2005/08/addressing"><text>World</text></Echo></soap:Body></soap:Envelope>
POST /wstf/sc003/Sc003ResponseService HTTP/1.1
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Header><Action
xmlns="http://www.w3.org/2005/08/addressing">http://www.wstf.org/docs/scenarios/sc002/EchoResponse</Action><MessageID
xmlns="http://www.w3.org/2005/08/addressing">urn:uuid:b3743575-569d-4f31-960d-eb784ae2a37e</MessageID><To
xmlns="http://www.w3.org/2005/08/addressing">http://localhost:8080/wstf/sc003/Sc003ResponseService</To><RelatesTo
xmlns="http://www.w3.org/2005/08/addressing">urn:11d1def534ea1be0:43941453:12b43e809f7:-7ffd</RelatesTo></soap:Header><soap:Body><EchoResponse
xmlns="http://www.wstf.org/docs/scenarios/sc002"
xmlns:ns2="http://www.w3.org/2005/08/addressing"><text>World</text></EchoResponse></soap:Body></soap:Envelope>
> 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...?
Cheers
Alessio
> 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")."
--
Alessio Soldano
Web Service Lead, JBoss
Re: WS-Addressing asynch MEP, CXF-2167 and WSTF tests
Posted by Daniel Kulp <dk...@apache.org>.
On Wednesday 29 September 2010 11:51:04 am Andrew Dinn wrote:
> Hi Dan,
>
> Thanks for the explanation. I have a few comments inline.
>
> On 09/29/2010 02:54 PM, Daniel Kulp wrote:
> > 1) JAX-WS async client callbacks. We need to correlate the incoming
> > message with the outgoing request so we can figure out which call back
> > object to call. This correlation could potentially be pushed into the
> > ClientImpl after the soap processing and everything is done, but it
> > still needs some way to correlate.
>
> Hmm, I had not ever considered combining async requests with response
> redirection via WSA ReplyTo/FaultTo (you probably need to be slightly
> out of your mind to do so :-). I guess it might be possible to do this
> to a degree, depending on where the response is redirected to. However,
> it has to be limited to some extent e.g. registering an async callback
> in the requester JVM cannot seriously be expected to work if the
> response is redirected to a different JVM.
Yea. I think MUCH of the JAX-WS style stuff won't work correctly in the cases
where ReplyTo/FaultTo doesn't come back to the same place as where the message
originated. If you don't use the async stuff, the calls will likely
timeout and the client would get timeout exceptions. If you do use async,
you're likely to have memory leaks or similar.
> > 2) JAX-WS handlers - if I remember correctly, if a Handler on the
> > outgoing side sets a property on the context, it needs to be available
> > when the handler on the incoming side. Thus, we would need some level
> > of correlation prior to handlers being called. Our own interceptors
> > have the same issue. For example, the Logging interceptors stick an ID
> > # on the exchange so you can visually correlate the messages in the logs
> > (although the logging interceptors run prior to the MAPCodec, so this
> > probably doesn't work in this case anyway). WS-SecurityPolicy also
> > requires this if signature confirmation is enabled. We need to record
> > the signatures that were sent so we can make sure they are properly
> > confirmed on the response. (although, thinking about this, I also don't
> > know if that works in the decoupled case)
>
> The handler spec also seems to be written on the assumption that a
> request response MEP has the response coming back to where it was sent
> from. But then again in the code I have written which relies on async
> FaultTo (or rather is speced so that it has to rely on it) I ensure that
> the handlers at the FaultTo end point know what to do on the basis of
> messageId/relatesTo values and shared JVM state (the client and FaultTo
> endpoint handler are not just in the same JVM but also part of the same
> app with a common classloader/class space). I don't expect the JaxWS
> layer to manage that context sharing for me. Once again, it might be
> possible for the JaxWS layer to support this sharing of context data for
> outgoing request and incoming response handlers to some degree but it
> clearly cannot be extended to the inter-JVM case.
Right. Again, this is kind of outside the scope of what JAX-WS really targets
for it's usecases.
> > 3) WS-RM - but I don't really know all the details
>
> I am not sure either since I only glanced at this code a couple of years
> ago. However, I thought it was adding explicit message header data to do
> its correlation.
>
> > 4) Mapping to the correct Operation for the response - by correlating, we
> > have the OperationInfo and such that was used for the request so the
> > response can be properly unmarshalled and such based on that
> > OperationInfo. Without the correlation, we'd have to do extra
> > processing to use the body contents to figure out the OperationInfo and
> > such. The problem is that that wouldn't be reliable as you can have
> > multiple operations with the same return message (but different request
> > messages) and still be compliant.
>
> That's an interesting point you raise here. When a response gets
> redirected how *is* it supposed to be processed. My own code only
> provides limited input here since I only use FaultTo redirection for
> OneWay messages. But with a redirected request-response exchange the
> question arises as to what sort of processing the ReplyTo endpoint is
> supposed to perform when and what sort of response handling the
> requester is supposed to perform. Is the ReplyTo endpoint supposed to
> handle the incoming message as though it was a response to a 2 way
> exchange? Or is it meant to handle it as a self-contained incoming
> message and ignore the fact that it was dispatched in reply to a RPC
> style request.
>
> I had always assumed the latter. So, for example, if the response has an
> associated WSA action I assumed it would be directed to a operation
> implementation method on the ReplyTo endpoint bean which was identified
> by that action. Ditto if there is a soap action. In the absence of an
> action I would have expected the usual rule to apply -- identify the
> type of the argument and direct to an operation using the type name as
> an identifier.
>
> I also assumed that the thread which made the original RPC style request
> would not be expecting to deserialise a reply because the ReplyTo was
> not null/anonymous/noreply.
Since this usecase really is way outside the JAX-WS spec things, I think we
can kind of figure out for ourselves what makes sense from a CXF standpoint.
You're description definitely seems fine by me. :-)
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: WS-Addressing asynch MEP, CXF-2167 and WSTF tests
Posted by Andrew Dinn <ad...@redhat.com>.
Hi Dan,
Thanks for the explanation. I have a few comments inline.
On 09/29/2010 02:54 PM, Daniel Kulp wrote:
> 1) JAX-WS async client callbacks. We need to correlate the incoming message
> with the outgoing request so we can figure out which call back object to call.
> This correlation could potentially be pushed into the ClientImpl after the
> soap processing and everything is done, but it still needs some way to
> correlate.
Hmm, I had not ever considered combining async requests with response
redirection via WSA ReplyTo/FaultTo (you probably need to be slightly
out of your mind to do so :-). I guess it might be possible to do this
to a degree, depending on where the response is redirected to. However,
it has to be limited to some extent e.g. registering an async callback
in the requester JVM cannot seriously be expected to work if the
response is redirected to a different JVM.
> 2) JAX-WS handlers - if I remember correctly, if a Handler on the outgoing
> side sets a property on the context, it needs to be available when the handler
> on the incoming side. Thus, we would need some level of correlation prior to
> handlers being called. Our own interceptors have the same issue. For
> example, the Logging interceptors stick an ID # on the exchange so you can
> visually correlate the messages in the logs (although the logging interceptors
> run prior to the MAPCodec, so this probably doesn't work in this case anyway).
> WS-SecurityPolicy also requires this if signature confirmation is enabled. We
> need to record the signatures that were sent so we can make sure they are
> properly confirmed on the response. (although, thinking about this, I also
> don't know if that works in the decoupled case)
The handler spec also seems to be written on the assumption that a
request response MEP has the response coming back to where it was sent
from. But then again in the code I have written which relies on async
FaultTo (or rather is speced so that it has to rely on it) I ensure that
the handlers at the FaultTo end point know what to do on the basis of
messageId/relatesTo values and shared JVM state (the client and FaultTo
endpoint handler are not just in the same JVM but also part of the same
app with a common classloader/class space). I don't expect the JaxWS
layer to manage that context sharing for me. Once again, it might be
possible for the JaxWS layer to support this sharing of context data for
outgoing request and incoming response handlers to some degree but it
clearly cannot be extended to the inter-JVM case.
> 3) WS-RM - but I don't really know all the details
I am not sure either since I only glanced at this code a couple of years
ago. However, I thought it was adding explicit message header data to do
its correlation.
> 4) Mapping to the correct Operation for the response - by correlating, we have
> the OperationInfo and such that was used for the request so the response can
> be properly unmarshalled and such based on that OperationInfo. Without the
> correlation, we'd have to do extra processing to use the body contents to
> figure out the OperationInfo and such. The problem is that that wouldn't be
> reliable as you can have multiple operations with the same return message (but
> different request messages) and still be compliant.
That's an interesting point you raise here. When a response gets
redirected how *is* it supposed to be processed. My own code only
provides limited input here since I only use FaultTo redirection for
OneWay messages. But with a redirected request-response exchange the
question arises as to what sort of processing the ReplyTo endpoint is
supposed to perform when and what sort of response handling the
requester is supposed to perform. Is the ReplyTo endpoint supposed to
handle the incoming message as though it was a response to a 2 way
exchange? Or is it meant to handle it as a self-contained incoming
message and ignore the fact that it was dispatched in reply to a RPC
style request.
I had always assumed the latter. So, for example, if the response has an
associated WSA action I assumed it would be directed to a operation
implementation method on the ReplyTo endpoint bean which was identified
by that action. Ditto if there is a soap action. In the absence of an
action I would have expected the usual rule to apply -- identify the
type of the argument and direct to an operation using the type name as
an identifier.
I also assumed that the thread which made the original RPC style request
would not be expecting to deserialise a reply because the ReplyTo was
not null/anonymous/noreply.
> Hope that helps a bit.
Yes, thank you very much for your help.
regards,
Andrew Dinn
-----------
Re: WS-Addressing asynch MEP, CXF-2167 and WSTF tests
Posted by Daniel Kulp <dk...@apache.org>.
On Wednesday 29 September 2010 4:53:25 am Andrew Dinn wrote:
> Hi Dan,
>
> I am afraid I have much shallower knowledge of the CXF code than
> Alessio so I hope you will forgive me asking a rather simple-minded
> question. Could you explain why CXF needs to perform correlation of
> outgoing requests and incoming responses?
There are a few uses cases that I can think of off the top of my head, but all
relate to request/response use cases with the SAME client proxy:
1) JAX-WS async client callbacks. We need to correlate the incoming message
with the outgoing request so we can figure out which call back object to call.
This correlation could potentially be pushed into the ClientImpl after the
soap processing and everything is done, but it still needs some way to
correlate.
2) JAX-WS handlers - if I remember correctly, if a Handler on the outgoing
side sets a property on the context, it needs to be available when the handler
on the incoming side. Thus, we would need some level of correlation prior to
handlers being called. Our own interceptors have the same issue. For
example, the Logging interceptors stick an ID # on the exchange so you can
visually correlate the messages in the logs (although the logging interceptors
run prior to the MAPCodec, so this probably doesn't work in this case anyway).
WS-SecurityPolicy also requires this if signature confirmation is enabled. We
need to record the signatures that were sent so we can make sure they are
properly confirmed on the response. (although, thinking about this, I also
don't know if that works in the decoupled case)
3) WS-RM - but I don't really know all the details
4) Mapping to the correct Operation for the response - by correlating, we have
the OperationInfo and such that was used for the request so the response can
be properly unmarshalled and such based on that OperationInfo. Without the
correlation, we'd have to do extra processing to use the body contents to
figure out the OperationInfo and such. The problem is that that wouldn't be
reliable as you can have multiple operations with the same return message (but
different request messages) and still be compliant.
Hope that helps a bit.
Dan
>
> regards,
>
>
> Andrew Dinn
> -----------
>
> On 09/28/2010 09:33 PM, Daniel Kulp wrote:
> > On Tuesday 28 September 2010 7:26:24 am Alessio Soldano wrote:
> >> Hi Dan,
> >>
> >> On 09/27/2010 08:25 PM, Daniel Kulp wrote:
> >>> Hmm..... I wonder if we can tackle some of these things kind of piece
> >>> meal, in steps:
> >>>
> >>> 1) Scenario one is a single Bus, but multiple MAPCodec's. This should
> >>> be fairly easy. If the MAPCodec stores it's storage map as a property
> >>> on the Bus, then multple MAPCodecs could share the storage and the
> >>> problem would be solved for this usecase, right?
> >>
> >> Right
> >>
> >>> 2) Scenario two is a single JVM/classlaoder with multiple bus's. This
> >>> is similar to (1), but the storage could be pre-configured and
> >>> shareable.
> >>
> >> Yes. Btw this is more or less the scenario we're on right now, as we
> >> could have this storage as a shared facility provided by CXF libraries
> >> which can be seen by all apps using them.
> >>
> >>> 3) Scenario three would be multiple apps/jvms/classloader. This is
> >>> trickier. One solution would be to allow configuring in a distrubted
> >>> map implementation for the storage.
> >>
> >> Yes, this is indeed trickier... and would deal with client and final
> >> response endpoint running on different jvm/classloader.
> >>
> >> IOW what you're suggesting here is that this might basically be a matter
> >> of having the user configure the storage with the scope/visibility he
> >> needs, right?
> >
> > Yea. That's kind of what I was thinking. This MAY be combinable with
> > your disabling of the correlation check so if the message cannot be
> > correlated in the current storage, just let it through like you
> > originally tried. To avoid the memory leak, we could timestamp the
> > outgoing exchange and periodically purge the exchanges based on some
> > sort of configurable timeout. That would at least cover MOST of the
> > issues.
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: WS-Addressing asynch MEP, CXF-2167 and WSTF tests
Posted by Andrew Dinn <ad...@redhat.com>.
Hi Alessio,
On 09/29/2010 10:24 AM, Alessio Soldano wrote:
> I actually had a brief chat about this with Dan yesterday. The main
> reason seems to be in WS-RM needs, but I still need to look at the
> details (to understand what actually needs to be copied from one
> exchange to the other). Besides that, there're probably other
> requirements related to visibility of context properties.
So, I can't be miles off the wrong track then. :-)
Yes, the ability to implement some form of reliable messaging (by which
I mean both WS-RM or also, perhaps, CXF's own notion of reliability) was
the first obvious thing that sprang to my mind. However, I wondered if
there was some deeper reason and if so whether it was an artefact of the
current CXF design or was down to some other necessity intrinsic to WS.
regards,
Andrew Dinn
-----------
Re: WS-Addressing asynch MEP, CXF-2167 and WSTF tests
Posted by Alessio Soldano <as...@redhat.com>.
Hi Andrew,
I actually had a brief chat about this with Dan yesterday. The main
reason seems to be in WS-RM needs, but I still need to look at the
details (to understand what actually needs to be copied from one
exchange to the other). Besides that, there're probably other
requirements related to visibility of context properties.
Cheers
Alessio
On 09/29/2010 10:53 AM, Andrew Dinn wrote:
> Hi Dan,
>
> I am afraid I have much shallower knowledge of the CXF code than
> Alessio so I hope you will forgive me asking a rather simple-minded
> question. Could you explain why CXF needs to perform correlation of
> outgoing requests and incoming responses?
>
> regards,
>
>
> Andrew Dinn
> -----------
>
> On 09/28/2010 09:33 PM, Daniel Kulp wrote:
>> On Tuesday 28 September 2010 7:26:24 am Alessio Soldano wrote:
>>> Hi Dan,
>>>
>>> On 09/27/2010 08:25 PM, Daniel Kulp wrote:
>>>> Hmm..... I wonder if we can tackle some of these things kind of
>>>> piece
>>>> meal, in steps:
>>>>
>>>> 1) Scenario one is a single Bus, but multiple MAPCodec's. This
>>>> should
>>>> be fairly easy. If the MAPCodec stores it's storage map as a property
>>>> on the Bus, then multple MAPCodecs could share the storage and the
>>>> problem would be solved for this usecase, right?
>>>
>>> Right
>>>
>>>> 2) Scenario two is a single JVM/classlaoder with multiple bus's.
>>>> This is
>>>> similar to (1), but the storage could be pre-configured and shareable.
>>>
>>> Yes. Btw this is more or less the scenario we're on right now, as we
>>> could have this storage as a shared facility provided by CXF libraries
>>> which can be seen by all apps using them.
>>>
>>>> 3) Scenario three would be multiple apps/jvms/classloader. This is
>>>> trickier. One solution would be to allow configuring in a
>>>> distrubted map
>>>> implementation for the storage.
>>>
>>> Yes, this is indeed trickier... and would deal with client and final
>>> response endpoint running on different jvm/classloader.
>>>
>>> IOW what you're suggesting here is that this might basically be a
>>> matter
>>> of having the user configure the storage with the scope/visibility he
>>> needs, right?
>>
>> Yea. That's kind of what I was thinking. This MAY be combinable
>> with your
>> disabling of the correlation check so if the message cannot be
>> correlated in
>> the current storage, just let it through like you originally tried.
>> To avoid
>> the memory leak, we could timestamp the outgoing exchange and
>> periodically
>> purge the exchanges based on some sort of configurable timeout.
>> That would
>> at least cover MOST of the issues.
>>
>>
>
--
Alessio Soldano
Web Service Lead, JBoss
Re: WS-Addressing asynch MEP, CXF-2167 and WSTF tests
Posted by Andrew Dinn <ad...@redhat.com>.
Hi Dan,
I am afraid I have much shallower knowledge of the CXF code than
Alessio so I hope you will forgive me asking a rather simple-minded
question. Could you explain why CXF needs to perform correlation of
outgoing requests and incoming responses?
regards,
Andrew Dinn
-----------
On 09/28/2010 09:33 PM, Daniel Kulp wrote:
> On Tuesday 28 September 2010 7:26:24 am Alessio Soldano wrote:
>> Hi Dan,
>>
>> On 09/27/2010 08:25 PM, Daniel Kulp wrote:
>>> Hmm..... I wonder if we can tackle some of these things kind of piece
>>> meal, in steps:
>>>
>>> 1) Scenario one is a single Bus, but multiple MAPCodec's. This should
>>> be fairly easy. If the MAPCodec stores it's storage map as a property
>>> on the Bus, then multple MAPCodecs could share the storage and the
>>> problem would be solved for this usecase, right?
>>
>> Right
>>
>>> 2) Scenario two is a single JVM/classlaoder with multiple bus's. This is
>>> similar to (1), but the storage could be pre-configured and shareable.
>>
>> Yes. Btw this is more or less the scenario we're on right now, as we
>> could have this storage as a shared facility provided by CXF libraries
>> which can be seen by all apps using them.
>>
>>> 3) Scenario three would be multiple apps/jvms/classloader. This is
>>> trickier. One solution would be to allow configuring in a distrubted map
>>> implementation for the storage.
>>
>> Yes, this is indeed trickier... and would deal with client and final
>> response endpoint running on different jvm/classloader.
>>
>> IOW what you're suggesting here is that this might basically be a matter
>> of having the user configure the storage with the scope/visibility he
>> needs, right?
>
> Yea. That's kind of what I was thinking. This MAY be combinable with your
> disabling of the correlation check so if the message cannot be correlated in
> the current storage, just let it through like you originally tried. To avoid
> the memory leak, we could timestamp the outgoing exchange and periodically
> purge the exchanges based on some sort of configurable timeout. That would
> at least cover MOST of the issues.
>
>
--
regards,
Andrew Dinn
-----------
Senior Software Engineer, JBoss
Red Hat UK Ltd
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire,
SI4 1TE, United Kingdom.
Registered in UK and Wales under Company Registration No. 3798903
Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons
(USA) and Brendan Lane (Ireland)
Re: WS-Addressing asynch MEP, CXF-2167 and WSTF tests
Posted by Daniel Kulp <dk...@apache.org>.
On Tuesday 28 September 2010 7:26:24 am Alessio Soldano wrote:
> Hi Dan,
>
> On 09/27/2010 08:25 PM, Daniel Kulp wrote:
> > Hmm..... I wonder if we can tackle some of these things kind of piece
> > meal, in steps:
> >
> > 1) Scenario one is a single Bus, but multiple MAPCodec's. This should
> > be fairly easy. If the MAPCodec stores it's storage map as a property
> > on the Bus, then multple MAPCodecs could share the storage and the
> > problem would be solved for this usecase, right?
>
> Right
>
> > 2) Scenario two is a single JVM/classlaoder with multiple bus's. This is
> > similar to (1), but the storage could be pre-configured and shareable.
>
> Yes. Btw this is more or less the scenario we're on right now, as we
> could have this storage as a shared facility provided by CXF libraries
> which can be seen by all apps using them.
>
> > 3) Scenario three would be multiple apps/jvms/classloader. This is
> > trickier. One solution would be to allow configuring in a distrubted map
> > implementation for the storage.
>
> Yes, this is indeed trickier... and would deal with client and final
> response endpoint running on different jvm/classloader.
>
> IOW what you're suggesting here is that this might basically be a matter
> of having the user configure the storage with the scope/visibility he
> needs, right?
Yea. That's kind of what I was thinking. This MAY be combinable with your
disabling of the correlation check so if the message cannot be correlated in
the current storage, just let it through like you originally tried. To avoid
the memory leak, we could timestamp the outgoing exchange and periodically
purge the exchanges based on some sort of configurable timeout. That would
at least cover MOST of the issues.
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: WS-Addressing asynch MEP, CXF-2167 and WSTF tests
Posted by Daniel Kulp <dk...@apache.org>.
On Tuesday 28 September 2010 9:09:56 am Alessio Soldano wrote:
> Hi,
>
> On 09/28/2010 01:26 PM, Alessio Soldano wrote:
> >> similar to (1), but the storage could be pre-configured and shareable.
> >
> > 2) Scenario two is a single JVM/classlaoder with multiple bus's. This is
> > Yes. Btw this is more or less the scenario we're on right now, as we
> > could have this storage as a shared facility provided by CXF libraries
> > which can be seen by all apps using them.
>
> I've just done a quick (& dirty) try locally, making the
> uncorrelatedExchanges map in MAPCodec a static attribute of that class,
> so that the map is shared in the jvm.
Uhg... Yuck. But for testing, OK. :-)
> That avoids the problem with the
> retrieval of the correlated exchange in the response endpoint, but
> reveals other issues (or at least generates some doubts/questions to me
> ;-)) once the exchange coming from the request message is installed in
> the response message.
>
> As previously mentioned, in my testcase, the response is received by a
> response endpoint; setting the exchange from the request in the response
> message overwrites the existing exchange and that seems to cause some of
> the endpoint server things to get lost (the invoker instance in the
> service/endpoint, the whole destination instance, ...). This makes me
> wonder whether completely swapping the exchange is the right approach or
> the MAPCodec there should instead ask the two exchanges to be somehow
> "merged" (having the Exchange class copy what is actually required to be
> copied - btw, is there a list of this?)
Hmm.... it probably needs to be the other way around. Copy everything except
a list of things that would cause issues. The Bus is one, the
BindingOperationInfo and related servicemodel things is another. Good luck!
:-)
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: WS-Addressing asynch MEP, CXF-2167 and WSTF tests
Posted by Alessio Soldano <as...@redhat.com>.
Hi,
On 09/28/2010 01:26 PM, Alessio Soldano wrote:
>> similar to (1), but the storage could be pre-configured and shareable.
> 2) Scenario two is a single JVM/classlaoder with multiple bus's. This is
> Yes. Btw this is more or less the scenario we're on right now, as we
> could have this storage as a shared facility provided by CXF libraries
> which can be seen by all apps using them.
I've just done a quick (& dirty) try locally, making the
uncorrelatedExchanges map in MAPCodec a static attribute of that class,
so that the map is shared in the jvm. That avoids the problem with the
retrieval of the correlated exchange in the response endpoint, but
reveals other issues (or at least generates some doubts/questions to me
;-)) once the exchange coming from the request message is installed in
the response message.
As previously mentioned, in my testcase, the response is received by a
response endpoint; setting the exchange from the request in the response
message overwrites the existing exchange and that seems to cause some of
the endpoint server things to get lost (the invoker instance in the
service/endpoint, the whole destination instance, ...). This makes me
wonder whether completely swapping the exchange is the right approach or
the MAPCodec there should instead ask the two exchanges to be somehow
"merged" (having the Exchange class copy what is actually required to be
copied - btw, is there a list of this?)
Cheers
Alessio
--
Alessio Soldano
Web Service Lead, JBoss
Re: WS-Addressing asynch MEP, CXF-2167 and WSTF tests
Posted by Alessio Soldano <as...@redhat.com>.
Hi Dan,
On 09/27/2010 08:25 PM, Daniel Kulp wrote:
> Hmm..... I wonder if we can tackle some of these things kind of piece meal,
> in steps:
>
> 1) Scenario one is a single Bus, but multiple MAPCodec's. This should be
> fairly easy. If the MAPCodec stores it's storage map as a property on the
> Bus, then multple MAPCodecs could share the storage and the problem would be
> solved for this usecase, right?
Right
> 2) Scenario two is a single JVM/classlaoder with multiple bus's. This is
> similar to (1), but the storage could be pre-configured and shareable.
Yes. Btw this is more or less the scenario we're on right now, as we
could have this storage as a shared facility provided by CXF libraries
which can be seen by all apps using them.
> 3) Scenario three would be multiple apps/jvms/classloader. This is trickier.
> One solution would be to allow configuring in a distrubted map implementation
> for the storage.
Yes, this is indeed trickier... and would deal with client and final
response endpoint running on different jvm/classloader.
IOW what you're suggesting here is that this might basically be a matter
of having the user configure the storage with the scope/visibility he
needs, right?
Thanks
Alessio
--
Alessio Soldano
Web Service Lead, JBoss
Re: WS-Addressing asynch MEP, CXF-2167 and WSTF tests
Posted by Daniel Kulp <dk...@apache.org>.
On Monday 27 September 2010 4:42:55 am Andrew Dinn wrote:
> On 09/24/2010 07: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? If so, why is the MAPCodec not
> > able to correlate the message?
>
> The problem is that when using ReplyTo/FaultTo the response may be sent
> from one bus/exchange and the reply received by another. Your use fo
> MessageID/RelatesTo to correlate request/response assumes that teh
> response comes back to where it is sent to. This assumption may be invalid.
>
> > 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. :-)
>
> Yes, this is one side of the problem -- the sender exchange fills with
> garbage. The other side is that the receiver exchange drops legitimate
> responses because they rae being received at a different location to the
> sender. Unfortunately, proper support for WSA ReplyTo/FaultTo requires
> that to be allowed.
Hmm..... I wonder if we can tackle some of these things kind of piece meal,
in steps:
1) Scenario one is a single Bus, but multiple MAPCodec's. This should be
fairly easy. If the MAPCodec stores it's storage map as a property on the
Bus, then multple MAPCodecs could share the storage and the problem would be
solved for this usecase, right?
2) Scenario two is a single JVM/classlaoder with multiple bus's. This is
similar to (1), but the storage could be pre-configured and shareable.
3) Scenario three would be multiple apps/jvms/classloader. This is trickier.
One solution would be to allow configuring in a distrubted map implementation
for the storage.
Thoughts? Ideas?
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: WS-Addressing asynch MEP, CXF-2167 and WSTF tests
Posted by Andrew Dinn <ad...@redhat.com>.
On 09/24/2010 07: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? If so, why is the MAPCodec not able to
> correlate the message?
The problem is that when using ReplyTo/FaultTo the response may be sent
from one bus/exchange and the reply received by another. Your use fo
MessageID/RelatesTo to correlate request/response assumes that teh
response comes back to where it is sent to. This assumption may be invalid.
> 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. :-)
Yes, this is one side of the problem -- the sender exchange fills with
garbage. The other side is that the receiver exchange drops legitimate
responses because they rae being received at a different location to the
sender. Unfortunately, proper support for WSA ReplyTo/FaultTo requires
that to be allowed.
regards,
Andrew Dinn
-----------
Re: WS-Addressing asynch MEP, CXF-2167 and WSTF tests
Posted by Daniel Kulp <dk...@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