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.
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.
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?
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.