Using the JCA flow, JBI exchanges can not be lost if they are configured to be persistent (set the persistent="true" on the jbi container). The JCA flow uses XA transactions, the transaction will be commited only when the component has answered (if the exchange is active). Current standard JBI components never rollback the transaction, so that if the component fail to process the exchange, the exchange may be reported back with an ERROR, or fault status.
On the binding side, once the exchange has been sent to the JCA flow, it should be safe to assume that it will be delivered to the provider component. However you may still have duplicates (if the server / client crashes between the time the jms message has been sent and the tcp acks the response). Wrt to the use of the SEDA flow, if a component which receives an exchange from the JCA flow sends a new exchange using sendSync, the transaction will be conveyed by the SEDA flow so that the provider component (or any component after this one) may eventually mark the transaction as rollback or report a fault or error. In all cases, if the server crashes or if the transaction is rolled back, the exchange will be redelivered by the ActiveMQ broker used by the JCA flow. spelletier wrote: > > Thanks for your reply Guillaume, my previous scenario on which were based > my questions was actually not as good as I thought in the context of > trying to understand transactions/persistence in ServiceMix, so let's say > that instead of an HTTP binding we have a "home made" TCP binding that > receives an xml message from a TCP client and sends back an OK ACK byte > sequence to the TCP client as soon as it is sure the xml message received > by the TCP Binding has no chance to be lost (TCP client just post messages > to ServiceMix, no request/reply), or a ERROR ACK if an error occurs while > the TCP binding process the message or if it is not able to put the > message on the NMR, the TCP client will not discard the xml message before > receiving the OK ACK byte sequence from the TCP binding, resending the > message if necessary. > > TCP-Binding ---|Q1|---> Router eip ---|Q2|---> xslt ---|Q3|---> > HTTP-Provider ----> External Web Service > > |Q| = internal JMS (ActiveMQ) queue used by the JCA flow > > So my assumption here is that, using the JCA flow, it would be safe for > the TCP-Binding to send an OK ACK back to the TCP Client as soon as the > TCP-Binding succesfully sends a MessageExchange to the Router eip i.e. if > send(InOnly) succeed (no exception thrown), we have the guarantee that the > messageExchange was successfully posted in |Q1|. Is that assumption true? > > If true, from that point, now we need to make sure that we never lose the > message in |Q1|. Does the message in |Q1| will be removed from the queue > after the TCP-Binding process the DONE MessageExchange from Router eip, > after Router eip sends back the DONE MessageExchange to the TCP-Binding > but before the TCP-Binding receives it, or after the Router eip > successfully sends the MessageExchange to xslt (message posted in |Q2|) > without having to wait for any DONE to be sent back to Router eip, of none > of the above? > > And once the message is in |Q3|, when will it be removed from |Q3|? Can > we have a guarantee that the MessageExchange in |Q3| will not be removed > until the HTTP-Provider sends a DONE message exchange back to xslt i.e. > after the call to the external web service successfully returns without > any error (the external web service doesn't return any value or we don't > care about the value returned)? > > Thanks again for helping me trying to clarify how transactions work in > ServiceMix! > > > gnodet wrote: >> >> First, HTTP is unreliable. This means that if something bad happen >> between the time the server receives the request and the client >> receives a response, the request will be lost. The only way to be >> fully reliable would be to use WS-RM which has not been implemented >> yet (we need to use CXF, Axis2, or implement our own for that). >> And for that to work correctly, the persistent store used by the WS-RM >> need to be enlisted in the same transaction used by the JCA flow to >> send the exchange to the HTTP BC. >> >> So, while you can use the JCA flow for processing an input >> HTTP message, the client may not never the response (if the >> socket has been closed for example). You would need to use >> an asynchronous pattern, where SMX would send the response >> by sending an HTTP request. In this case, you could rollback >> the transaction if the client did not answer with an HTTP 200 >> status code. Again, there are always point of failures: if the >> client receives the response, process it, but fail before having >> answered a 200, the server would assume the request has not >> been processed. So you would need duplicate message >> detection. >> >> So, even in this case, the solution is to use a robust WS-RM >> implementation with a persistent store. Or use JMS :) >> >> On 10/20/06, spelletier <[EMAIL PROTECTED]> wrote: >>> >>> In a scenario like: >>> >>> HTTP-Consumer ---> Content-based Router eip ----> xslt ----> >>> HTTP-Provider >>> -----> External Web Service >>> >>> If the JCA flow is used to transport the MessageExchange (with >>> transaction/persistence), when e.g. HTTP-Consumer sends a >>> MessageExchange to >>> the Content-based Router (InOnly through send() method), the message >>> will be >>> put in an internal queue (through the JCA flow) and then delivered to >>> the >>> Router eip. >>> >>> Assuming this is true, my first question is when that message will be >>> removed from the queue? After the Router eip sends a DONE reply message >>> to >>> the HTTP-Consumer but before the HTTP-Consumer receives it? After the >>> HTTP-Consumer receives the DONE message from the Router eip? And when >>> the >>> Router eip will send a DONE message to the HTTP-Consumer? Sometime >>> after >>> the send() method to xslt succeeded (no exception i.e. when through the >>> JCA >>> flow the message is sucessfully posted in the queue between the Router >>> eip >>> and the xslt) or after explicitely receiving the DONE message from the >>> xslt? >>> >>> Another related question is, if all components use the JCA flow and a >>> JMS >>> message (containing the MessageExchange) is posted in the internal queue >>> between xslt and HTTP-Provider, how can we make sure that the message is >>> not >>> removed from the queue until the external web service returns >>> successfully >>> (no soap fault, assuming the web service method doesn't return any value >>> or >>> that we don't care about the return value)? >>> >>> And if the JCA flow was only used between HTTP-Consumer and the Router >>> eip, >>> with e.g. SEDA flow for all the remaining components from Router eip to >>> external web service (let's assume for the purpose of the example that >>> all >>> components except HTTP-Consumer use sendSync), how can we guarantee that >>> we >>> don't lost the message until we have the confirmation that the call to >>> the >>> external web service succeeded and returned with no fault? >>> >>> Sorry for the long email :-), but the whole point is to try to better >>> understand the different transaction/persistence scenarios using one or >>> a >>> mix of different NMR flows combined with calls to web services hosted >>> outside ServiceMix. >>> >>> Thanks a lot! >>> -- >>> View this message in context: >>> http://www.nabble.com/NMR-Flows-%2B-transaction-persistence-tf2476584.html#a6906622 >>> Sent from the ServiceMix - User mailing list archive at Nabble.com. >>> >>> >> >> >> -- >> Cheers, >> Guillaume Nodet >> >> > > -- View this message in context: http://www.nabble.com/NMR-Flows-%2B-transaction-persistence-tf2476584.html#a6950549 Sent from the ServiceMix - User mailing list archive at Nabble.com.
