james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Short" <ssh...@postx.com>
Subject RE: Handler timeout/trigger issues
Date Tue, 06 Aug 2002 18:39:09 GMT

We resolved this locally by changing the Cornerstone
DefaultTimeScheduler to always notify the monitor thread when entries
exist in the priority queue during methods addTrigger() &
rescheduleEntry().  Shilpa didn't submit a patch because the dicussion
in Avalon dev was leading to a different solution.

FWIW the change is 'if( entry == m_priorityQueue.peek() )' to 'if( null
!= m_priorityQueue.peek() )' in two places.  Diff available on request.

Cheers
Steve
System Architect
PostX Corporation
Tel: (408) 861 3540
Email: sshort@postx.com



> -----Original Message-----
> From: Noel J. Bergman [mailto:noel@devtech.com] 
> Sent: Tuesday, August 06, 2002 10:25 AM
> To: James Developers List
> Subject: Handler timeout/trigger issues
> 
> 
> > BTW. More than a year back there were problems with Avalon 
> > PeriodicTimeTrigger. It was apparently fixed. Here was an alternate 
> > implementation submitted.
> 
> James uses DefaultTimeScheduler, as you can see from the 
> assembly.xml file:
> 
>   <block 
> class="org.apache.avalon.cornerstone.blocks.scheduler.DefaultT
> imeScheduler"
>          name="scheduler">
> 
> The problems reported by Shilpa Dalmia are current, and were 
> discussed on both this list and the Avalon list just a couple 
> of months ago.
> 
> As for your scheduler, I checked the nighly build for 
> Cornerstone.  Your code has never been adopted into the 
> build.  I spoke with Paul Hammant today, who said that he'll 
> take a look at it.
> 
> However, it does not appear to me that your code resolves the 
> issue raised by Shilpa.  You do remove the task from your 
> task map, but
> TimerTask.cancel() simply marks the task as cancelled.  There 
> is still an accummulation of TimerTask objects in the Timer's 
> queue, which is the issue being raised in the first place.
> 
> FWIW, you have a minor bug in your exception handling.
> TimeSchedulerImpl.removeTrigger(String) is supposed to throw 
> an exception, but that code is only present in 
> TimeSchedulerImpl.removeTrigger(String).  I believe that this 
> would be correct:
> 
>     private Task remove( String name )
>         throws NoSuchElementException
>     {
>         Task task = (Task)taskMap.remove(name);
>         if ( task == null )
>             throw new NoSuchElementException(name);
>         task.cancel();
>         return task;
>     }
> 
>     public void removeTrigger( String name )
>         throws NoSuchElementException
>     {
>         remove(name);
>     }
> 
>     public void resetTrigger( String name )
>         throws NoSuchElementException
>     {
>         Task task = remove(name);
>         addTrigger(name,task.trigger,task.target);
>     }
> 
> > How does [timeout handling] relate to CommandMap. They
> > seem to be 2 topics, what is the association.
> 
> With my implementation of the CommandMap, you invoke a 
> command through the map.  One of the methods for invoking a 
> command supports a timeout.  That was the association.  Even 
> if we don't use the CommandMap, my approach for a lightweight 
> watchdog is probably something to adopt.
> 
> 	--- Noel
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:james-dev-> unsubscribe@jakarta.apache.org>
> For 
> additional commands, 
> e-mail: <mailto:james-dev-help@jakarta.apache.org>
> 
> 

--
To unsubscribe, e-mail:   <mailto:james-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@jakarta.apache.org>


Mime
View raw message