You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@synapse.apache.org by "Gerald Loeffler (JIRA)" <ji...@apache.org> on 2007/03/16 12:33:09 UTC
[jira] Created: (SYNAPSE-72) end-to-end
reliability/transactionality for proxying messages
end-to-end reliability/transactionality for proxying messages
-------------------------------------------------------------
Key: SYNAPSE-72
URL: https://issues.apache.org/jira/browse/SYNAPSE-72
Project: Synapse
Issue Type: New Feature
Components: Core
Affects Versions: 0.91
Reporter: Gerald Loeffler
i'm using a proxy to accept SOAP/WSRM/HTTP messages and send them on to a JMS endpoint:
<proxy name="RMProxy" transports="http">
<target endpoint="jmsEndpoint"/>
<enableRM/>
</proxy>
<definitions>
<endpoint name="jmsEndpoint" address="jms://localhost:blah" force="pox"/>
</definitions>
i see the following behaviour:
after the proxy received an SOAP/HTTP message containing WS-RM headers
from the client, it acknowledges the receipt of that message to
Sandesha. The proxy then attempts to send the message over the JMS
endpoint. If that endpoint is down, however, an exception is triggered
and the proxy basically drops the message. Since the message has
already been acknowledged to the client, the client will not try to
re-send it.
now this begs the obvious questions:
- how can i configure acknowledgement behaviour of a proxy? can i
get the proxy to only acknowledge the message receipt to Sandesha
after sending it on?
- is there any concept of transactions in Synapse? could the
combination of message accept/send described above be executed within
one transaction (e.g. by connecting to a configurable transaction
manager and have the Synapse proxy to the begin/commit/rollback with
that transaction manager?)
Paul replied:
---------------------------------------
There are two ways we can work this. One expects Synapse to have a
resilient store and transactions, the other expects us to simply
bridge the transactions from different systems.
The first approach is that Sandesha stores the message in a persistent
store when it arrives. Then it attempts to deliver the message. It
should only unpersist the message from the store when that "delivery"
works. In your case the attempt to send on with cause an exception and
we should roll back the delete from the store. This means that we need
the Sandesha delivery thread to start a transaction, and Synapse to
mark the transaction as failed.
To make this really work, we need some kind of smart retry handling.
In other words, we don't want to retry endlessly to that endpoint. We
need to backoff exponentially and also have a max retry count. In case
we hit the max retry - what should the behaviour be? Should we keep
accepting incoming messages and storing them?
The second approach requires more changes to Sandesha. In this model
we don't ack to the client until JMS acks to us. In other words we
don't need to store the messages persistently - we simply bridge JMS
acks back to the client. This is a neater solution in one way. We
still need a persistent store for the RM sequence information, but
that is pretty small (one row per open sequence). So this model is
much more suitable for a router or gateway that might be in the DMZ
and have a limited storage.
---------------------------------------
--
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: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org
[jira] Resolved: (SYNAPSE-72) end-to-end
reliability/transactionality for proxying messages
Posted by "Asankha C. Perera (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SYNAPSE-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Asankha C. Perera resolved SYNAPSE-72.
--------------------------------------
Resolution: Later
Fix Version/s: 1.1
I do not think we could do this in the 1.0 timeframe - hence marking this for attention post 1.0
> end-to-end reliability/transactionality for proxying messages
> -------------------------------------------------------------
>
> Key: SYNAPSE-72
> URL: https://issues.apache.org/jira/browse/SYNAPSE-72
> Project: Synapse
> Issue Type: New Feature
> Components: Core
> Affects Versions: 0.91
> Reporter: Gerald Loeffler
> Fix For: 1.1
>
>
> i'm using a proxy to accept SOAP/WSRM/HTTP messages and send them on to a JMS endpoint:
> <proxy name="RMProxy" transports="http">
> <target endpoint="jmsEndpoint"/>
> <enableRM/>
> </proxy>
> <definitions>
> <endpoint name="jmsEndpoint" address="jms://localhost:blah" force="pox"/>
> </definitions>
> i see the following behaviour:
> after the proxy received an SOAP/HTTP message containing WS-RM headers
> from the client, it acknowledges the receipt of that message to
> Sandesha. The proxy then attempts to send the message over the JMS
> endpoint. If that endpoint is down, however, an exception is triggered
> and the proxy basically drops the message. Since the message has
> already been acknowledged to the client, the client will not try to
> re-send it.
> now this begs the obvious questions:
> - how can i configure acknowledgement behaviour of a proxy? can i
> get the proxy to only acknowledge the message receipt to Sandesha
> after sending it on?
> - is there any concept of transactions in Synapse? could the
> combination of message accept/send described above be executed within
> one transaction (e.g. by connecting to a configurable transaction
> manager and have the Synapse proxy to the begin/commit/rollback with
> that transaction manager?)
> Paul replied:
> ---------------------------------------
> There are two ways we can work this. One expects Synapse to have a
> resilient store and transactions, the other expects us to simply
> bridge the transactions from different systems.
> The first approach is that Sandesha stores the message in a persistent
> store when it arrives. Then it attempts to deliver the message. It
> should only unpersist the message from the store when that "delivery"
> works. In your case the attempt to send on with cause an exception and
> we should roll back the delete from the store. This means that we need
> the Sandesha delivery thread to start a transaction, and Synapse to
> mark the transaction as failed.
> To make this really work, we need some kind of smart retry handling.
> In other words, we don't want to retry endlessly to that endpoint. We
> need to backoff exponentially and also have a max retry count. In case
> we hit the max retry - what should the behaviour be? Should we keep
> accepting incoming messages and storing them?
> The second approach requires more changes to Sandesha. In this model
> we don't ack to the client until JMS acks to us. In other words we
> don't need to store the messages persistently - we simply bridge JMS
> acks back to the client. This is a neater solution in one way. We
> still need a persistent store for the RM sequence information, but
> that is pretty small (one row per open sequence). So this model is
> much more suitable for a router or gateway that might be in the DMZ
> and have a limited storage.
> ---------------------------------------
--
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: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org