You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fx-dev@ws.apache.org by "Matt Lovett (JIRA)" <ji...@apache.org> on 2006/11/09 12:37:37 UTC
[jira] Created: (SANDESHA2-42) Restructure outbound message path
Restructure outbound message path
---------------------------------
Key: SANDESHA2-42
URL: http://issues.apache.org/jira/browse/SANDESHA2-42
Project: Apache Sandesha2
Issue Type: Improvement
Reporter: Matt Lovett
I don't think that the sandesha transport adds any capability to the code, and it complicates the outbound processing path. I think we should be able to remove it, and be a little more careful about how we pause and resume the message context on its way out.
I plan to attach a patch later on today
Matt
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
[jira] Commented: (SANDESHA2-42) Restructure outbound message path
Posted by "Matt Lovett (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/SANDESHA2-42?page=comments#action_12448704 ]
Matt Lovett commented on SANDESHA2-42:
--------------------------------------
Hi Chamikara,
I see what you are saying, but I don't think that is the correct way to address the issue. We already know that you cannot just go to the final envelope at the time the message is inserted into the store - because WS-Security may insert time-dependent headers, so we cannot simply retransmit the message. I think that security is currently handled as a special case, but with this change we could handle any downstream handler.
The cost, as you noted, is that we need to serialise more of the message context. I think this has been an ongoing discussion on the Axis2 list. My opinion is that 90% of the message context can be rebuilt from the application config, and so the overhead is relatively small. I think it's a fair price to pay for a clean solution.
Perhaps we should see what happens in Axis2, and apply this patch as and when message context serialisation goes into the codebase.
The axis2 issue is here: https://issues.apache.org/jira/browse/AXIS2-1567
Matt
> Restructure outbound message path
> ---------------------------------
>
> Key: SANDESHA2-42
> URL: http://issues.apache.org/jira/browse/SANDESHA2-42
> Project: Apache Sandesha2
> Issue Type: Improvement
> Reporter: Matt Lovett
> Attachments: transport.patch
>
>
> I don't think that the sandesha transport adds any capability to the code, and it complicates the outbound processing path. I think we should be able to remove it, and be a little more careful about how we pause and resume the message context on its way out.
> I plan to attach a patch later on today
> Matt
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
[jira] Closed: (SANDESHA2-42) Restructure outbound message path
Posted by "Matt Lovett (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SANDESHA2-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Matt Lovett closed SANDESHA2-42.
--------------------------------
Resolution: Invalid
This Jira is made obsolete by the option to use MessageContext serialization in Sandesha - when that option is enabled we avoid using the Sandesha transport.
> Restructure outbound message path
> ---------------------------------
>
> Key: SANDESHA2-42
> URL: https://issues.apache.org/jira/browse/SANDESHA2-42
> Project: Sandesha2
> Issue Type: Improvement
> Reporter: Matt Lovett
> Attachments: transport.patch
>
>
> I don't think that the sandesha transport adds any capability to the code, and it complicates the outbound processing path. I think we should be able to remove it, and be a little more careful about how we pause and resume the message context on its way out.
> I plan to attach a patch later on today
> Matt
--
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: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
[jira] Commented: (SANDESHA2-42) Restructure outbound message path
Posted by "Chamikara Jayalath (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/SANDESHA2-42?page=comments#action_12449073 ]
Chamikara Jayalath commented on SANDESHA2-42:
---------------------------------------------
Yep. Thats better. Lets wait a bit till we have an alternate way to do this.
One more thing. The downstream handlers may be dependent on the information present in other contexts as well. So we will have to make sure that we serielize and deserialize the nessary information of all the related contexts (not just the message context). Hope Anns solution addresses this as well.
Chamikara
> Restructure outbound message path
> ---------------------------------
>
> Key: SANDESHA2-42
> URL: http://issues.apache.org/jira/browse/SANDESHA2-42
> Project: Apache Sandesha2
> Issue Type: Improvement
> Reporter: Matt Lovett
> Attachments: transport.patch
>
>
> I don't think that the sandesha transport adds any capability to the code, and it complicates the outbound processing path. I think we should be able to remove it, and be a little more careful about how we pause and resume the message context on its way out.
> I plan to attach a patch later on today
> Matt
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
[jira] Commented: (SANDESHA2-42) Restructure outbound message path
Posted by "Matt Lovett (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/SANDESHA2-42?page=comments#action_12448704 ]
Matt Lovett commented on SANDESHA2-42:
--------------------------------------
Hi Chamikara,
I see what you are saying, but I don't think that is the correct way to address the issue. We already know that you cannot just go to the final envelope at the time the message is inserted into the store - because WS-Security may insert time-dependent headers, so we cannot simply retransmit the message. I think that security is currently handled as a special case, but with this change we could handle any downstream handler.
The cost, as you noted, is that we need to serialise more of the message context. I think this has been an ongoing discussion on the Axis2 list. My opinion is that 90% of the message context can be rebuilt from the application config, and so the overhead is relatively small. I think it's a fair price to pay for a clean solution.
Perhaps we should see what happens in Axis2, and apply this patch as and when message context serialisation goes into the codebase.
The axis2 issue is here: https://issues.apache.org/jira/browse/AXIS2-1567
Matt
> Restructure outbound message path
> ---------------------------------
>
> Key: SANDESHA2-42
> URL: http://issues.apache.org/jira/browse/SANDESHA2-42
> Project: Apache Sandesha2
> Issue Type: Improvement
> Reporter: Matt Lovett
> Attachments: transport.patch
>
>
> I don't think that the sandesha transport adds any capability to the code, and it complicates the outbound processing path. I think we should be able to remove it, and be a little more careful about how we pause and resume the message context on its way out.
> I plan to attach a patch later on today
> Matt
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
[jira] Updated: (SANDESHA2-42) Restructure outbound message path
Posted by "Matt Lovett (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/SANDESHA2-42?page=all ]
Matt Lovett updated SANDESHA2-42:
---------------------------------
Attachment: transport.patch
As described above, this patch removes the sandesha transport, which means that we need to do less tweaking of phases & transports as the messages head outbound.
> Restructure outbound message path
> ---------------------------------
>
> Key: SANDESHA2-42
> URL: http://issues.apache.org/jira/browse/SANDESHA2-42
> Project: Apache Sandesha2
> Issue Type: Improvement
> Reporter: Matt Lovett
> Attachments: transport.patch
>
>
> I don't think that the sandesha transport adds any capability to the code, and it complicates the outbound processing path. I think we should be able to remove it, and be a little more careful about how we pause and resume the message context on its way out.
> I plan to attach a patch later on today
> Matt
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
[jira] Commented: (SANDESHA2-42) Restructure outbound message path
Posted by "Chamikara Jayalath (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/SANDESHA2-42?page=comments#action_12448664 ]
Chamikara Jayalath commented on SANDESHA2-42:
---------------------------------------------
Hi Matt,
There was a need for the Sandesha2TransportSender but it'll be reflected only when a PersistentStorageManager is present :-( .
Because of this Sandesha2TransportSender Sandesha2 always saves the final SOAP envelope (which has gone through all the outFlow handlers) in its database. In retransmissions Sender can directly feed this to the actual Transport Sender.
If we remove this we will be storing envelopes which have only gone through a half of the outFlow handlers. We will have to send them throgh the rest of the handlers in every retransmission and we will have to serialize the whole context hierarchy to make sure that the process work correctly.
Chamikara
> Restructure outbound message path
> ---------------------------------
>
> Key: SANDESHA2-42
> URL: http://issues.apache.org/jira/browse/SANDESHA2-42
> Project: Apache Sandesha2
> Issue Type: Improvement
> Reporter: Matt Lovett
> Attachments: transport.patch
>
>
> I don't think that the sandesha transport adds any capability to the code, and it complicates the outbound processing path. I think we should be able to remove it, and be a little more careful about how we pause and resume the message context on its way out.
> I plan to attach a patch later on today
> Matt
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
[jira] Commented: (SANDESHA2-42) Restructure outbound message path
Posted by "Chamikara Jayalath (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/SANDESHA2-42?page=comments#action_12448664 ]
Chamikara Jayalath commented on SANDESHA2-42:
---------------------------------------------
Hi Matt,
There was a need for the Sandesha2TransportSender but it'll be reflected only when a PersistentStorageManager is present :-( .
Because of this Sandesha2TransportSender Sandesha2 always saves the final SOAP envelope (which has gone through all the outFlow handlers) in its database. In retransmissions Sender can directly feed this to the actual Transport Sender.
If we remove this we will be storing envelopes which have only gone through a half of the outFlow handlers. We will have to send them throgh the rest of the handlers in every retransmission and we will have to serialize the whole context hierarchy to make sure that the process work correctly.
Chamikara
> Restructure outbound message path
> ---------------------------------
>
> Key: SANDESHA2-42
> URL: http://issues.apache.org/jira/browse/SANDESHA2-42
> Project: Apache Sandesha2
> Issue Type: Improvement
> Reporter: Matt Lovett
> Attachments: transport.patch
>
>
> I don't think that the sandesha transport adds any capability to the code, and it complicates the outbound processing path. I think we should be able to remove it, and be a little more careful about how we pause and resume the message context on its way out.
> I plan to attach a patch later on today
> Matt
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
[jira] Commented: (SANDESHA2-42) Restructure outbound message path
Posted by "Chamikara Jayalath (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/SANDESHA2-42?page=comments#action_12449073 ]
Chamikara Jayalath commented on SANDESHA2-42:
---------------------------------------------
Yep. Thats better. Lets wait a bit till we have an alternate way to do this.
One more thing. The downstream handlers may be dependent on the information present in other contexts as well. So we will have to make sure that we serielize and deserialize the nessary information of all the related contexts (not just the message context). Hope Anns solution addresses this as well.
Chamikara
> Restructure outbound message path
> ---------------------------------
>
> Key: SANDESHA2-42
> URL: http://issues.apache.org/jira/browse/SANDESHA2-42
> Project: Apache Sandesha2
> Issue Type: Improvement
> Reporter: Matt Lovett
> Attachments: transport.patch
>
>
> I don't think that the sandesha transport adds any capability to the code, and it complicates the outbound processing path. I think we should be able to remove it, and be a little more careful about how we pause and resume the message context on its way out.
> I plan to attach a patch later on today
> Matt
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
[jira] Updated: (SANDESHA2-42) Restructure outbound message path
Posted by "Matt Lovett (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/SANDESHA2-42?page=all ]
Matt Lovett updated SANDESHA2-42:
---------------------------------
Attachment: transport.patch
As described above, this patch removes the sandesha transport, which means that we need to do less tweaking of phases & transports as the messages head outbound.
> Restructure outbound message path
> ---------------------------------
>
> Key: SANDESHA2-42
> URL: http://issues.apache.org/jira/browse/SANDESHA2-42
> Project: Apache Sandesha2
> Issue Type: Improvement
> Reporter: Matt Lovett
> Attachments: transport.patch
>
>
> I don't think that the sandesha transport adds any capability to the code, and it complicates the outbound processing path. I think we should be able to remove it, and be a little more careful about how we pause and resume the message context on its way out.
> I plan to attach a patch later on today
> Matt
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
[jira] Closed: (SANDESHA2-42) Restructure outbound message path
Posted by "Matt Lovett (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SANDESHA2-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Matt Lovett closed SANDESHA2-42.
--------------------------------
Resolution: Invalid
This Jira is made obsolete by the option to use MessageContext serialization in Sandesha - when that option is enabled we avoid using the Sandesha transport.
> Restructure outbound message path
> ---------------------------------
>
> Key: SANDESHA2-42
> URL: https://issues.apache.org/jira/browse/SANDESHA2-42
> Project: Sandesha2
> Issue Type: Improvement
> Reporter: Matt Lovett
> Attachments: transport.patch
>
>
> I don't think that the sandesha transport adds any capability to the code, and it complicates the outbound processing path. I think we should be able to remove it, and be a little more careful about how we pause and resume the message context on its way out.
> I plan to attach a patch later on today
> Matt
--
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: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org