You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by "Matt Lovett (JIRA)" <ji...@apache.org> on 2007/02/15 16:11:05 UTC
[jira] Created: (AXIS2-2191) Dispatch phase optimizations can
prevent Sandesha from using the back-channel for acks
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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Commented: (AXIS2-2191) Dispatch phase optimizations can
prevent Sandesha from using the back-channel for acks
Posted by "Deepal Jayasinghe (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-2191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473619 ]
Deepal Jayasinghe commented on AXIS2-2191:
------------------------------------------
+1 for the proposal.
Thanks
Deepal
> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Assigned: (AXIS2-2191) Dispatch phase optimizations can
prevent Sandesha from using the back-channel for acks
Posted by "Davanum Srinivas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-2191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Davanum Srinivas reassigned AXIS2-2191:
---------------------------------------
Assignee: Deepal Jayasinghe
> 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
> Assigned To: Deepal Jayasinghe
>
> 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
[jira] Resolved: (AXIS2-2191) Dispatch phase optimizations can
prevent Sandesha from using the back-channel for acks
Posted by "Srinath Perera (JIRA)" <ji...@apache.org>.
[ 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
[jira] Updated: (AXIS2-2191) Dispatch phase optimizations can
prevent Sandesha from using the back-channel for acks
Posted by "Amila Chinthaka Suriarachchi (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-2191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Amila Chinthaka Suriarachchi updated AXIS2-2191:
------------------------------------------------
Priority: Blocker (was: Major)
> 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