Command ThreadManager and event queues (was RE: SEDA)

[Marc Schier <MS...@bsquare.com>]

Berin,

Could you do me a favor and please apply the attached patches. They fix that
the threadmanager's configuration cannot specify the block timeout of the
used pool implementation.

I also would like your opinion about two changes to the event queues. How
would you think about adding enqueue predicates to the queue. And the second
change I propose, I would like to add a way to tag queues in the system with
a specific name (The stage name). This makes it much easier to debug a stage
system, since you know which queue you are dealing with all the time. The
tag would be passed in during consturction of the queue.

Let me know if this sounds reasonable. It would allow me to let go of the
last remains of my event package fork.

Thanks.
Marc

> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Monday, September 16, 2002 1:54 PM
> To: Avalon Developers List
> Subject: Re: SEDA
> 
> 
> Marc Schier wrote:
> >  
> > 
> >>>* Redo the nio socket implementations, make them compliant 
> >>
> >>with the current
> >>
> >>>scheme.
> >>
> >>:/  We need to support both JDK 1.4 NIO and SEDA NBIO.  That 
> >>way we can 
> >>have nonblocking IO on JDK 1.3+.  Also the NBIO is 
> apparently faster 
> >>than the JDK 1.4 version.
> > 
> > 
> > I hope the new component oriented design will allow this. 
> NBIO and JDK NIO
> > seem to be pretty similar.
> 
> It should.
> 
> >>>* Make th design more extensible, for example by allowing 
> >>
> >>to provide special
> >>
> >>>event handler implementations for specific purposes to the 
> >>
> >>stage pipeline.
> >>
> >>>Currently the three needed event handler implementations 
> >>
> >>are inner classes
> >>
> >>>to the pipeline.
> >>
> >>I'm not sure I follow what this is about.
> > 
> > 
> > What I mean is that the event handler implementations (which in your
> > previous email you were refering to as helper classes) are currently
> > hardcoded into the pipeline implementation.  But thinking 
> about it, it
> > should not be necessary to allow flexible addition of these 
> helper classes,
> > since the ones in there should suffice. BTW EventHandler 
> should definetly
> > not be deprecated, since its needed for the stage manager's 
> native event
> > handling mechanism and to register thread managers.
> 
> Ok.
> 
> 
> >>>* Add ant build files.
> >>
> >>I unpacked your zip file in the event package to take 
> >>advantage of the 
> >>build file already there.  It does not compile though.  It is 
> >>complaining about ContextManager/ServiceManager or something 
> >>like that.
> >>Did you have any other jars in the classpath?
> > 
> > 
> > It's probably the dependency on fortress from the test 
> case. You will also
> > need JUnit in your classpath. Another problem could be that 
> I'm compiling on
> > JDK 1.4.1...
> 
> I have JDK 1.4.1--however I think it has to do with dependencies on 
> Fortress.
> 
> > The next update that I will be posting includes the ability 
> to describe
> > stages that are comprised of more than one component and a 
> way to specify
> > asynchronous exception handlers and return value handlers.
> > 
> > BTW, I saw your post on the SEDA mailing list. I also cross 
> posted my last
> > email to the seda list to keep em in the loop.
> 
> There is a private developers list.  I am working with them on that. 
> However communication is slow.  There is usually a day lag.
> 
> -- 
> 
> "They that give up essential liberty to obtain a little 
> temporary safety
>   deserve neither liberty nor safety."
>                  - Benjamin Franklin
> 
> 
> --
> To unsubscribe, e-mail:   
> <ma...@jakarta.apache.org>
> For additional commands, e-mail: 
> <ma...@jakarta.apache.org>
> 

Re: Command ThreadManager and event queues (was RE: SEDA)

[Berin Loritsch <bl...@apache.org>]

Marc Schier wrote:
> Berin,
> 
> Could you do me a favor and please apply the attached patches. They fix that
> the threadmanager's configuration cannot specify the block timeout of the
> used pool implementation.
> 
> I also would like your opinion about two changes to the event queues. How
> would you think about adding enqueue predicates to the queue. And the second
> change I propose, I would like to add a way to tag queues in the system with
> a specific name (The stage name). This makes it much easier to debug a stage
> system, since you know which queue you are dealing with all the time. The
> tag would be passed in during consturction of the queue.
> 
> Let me know if this sounds reasonable. It would allow me to let go of the
> last remains of my event package fork.


Applied.


-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>