Dispatch phase optimizations can prevent Sandesha from using the back-channel
for acks
--------------------------------------------------------------------------------------
Key: AXIS2-2191
URL: https://issues.apache.org/jira/browse/AXIS2-2191
Project: Axis 2.0 (Axis2)
Issue Type: Bug
Components: kernel
Reporter: Matt Lovett
Chamikara and I have been disussing this issue on the sandesha-dev list.
Essentially there is code in the DispatchPhase (around line 71) that sends a
HTTP 202 back if the message is 1-way, or if it is 2-way with an async replyTo.
However, there are cases when the WS-RM layer needs to write a SequenceAck
message into the backchannel, and this code is running before we get the chance
to try. We cannot move our logic earlier, as we need the dispatch phase to have
resolved the MEP before we can make the decision.
The only way forward we can see is to define a new constant, and avoid the code
in DispatchPhase when the constant is set. When RM is enabled we will set the
value onto the ConfigurationContext at the time that Sandesha is engaged. From
then on the Sandesha handlers will take the responsibility - returning the HTTP
202 as soon as possible if we do not need the backchannel.
Here's a proposal for the new constant name:
// If this property is set to Boolean.TRUE then the Dispatch Phase should not
try so send an early
// transport-level ack back. Downstream handlers are expected to send an
transport-level ack as
// soon as they are sure that the transport level ack may be sent.
org.apache.axis2.Constants.Configuration.DEFER_TRANSPORT_ACKNOWLEDGEMENT =
"deferTransportAcks";
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
