synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Asankha C. Perera (JIRA)" <>
Subject [jira] Resolved: (SYNAPSE-72) end-to-end reliability/transactionality for proxying messages
Date Tue, 27 Mar 2007 19:35:32 GMT


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

> end-to-end reliability/transactionality for proxying messages
> -------------------------------------------------------------
>                 Key: SYNAPSE-72
>                 URL:
>             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:
For additional commands, e-mail:

View raw message