Hi Lars, On Mon, Feb 27, 2012 at 3:55 PM, Lars-Erik Helander <[email protected]>wrote:
> Hi Ruwan > > Thank you very much for the answer. It provided exactly the type of > information I was looking for. > Thanks, and you're welcome. > > Regarding: > >There is a case where this could fail too, if Synapse fails or crashes > > after receiving the signals like ACK etc from the back-end server, before > > sending the same back to the client, in this case the resend should be > > discarded from the server and completes the transaction. > > I guess that synapse (when it has recovered) is not aware of the > history, but will be able to pick up according to the resends > initiated by the client, correct ? > Yes. > > The back-end server needs to be able to reproduce any previously sent > ACKs, either by being idempotent or in some other way deal with this > "internally". > I think WS-RM should take care of it, if the sequence acknowledgement is not acked within the timeout from the client (in this case synapse), it should (I mean the back-end server should) re-send the sequence acknowledgement after the timeout per the spec, IIRC. (I am not quite sure about the behaviour and it depends on the implementation that you are using) > I also guess that you might be able to manage the necessary persitency > for these ACKs by having a persistent queue in the flow between the > back-end server and synapse, but that would require some explicit > logic for this in the synapse in/out-sequences. > Yes, and that logic might get complicated when you want to handle all possible cases. One of the design principals for Synapse core is that we treated it as a dumb proxy which does what user instructs via its configuration and only that. So this sort of a logic needs to be custom developed, and that require a little bit depth of Synapse/Axis2 as well as RM. Thanks, Ruwan > > > Thanks > > Lars > 2012/2/27 Ruwan Linton <[email protected]>: > > Hi Lars, > > > > First of all sorry for the late reply. > > > > On Sun, Feb 19, 2012 at 7:35 PM, Lars-Erik Helander <[email protected] > >wrote: > > > >> Hi, > >> I have a client and service that both are RM enabled. I want to put > >> Synapse in between the two to perform some transformation of the message > >> data, but wants to keep the RM characteristics of the exchange. > >> > >> Is this possible? > >> > > > > Yes. > > > > > >> Do I have to explicitly enable RM on the Proxy Service and Endpoint in > >> Synapse, or do Synapse by default pass on the RM related info between > the > >> client and the service? > >> > > > > You have to explicitly set RM at both ends, i.e. on the proxy service as > > well as on the endpoint. Default behaviour of Synapse is to assume that > the > > RM is terminated at the receiving side, unless otherwise specified for > the > > out going endpoint too. > > > > > >> > >> If I enable RM on the proxy and endpoint (which I guess will create two > >> different RM associations: client <-> synapse and synapse <-> service) > > > > > > You're correct. > > > > > >> is there a risk that the RM characteristics are violated compared to the > >> RM characteristics of a direct association between the client and > service? > >> > > > > As far as the complete transaction is concerned, it will not, as Synapse > > deals with the RM sequences etc and adheres to the specification on > > sequence messages and transaction initiation and termination as a proxy. > > However as you have figured out, the actual message transmission happens > in > > 2 transactions. > > > > The reliability is guaranteed as the sequence acknowledgement etc are > sent > > back to client only after getting the same from the back-end server etc > and > > if synapse failed to deliver the ACK within the timeout (could be due to > > failure in sending the request, or back-end server not being able to send > > back the ACK on-time) it is the responsibility of the client to resend > and > > so forth. > > > > So from the clients perspective it is giving an end-2-end reliability. > > There is a case where this could fail too, if Synapse fails or crashes > > after receiving the signals like ACK etc from the back-end server, before > > sending the same back to the client, in this case the resend should be > > discarded from the server and completes the transaction. > > > > Thanks, > > Ruwan > > > > > >> > >> Kind Regards > >> Lars > > > > > > > > > > -- > > Ruwan Linton > > Member, Apache Software Foundation; http://www.apache.org > > Director of Engineering; http://adroitlogic.org > > > > phone: +94 11 282 7532 > > email: [email protected]; cell: +94 77 341 3097 > > blog: http://blog.ruwan.org > > linkedin: http://www.linkedin.com/in/ruwanlinton > > google: http://www.google.com/profiles/ruwan.linton > > tweet: http://twitter.com/ruwanlinton > -- Ruwan Linton Member, Apache Software Foundation; http://www.apache.org Director of Engineering; http://adroitlogic.org phone: +94 11 282 7532 email: [email protected]; cell: +94 77 341 3097 blog: http://blog.ruwan.org linkedin: http://www.linkedin.com/in/ruwanlinton google: http://www.google.com/profiles/ruwan.linton tweet: http://twitter.com/ruwanlinton
