Thanks for the reply.
Here is why we raised this as an issue. The Apache James mail server project is using this timer mechanism to implement a connection timeout on the SMTP port. When it receives data on the the port, it calls resetTrigger to resets the timer. If the timeout is 5 minutes, and there is constant SMTP activity, I estimate that this could lead to 15,000 or more invalid timer entries in the queue. (10 message per second * 5 SMTP commands per message * 300 seconds). Regards Steve -----Original Message----- From: Peter Donald [mailto:[EMAIL PROTECTED]] Sent: Saturday, May 18, 2002 4:13 PM To: Steve Short Subject: Fwd: Re: DefaultTimeScheduler Notify Issue It got through the first time and here was my response ;) ---------- Forwarded Message ---------- Subject: Re: DefaultTimeScheduler Notify Issue Date: Sat, 18 May 2002 14:05:17 +1000 From: Peter Donald <[EMAIL PROTECTED]> To: "Avalon Developers List" <[EMAIL PROTECTED]> On Sat, 18 May 2002 03:21, Steve Short wrote: > In cornerstone/blocks/scheduler/DefaultTimeScheduler class the addTrigger() > & rescheduleEntry() methods notify the waiting thread only if the first > entry in the priorityqueue matches the current entry. > if( entry == m_priorityQueue.peek() ) > { > notifyAll(); > } > As a result of this, the waiting thread (the run() method) > synchronized( this ) { > wait( duration ); > } > does not get notified & does not get a chance to remove invalid entries > from the queue (old entries invalidated by rescheduleEntry() method) & the > queue keeps growing until the wait times out, the timeout value depending > on the value specified to the trigger. > > My question here is why don't these methods send a notify after it finds > any entry in the queue, so that the waiting thread gets a chance to clean > up all invalid entries? Or is there some other thread notifying this > thread? The idea was that you only needed to wakeup the monitor thread if the entry at the top of the heap changes. The reason being that the top entry on heap is always the next entry to run. Invalid entrys are only removed when they get to the top of the heap and we goto look at them. So even if we woke up the monitor thread it would not be able to delete invalid entrys unless the top entry happened to be invalidated. What this means is that there can possibly be lots of invalid entrys inside the heap if you schedule them far enough into future and keep rescheduling them. At one stage we were going to have a "reaper" thread that went through and removed all the invalidated entrys but it never got done as the worst case scenario (schedule in future then reschedule) is rare enough not to be an issue. -- Cheers, Peter Donald -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> ------------------------------------------------------- -- Cheers, Peter Donald -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
