directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Trustin Lee <trus...@gmail.com>
Subject Re: BaseThreadPool question
Date Mon, 17 Oct 2005 08:39:06 GMT
Hi J-F,

As you see from:

http://issues.apache.org/jira/browse/DIRMINA-95

your issue has been resolved.

HTH,
Trustin

2005/10/17, Trustin Lee <trustin@gmail.com>:
>
> Hi J-F,
>
> 2005/10/11, daune.jf@daune-consult.com <daune.jf@daune-consult.com>:
> >
> > I noticed in Worker.fetchBuffer that readySessionBuffers is 'cleaned'
> > (removal
> > of null or empty SessionBuffers) up to the first usable SessionBuffer.
> >
> > Is there a reason to stop cleaning?
>
>
> It is not simple cleaning but fetching. A leader thread fetches one
> buffer, gives up its leader position, and promoted one of other threads
> (followers) to a leader. And the new leader will do the same. This is what's
> specified in Douglas Schmidt's Leader-Followers thread pool pattern.
>
> What do you think about separating the cleaning from the selection?
> >
> > We could first iterate and remove null or empty SessionBuffers, and then
> > call an
> > electBufferForProcessing method if the set is not empty.
>
>
> We can do that, but why? Is there any benefit we can get doing so? There
> will be a little performance penalty and you could simply reimplement the
> code which checks null and emptiness.
>
> Another approach would be to prevent null/empty SessionBuffer to be in
> > readySessionBuffers. But I don't know how they reach the set.
>
>
> I started thinking that it is safe to move this checking code to fireEvent
> method. But I didn't test this idea yet. I'll let you know when the test is
> done.
>
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/




--
what we call human nature is actually human habit
--
http://gleamynode.net/

Mime
View raw message