Peter Donald wrote:
On Fri, 2 Nov 2001 23:09, Ken Geis wrote:
I'm pretty sure what I propose below is how it should be. What I can't figure out is why this was outstanding. Did it truly not happen to anyone? I've tested the patch and it resolves the problem I was having.
I applied it but I am not sure why you are getting the exception. In theory the priority queue should never be empty at this point because you have just inserted a value into it.
Can you give a small test case that would cause the exception to be thrown ?
The exception happened because I misread the CronTimeTrigger docs and created a trigger for the year 2. If you add a trigger and it's scheduled to fire in the past, rescheduleEntry does not add it to m_priorityQueue.
I think my change is an appropriate change. Of course, another option would be to have rescheduleEntry return boolean whether the entry was scheduled or not (then deal with the return value.)
83,86c83,90 < if( entry == m_priorityQueue.peek() ) < { < synchronized( m_monitor ) { m_monitor.notify(); } < } ---
> try > { > if( entry == m_priorityQueue.peek() ) > { > synchronized( m_monitor ) { m_monitor.notify(); } > } > } > catch( final NoSuchElementException nse ) {}
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
