axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Srinath Perera (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (AXIS2-2191) Dispatch phase optimizations can prevent Sandesha from using the back-channel for acks
Date Fri, 15 Jun 2007 20:04:26 GMT

     [ https://issues.apache.org/jira/browse/AXIS2-2191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Srinath Perera resolved AXIS2-2191.
-----------------------------------

    Resolution: Fixed

remove the dispatch phase optimization from execuation  based o June 2007 F2F discussions

> 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
>            Assignee: Deepal Jayasinghe
>            Priority: Blocker
>
> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org


Mime
View raw message