Details

Description

A recently added robust-inonly mode (CXF-4096) can be used to invoke services synchronously so that the caller can distinguish a successful invocation from an unsuccessful one.

Although this feature is implemented independently of WS-RM, it can be used with WS-RM to force the acknowledgement message to be returned only after the service invocation successfully completes.

Unfortunately, there is a minor change required in WS-RM so that this feature will work for this use case. Namely, it must be made aware of this robust setting so that it can postpone updating the sequence until the message is delivered.

Activity

This is probably the way all WS-RM processing should work, so that messages are only acknowledged once they've been delivered to the application and processed. The current code appears to allow a timing window where a crash would mean the message has been accepted and acknowledged by RM processing but is never seen by the application.

It looks like all that needs to be done for 2.5.x+ is to remove the call to destination.acknowledge() from RMInInterceptor.processSequence() and instead call it from RMDeliveryInterceptor.handle() (before the call to processingComplete()).

Dennis Sosnoski
added a comment - 06/Mar/12 00:10 This is probably the way all WS-RM processing should work, so that messages are only acknowledged once they've been delivered to the application and processed. The current code appears to allow a timing window where a crash would mean the message has been accepted and acknowledged by RM processing but is never seen by the application.
It looks like all that needs to be done for 2.5.x+ is to remove the call to destination.acknowledge() from RMInInterceptor.processSequence() and instead call it from RMDeliveryInterceptor.handle() (before the call to processingComplete()).

This is an option for not losing messages at Destination. For many applications, this option will be sufficient. For those which expect an asynchronous decoupling of the message transport to the service invocation, this will be insufficient and we will still need a message storage and a re-delivery logic from the storage, which is currently missing.

So, I will be adding to this ticket an optimization change to avoid persisting the messages at Destination for the robust-mode. Currently, the messages are always persisted independently of the mode.

Akitoshi Yoshida
added a comment - 13/Mar/12 12:55 Hi Dennis,
As I mentioned in my reply on dev@cxf at
http://cxf.547215.n5.nabble.com/Re-svn-commit-r1297370-in-cxf-branches-2-5-x-fixes-rt-ws-rm-src-main-java-org-apache-cxf-ws-rm-syste-td5540174.html
This is an option for not losing messages at Destination. For many applications, this option will be sufficient. For those which expect an asynchronous decoupling of the message transport to the service invocation, this will be insufficient and we will still need a message storage and a re-delivery logic from the storage, which is currently missing.
So, I will be adding to this ticket an optimization change to avoid persisting the messages at Destination for the robust-mode. Currently, the messages are always persisted independently of the mode.
regards, aki