[
https://issues.apache.org/jira/browse/CXF-6519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14661479#comment-14661479
]
Akitoshi Yoshida commented on CXF-6519:
---------------------------------------
Hi Jozef,
calling line line 173 triggers the sequence handling and consequently its ack
generation code. But the RM11 CloseSequence message has no message for that
sequence and does not require any sequence ack handling unlike a normal message
carrying a numbered message. Because of this, as you already observed, in
calling that method, you would just get the ack message and not the expected
CloseSequenceResponse message. So this is still incorrect and you are just
lucky that your client accepted this incorrect response. On the other hand, you
are unlucky that your client did not accept yet another incorrect empty
response. If it did, you wouldn't have had this problem.
Ideally, any WS-RM client should ignore any response from CloseSequence or
TerminateSequence. Because these control messages are intended for the client
(RMSource) to inform the server (RMDestination) that the client has no
intention of sending additional messages over this sequence so that the server
can free the associated resource. As the client will send these messages as
BestEffort and anything can happen, the client should log/warn anything
unexpected (i.e., getting an error or un unexpected response) but continue
processing so that it is protected from any server or network problem. Such a
rule should be part of the WSI WS-RM profile which does not exit.
If you have an RM client that strictly expects the CloseSequenceResponse
message before initiating the TerminateSequence process, you will have an issue
with not only CXF 2.7.x which does not currently support CloseSequenceResponse
but also with any server or network that sporadically fails.
For 3.1.x and 3.0.x, there is an integration unit test verifying the correct
CloseSequence/CloseSequenceResponse handling.
https://github.com/apache/cxf/blob/master/systests/ws-rm/src/test/java/org/apache/cxf/systest/ws/rm/ProtocolVariationsTest.java#L435-L438
For 2.7.x, there are a few things missing for correctly handling CloseSequence.
So, I need to look at it to see if it's worth a while to fix this handling.
regards, aki
> 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)
