james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: Handler timeout/trigger issues
Date Tue, 06 Aug 2002 22:23:51 GMT
Steve,

Would you please hookup with Paul Hammant about your changes?  As I
understand it, he is the current primary maintainer on Cornerstone, while
other Avalon developers are working on new things.  Earlier today he
mentioned that he'll have a new version for us soon.

	--- Noel

-----Original Message-----
From: Steve Short [mailto:sshort@postx.com]
Sent: Tuesday, August 06, 2002 14:39
To: James Developers List
Subject: RE: Handler timeout/trigger issues

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>


Mime
View raw message