PS can you please raise a JIRA? Paul
On 3/16/07, Paul Fremantle <[EMAIL PROTECTED]> wrote:
Gerald Interesting. Thanks for testing this! 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. Paul On 3/16/07, Gerald Loeffler <[EMAIL PROTECTED]> wrote: > hi all, > > further to this, 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?) > > cheers, > gerald > > > On 12/03/07, Paul Fremantle <[EMAIL PROTECTED]> wrote: > > Gerald > > > > Sure. > > > > Are you using 0.91 or the latest build? > > > > In 0.91 you need to do this: > > <proxies> > > <proxy name="RMProxy" transports="http" description="A simple RM > > endpoint"> > > <target endpoint="jmsEndpoint"/> > > <enableRM/> > > </proxy> > > </proxies> > > > > <definitions> > > <endpoint name="jmsEndpoint" address="jms://localhost:blah" > > force="pox"/> > > </definitions> > > > > Its been updated in the latest trunk. > > > > Paul > > > > On 3/12/07, Gerald Loeffler <[EMAIL PROTECTED]> wrote: > > > Paul, > > > > > > On 12/03/07, Paul Fremantle <[EMAIL PROTECTED]> wrote: > > > > I think in general it is more likely that you would use one way flows > > > > between HTTP and JMS, or use SOAP together with RM. Otherwise it seems > > > > to me that the HTTP might well timeout and without RM you cannot > > > > resend the response after the client has timed out. > > > > > > I agree. Can i use WSRM guaranteed/exactly-once delivery on one-way > > > SOAP messages? This would allow me to > > > 1. reliably send a message via a one-way SOAP/HTTP request from the > > > client to synapse, > > > 2. then have synapse put the message onto a JMS queue > > > - without either synapse or the client waiting for the message to > > > actually be consumed from the JMS queue. > > > > > > cheers, > > > gerald > > > > > > > > > > > Paul > > > > > > > > On 3/12/07, Asankha C. Perera <[EMAIL PROTECTED]> wrote: > > > > > Hi Gerald > > > > > > i understand the message flow in sample 111 as follows: > > > > > > 1. client sends SOAP/HTTP request for the getQuote operation to the > > > > > > synapse proxy. This is an in-out operation and the client actually > > > > > > waits synchronously for the response. > > > > > > 2. the synapse proxy accepts this request message and routes it to > > > > > > SimpleStockQuoteService via JMS by posting a JMS message on the > > > > > > SimpleStockQuoteService queue. > > > > > > 3. the SimpleStockQuoteService accepts the request and replies > > > > > > synchronously with a response. But where is that reponse sent to? > > > > > When the request to the service was sent over JMS, Synapse created a > > > > > temporary Queue for the response message and awaits for it by blocking > > > > > > Since this service is invoked through JMS in this scenario, i would > > > > > > expect the response message to be sent to a JMS queue - but where is > > > > > > that queue configured? > > > > > > 4. assuming that the reponse message was put on a JMS queue, synapse > > > > > > must now listen on that queue. This is for the out-rule of synapse. I > > > > > > don't see how/where i could tell synapse to listen on a particular JMS > > > > > > queue for response messages from a service. > > > > > > 5. assuming that the response message was received by synapse from > > > > > > that JMS queue, the synapse proxy then puts that message into the > > > > > > SOAP/HTTP response for the initial SOAP/HTTP request > > > > > > 6. client receives the SOAP/HTTP response for his initial request > > > > > > (synchronously, in this example). > > > > > Yep, the rest is all correct and indeed works! On a separate note, the > > > > > JMS destinations for responses have been discussed on the Axis2 lists > > > > > recently and some JIRAs are pending for some enhancements. The current > > > > > version of the JMS transport is the first cut implementation and now its > > > > > time to enhance it to cater to scenarios such as this > > > > > > there seems to be a missing link here somewhere that handles the > > > > > > translation from *one* request/response pair in SOAP/HTTP to *two* > > > > > > queues (input and output) for the JMS transport. The root problem is > > > > > > that the SOAP operation invoked by the client is an in-out operation. > > > > > > I could imagine that the synapse proxy needs to inserts a WSA reply-to > > > > > > header with a JMS-address before sending the request to the > > > > > > SimpleStockQuoteService... > > > > > > > > > > > > please help me solve this mystery! ;-) > > > > > > > > > > > > kind regards, > > > > > > gerald > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > -- > > > > Paul Fremantle > > > > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair > > > > > > > > http://bloglines.com/blog/paulfremantle > > > > [EMAIL PROTECTED] > > > > > > > > "Oxygenating the Web Service Platform", www.wso2.com > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > -- > > > http://www.gerald-loeffler.net > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > -- > > Paul Fremantle > > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair > > > > http://bloglines.com/blog/paulfremantle > > [EMAIL PROTECTED] > > > > "Oxygenating the Web Service Platform", www.wso2.com > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > http://www.gerald-loeffler.net > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Paul Fremantle VP/Technology, WSO2 and OASIS WS-RX TC Co-chair http://bloglines.com/blog/paulfremantle [EMAIL PROTECTED] "Oxygenating the Web Service Platform", www.wso2.com
-- Paul Fremantle VP/Technology, WSO2 and OASIS WS-RX TC Co-chair http://bloglines.com/blog/paulfremantle [EMAIL PROTECTED] "Oxygenating the Web Service Platform", www.wso2.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
