1 2 3 4 Previous Next 49 Replies Latest reply on Oct 26, 2006 10:13 AM by clebert.suconic Go to original post
      • 45. Re: Client failover redeliveries discussion
        ovidiu.feodorov

         

        Tim wrote:
        I don't think you need to copy anything - just re-use the old one.


        You're right here.

        • 46. Re: Client failover redeliveries discussion
          ovidiu.feodorov

           

          Tim wrote:

          Still makes no sense.
          What's the point of sending an ack that's just going to be ignored?
          It's much easier to just not send it in the first place, you can still process the np messages in the client buffer, just completely pointless to send acks to the server for them.


          Because we are not going to modify the client code to NOT send acknowledgments for messages being delivered. The acknowledgment-sending portion of the client-side aspect stack is "unaware" that it just went through a failover and it will dully continue to behave as designed, i.e. sending acknowledgments for messages being consumed. It's the secondary server job to realize that the acknowledgments arriving for deliveries it actually does not have (or better said, did not create by actually sending messages) are legit, and are generated by "salvaged" non-persistent messages.

          Does it make sense?

          • 47. Re: Client failover redeliveries discussion
            timfox

             

            "ovidiu.feodorov@jboss.com" wrote:


            Because we are not going to modify the client code to NOT send acknowledgments for messages being delivered. The acknowledgment-sending portion of the client-side aspect stack is "unaware" that it just went through a failover and it will dully continue to behave as designed, i.e. sending acknowledgments for messages being consumed. It's the secondary server job to realize that the acknowledgments arriving for deliveries it actually does not have (or better said, did not create by actually sending messages) are legit, and are generated by "salvaged" non-persistent messages.

            Does it make sense?


            That's a poor solution.

            So you're going to send unnecessary traffic across the network, plus add fiddly code on the server side to create deliveries for non existent non persistent messages just to avoid changing a few lines of code on the client side?


            • 48. Re: Client failover redeliveries discussion
              ovidiu.feodorov

              :)

              I am at least happy that you finally give a chance to the non-persistent messages.

              And sure, there are always better solutions. We can continue to talk about that.

              • 49. Re: Client failover redeliveries discussion
                clebert.suconic

                 

                Ovidiu wrote:
                To spell this out for you, so you won't go over is again: The current code, that is in the SVN, does not behave this way. This is understandable, it's just a prototype. I was going over the use cases for which we need test cases, so we can make sure the correct behavior is preserved in the future. The correct behavior is "transparently copying the transactional state (the corresponding TxState instance) into the new ResourceManager and send the messages over the new connection when transaction commits." Please note the use of the word "transparent".


                The Transaction still has any pending transaction on its buffer when a connection is failed over.

                The code it's not a prototype IMO, it's one of the layers of the failover and currently I'm not considering the first layer yet. I have started from the second layer as when we started we were not sure what was going to happen with Remoting. I want to finish this layer now before starting on the first layer.

                1 2 3 4 Previous Next