Hi and thanks again :) >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 was not aware that the back-end server would be able to detect a flaw in the ACK path, but it sounds reasonable that it could do that. I need to learn more details about the WS-RM ;) Thanks Lars 2012/2/27 Ruwan Linton <[email protected]>: > 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
