4 Replies Latest reply on Oct 24, 2009 1:27 PM by clebert.suconic

    Referencing counting for large messages

    timfox

      I'm trying to understand why large messages need to have the reference count incremented to prevent them being deleted. (See ServerConsumerImpl)

      I understand from the comments that this is done to prevent deletion, but the mechanism is not explained in any detail.

      Clebert- can you explain why not incrementing the ref count for a large message would cause it to get deleted prematurely?

      Why is a large message any different from a normal message?

        • 1. Re: Referencing counting for large messages
          clebert.suconic


          LargeMessage is using the reference counting to determine when to delete the file associated.

          The user might ACK the message as soon as the first packet arrived on the client. As soon as the ACK arrived to the server the durableRefCount would be 0 and therefore I wouldn't be able to send any more packets to the client.

          Because of that the LargeMessageDeliverer will hold to a reference until the deliver process is completed. This way I'm sure the file associated with the large message will exist for the entire deliver process.

          • 2. Re: Referencing counting for large messages
            clebert.suconic

            I meant.. the refCount itself (not the durable one).


            A LargeMessage could also be "non-durable". A non-durable largeMessage would have the file associated but not be associated to any journal.

            • 3. Re: Referencing counting for large messages
              timfox

              So... if you're increasing the ref count, then the client acks the message, but you don't actually delete the message then, when do you actually process the ack?

              • 4. Re: Referencing counting for large messages
                clebert.suconic

                The delete on the journal is controlled by the durableRefCount, while the delete of the file is controlled by the refCount.


                The ACK process is no different.