-
1. Re: message expiry
timfox Nov 25, 2008 10:45 AM (in response to ataylor)I don't like the idea of copying.
I'd recommend for now doing something like the following,
Maintain a ConcurrentHashSet of refs in the queue as well as the normal PriorityLinkedList.
As ref is added to queue, if it has a non zero expiry time then add it to that set too. On acknowledge remove from set too.
Then the expiry thread can iterate that set without any problems. -
2. Re: message expiry
ataylor Nov 25, 2008 10:48 AM (in response to ataylor)Ok, I'll also run some perf comparisons to see what effect it has
-
3. Re: message expiry
ataylor Nov 25, 2008 11:19 AM (in response to ataylor)would you expect the message order to be maintained in the dlq's if a number of messages expire at the same time?
-
4. Re: message expiry
timfox Nov 27, 2008 7:19 AM (in response to ataylor)A few comments on the latest commit:
1) Why do we needif (ref.getMessage().getExpiration() != 0) { expiringMessageReferences.addIfAbsent(ref); }
In method queueimpl::addlistfirst?
AddListFirst happens at rollback in which case the ref should already be in that set
2) QueueImpl:expireMessages. Why loop through the set twice - this can be done in a single iteration
3) don't type the LHS as a ConcurrentHashSet -bad practiceprivate final ConcurrentHashSet<MessageReference> expiringMessageReferences = new ConcurrentHashSet<MessageReference>();
4) If MessageExpiryRunner is put in postoffice (which seems a more natural place for it) then you don't need to add the getQueues method to PostOffice,
-
5. Re: message expiry
ataylor Nov 27, 2008 12:26 PM (in response to ataylor)ok, no probs, i'll sort it
-
6. Re: message expiry
ataylor Dec 2, 2008 11:35 AM (in response to ataylor)Ive done some performance testing with these changes and theres a 4% drop in throughput when every single message sent has the expiry time set.