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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
