[
https://issues.apache.org/jira/browse/CXF-6519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14660798#comment-14660798
]
Jozef Tomek edited comment on CXF-6519 at 8/7/15 9:27 AM:
----------------------------------------------------------
Hi Akitoshi
>> actually the wrong constant is not relevant here because WS-RM 1.1's close
>> sequence has no sequenced message attached to it and needs no sequence
>> processing.
What I have is cxf 2.7.11 client on one side, ServiceMix with cxf 2.7.14 as
server side. Within sequence creation, client also offers inbound sequence with
this dummy / anonymous URI, server accepts both (probably not important, but
still mentioning it). This invalid constant then definitely causes empty
response to be sent to CloseSequence request which in turn makes client to not
proceed and send TerminateSequence. From what I see in the payload, the
CloseSequence request is another message in a sequence with it's own UID and
order number.
Also, per spec
([1.1|http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-spec-os-01-e1.pdf],
line 750):
"A CloseSequenceResponse is sent in the body of a message in response to
receipt of a CloseSequence request message. It indicates that the responder has
closed the Sequence."
I patched the server side stack (shadowed only the RMInInterceptor class with
dirty OSGi hack) and now server responds with SequenceAcknowledgement acking
the CloseSequence request (it's order number) and client proceeds and sends
TerminateSequence to which server responds with TerminateSequenceResponse ...
while properly removing the sequence(s) from the RMTxStore. That's actualy how
I found the issue ... sequences/messages have not been removed from RMTxStore
and I back-tracked through call hierarchy which led me to single possible call
- processSequence(destination, message) on line 173.
>> And I just verified that the CloseSequenceResponse is correctly returned for
>> both 3.1.2 and 3.0.6. I haven't verified if some earlier 3.x.x has the same
>> limitation as in 2.7.x.
Once I am little less busy at work, I definitely want to try it with 3.x
binaries.
Regards
Jozef
was (Author: jtomek):
Hi Akitoshi
>> actually the wrong constant is not relevant here because WS-RM 1.1's close
>> sequence has no sequenced message attached to it and needs no sequence
>> processing.
What I have is cxf 2.7.11 client on one side, ServiceMix with cxf 2.7.14 as
server side. Within sequence creation, client also offers inbound sequence with
this dummy / anonymous URI, server accepts both (probably not important, but
still mentioning it). This invalid constant then definitely causes empty
response to be sent to CloseSequence request which in turn makes client to not
proceed and send TerminateSequence. From what I see in the payload, the
CloseSequence request is another message in a sequence with it's own UID and
order number.
Also, per spec
([1.1|http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.2-spec-os.pdf], line
750):
"A CloseSequenceResponse is sent in the body of a message in response to
receipt of a CloseSequence request message. It indicates that the responder has
closed the Sequence."
I patched the server side stack (shadowed only the RMInInterceptor class with
dirty OSGi hack) and now server responds with SequenceAcknowledgement acking
the CloseSequence request (it's order number) and client proceeds and sends
TerminateSequence to which server responds with TerminateSequenceResponse ...
while properly removing the sequence(s) from the RMTxStore. That's actualy how
I found the issue ... sequences/messages have not been removed from RMTxStore
and I back-tracked through call hierarchy which led me to single possible call
- processSequence(destination, message) on line 173.
>> And I just verified that the CloseSequenceResponse is correctly returned for
>> both 3.1.2 and 3.0.6. I haven't verified if some earlier 3.x.x has the same
>> limitation as in 2.7.x.
Once I am little less busy at work, I definitely want to try it with 3.x
binaries.
Regards
Jozef
> WS-RM - Invalid response for CloseSequence
> ------------------------------------------
>
> Key: CXF-6519
> URL: https://issues.apache.org/jira/browse/CXF-6519
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
> Reporter: Jozef Tomek
> Assignee: Akitoshi Yoshida
>
> When endpoint is running with WS-RM 1.1/1.2 enabled, after CloseSequence
> control message (org.apache.cxf.ws.rm.RM11Constants.CLOSE_SEQUENCE_ACTION) is
> received, invalid empty response (202 Accepted with no content) is returned
> instead of CloseSequenceResponse.
> This in turn means that source RM endpoint won't proceed to terminate the
> sequence which results in sequence metadata not being being removed (as part
> of sequence termination handling) from RMTxStore if it's used on either side.
> I suspect one particular line to be causing the issue - see line 172 where I
> believe RM11Constants.CLOSE_SEQUENCE_ACTION should be used instead of
> RM11Constants.SEQUENCE_ACKNOWLEDGMENT_ACTION:
> {code:title=org.apache.cxf.ws.rm.RMInInterceptor|borderStyle=solid}
> 85 protected void handle(Message message) throws SequenceFault,
> RMException {
> ...
> 166 } else {
> 167 rme.receivedControlMessage();
> 168 if
> (RM10Constants.SEQUENCE_ACKNOWLEDGMENT_ACTION.equals(action)
> 169 ||
> RM11Constants.SEQUENCE_ACKNOWLEDGMENT_ACTION.equals(action)) {
> 170 processAcknowledgments(rme, rmps, protocol);
> 171 } else if (RM10Constants.CLOSE_SEQUENCE_ACTION.equals(action)
> 172 ||
> RM11Constants.SEQUENCE_ACKNOWLEDGMENT_ACTION.equals(action)) {
> 173 processSequence(destination, message);
> 174 } else if
> ((RM10Constants.CREATE_SEQUENCE_ACTION.equals(action)
> 175 || RM11Constants.CREATE_SEQUENCE_ACTION.equals(action))
> && !isServer) {
> 176 LOG.fine("Processing inbound CreateSequence on client
> side.");
> 177 Servant servant = rme.getServant();
> 178 Object csr = servant.createSequence(message);
> 179 Proxy proxy = rme.getProxy();
> 180 proxy.createSequenceResponse(csr, protocol);
> 181 return;
> 182 }
> 183 }
> 184
> 185 assertReliability(message);
> 186 }
> {code}
> I found the issue on v2.7.14, but I think the issue is present on all
> versions (since I see suspected code present in all versions)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
