You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by da...@daune-consult.com on 2005/10/11 10:09:14 UTC
BaseThreadPool question
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?
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.
By default, electBufferForProcessing would return the first element.
In my case (cf. mail about prioritary messages), I would overwrite default
behavior and search for prioritary messages.
This seems to me a good refactoring as it separates concerns.
Another approach would be to prevent null/empty SessionBuffer to be in
readySessionBuffers. But I don't know how they reach the set.
Regards,
J-F
Re: BaseThreadPool question
Posted by Trustin Lee <tr...@gmail.com>.
2005/10/18, daune.jf@daune-consult.com <da...@daune-consult.com>:
>
> If you hold on Queue, it could be interesting to implement same interface
> as
> java.util.Queue to ease future migration.
Great idea. I'm testing my new Queue which implements List. I'll get back to
this thread if done.
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: BaseThreadPool question
Posted by Trustin Lee <tr...@gmail.com>.
2005/10/18, daune.jf@daune-consult.com <da...@daune-consult.com>:
>
> If you hold on Queue, it could be interesting to implement same interface
> as
> java.util.Queue to ease future migration.
Now org.apache.mina.util.Queue now provides all methods requires to be
java.util.List and java.util.Queue. It currently implements
java.util.Listonly becuase MINA should run on JDK
1.4.
This change will be included in MINA 0.8.
HTH,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: BaseThreadPool question
Posted by da...@daune-consult.com.
Trustin Lee <tr...@gmail.com> a écrit :
> 2005/10/18, daune.jf@daune-consult.com <da...@daune-consult.com>:
>>
>> Trustin,
>>
>> I have some questions for you:
>>
>> - Is there a reason to use a Queue instead of (the less restrictive) List?
>
>
> We need a pop() operation. That's all for now. :)
Then a List would suit you as well (remove(0)), and suit me more.
> - If so, is there a reason to use a custom Queue instead of those from Java?
>
>
> First, java.util.Queue appeared in JDK 1.5. We support JDK 1.4 or above.
Sorry, I have been using Java 5.0 for almost a year now. I have even forgotten
the good old 1.4 days ;->
BTW, the Queue has same method names as java.util.Stack, while one is FIFO and
the other LIFO. This can be misleading.
If you hold on Queue, it could be interesting to implement same interface as
java.util.Queue to ease future migration.
> And the queues provided by JDK is less effecient than our circular queue
> implementation. There's no circular queue implementation in JDK 1.5 yet.
>
> Trustin
Regards,
J-F
Re: BaseThreadPool question
Posted by Trustin Lee <tr...@gmail.com>.
2005/10/18, daune.jf@daune-consult.com <da...@daune-consult.com>:
>
> Trustin,
>
> I have some questions for you:
>
> - Is there a reason to use a Queue instead of (the less restrictive) List?
We need a pop() operation. That's all for now. :)
- If so, is there a reason to use a custom Queue instead of those from Java?
First, java.util.Queue appeared in JDK 1.5. We support JDK 1.4 or above.
And the queues provided by JDK is less effecient than our circular queue
implementation. There's no circular queue implementation in JDK 1.5 yet.
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: BaseThreadPool question
Posted by da...@daune-consult.com.
Trustin,
I have some questions for you:
- Is there a reason to use a Queue instead of (the less restrictive) List?
- If so, is there a reason to use a custom Queue instead of those from Java?
J-F
> Yes you're right. But we can modify org.apache.mina.util.Queue to implement
> java.util.List .
>
> 2005/10/18, daune.jf@daune-consult.com <da...@daune-consult.com>:
>>
>> The fact that fetchSessionBuffer takes a Queue prevents easy
>> manipulation of the
>> collection.
>>
>> There is no way to remove an element at index i, other than popping all
>> elements
>> before and pushing them back (actually a queue implies FIFO strategy)
>
Re: BaseThreadPool question
Posted by Trustin Lee <tr...@gmail.com>.
Yes you're right. But we can modify org.apache.mina.util.Queue to implement
java.util.List .
2005/10/18, daune.jf@daune-consult.com <da...@daune-consult.com>:
>
> The fact that fetchSessionBuffer takes a Queue prevents easy
> manipulation of the
> collection.
>
> There is no way to remove an element at index i, other than popping all
> elements
> before and pushing them back (actually a queue implies FIFO strategy)
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: BaseThreadPool question
Posted by da...@daune-consult.com.
Jean-François Daune <da...@daune-consult.com> a écrit :
> Trustin Lee wrote:
>
>> Hi J-F,
>>
>> 2005/10/17, daune.jf@daune-consult.com
>> <ma...@daune-consult.com> <daune.jf@daune-consult.com
>> <ma...@daune-consult.com>>:
>>
>> I would like to suggest some additional changes (cf. attachment)
>>
>> This allows modifying the SessionBuffer selection criteria. I
>> modifies BastThreadPool as you requested. Additionally, I replaces
>> BlockingSet with BlockingQueue because it is more efficient in usual
>> case. Please override BaseThreadPool.fetchSessionBuffer().
>>
>> Cheers,
>> Trustin
>> --
>> what we call human nature is actually human habit
>> --
>> http://gleamynode.net/
>
> Thanks a lot for responsiveness !!
>
> J-F
The fact that fetchSessionBuffer takes a Queue prevents easy
manipulation of the
collection.
There is no way to remove an element at index i, other than popping all
elements
before and pushing them back (actually a queue implies FIFO strategy)
J-F
Re: BaseThreadPool question
Posted by Jean-François Daune <da...@daune-consult.com>.
Trustin Lee wrote:
> Hi J-F,
>
> 2005/10/17, daune.jf@daune-consult.com
> <ma...@daune-consult.com> <daune.jf@daune-consult.com
> <ma...@daune-consult.com>>:
>
> I would like to suggest some additional changes (cf. attachment)
>
> This allows modifying the SessionBuffer selection criteria.
>
>
> I modifies BastThreadPool as you requested. Additionally, I replaces
> BlockingSet with BlockingQueue because it is more efficient in usual
> case. Please override BaseThreadPool.fetchSessionBuffer().
>
> Cheers,
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
Thanks a lot for responsiveness !!
J-F
Re: BaseThreadPool question
Posted by Trustin Lee <tr...@gmail.com>.
Hi J-F,
2005/10/17, daune.jf@daune-consult.com <da...@daune-consult.com>:
>
> I would like to suggest some additional changes (cf. attachment)
>
> This allows modifying the SessionBuffer selection criteria.
I modifies BastThreadPool as you requested. Additionally, I replaces
BlockingSet with BlockingQueue because it is more efficient in usual case.
Please override BaseThreadPool.fetchSessionBuffer().
Cheers,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: BaseThreadPool question
Posted by Trustin Lee <tr...@gmail.com>.
And I forgot to mention that:
* busySessionBuffers is renamed to allSessionBuffers
* readySessionBuffers is renamed to unfetchedSessionBuffers
to clarify their meaning.
HTH,
Trustin
2005/10/17, Trustin Lee <tr...@gmail.com>:
>
> 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 <tr...@gmail.com>:
> >
> > Hi J-F,
> >
> > 2005/10/11, daune .jf@daune-consult.com <da...@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/
>
--
what we call human nature is actually human habit
--
http://gleamynode.net/
Re: BaseThreadPool question
Posted by Trustin Lee <tr...@gmail.com>.
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 <tr...@gmail.com>:
>
> Hi J-F,
>
> 2005/10/11, daune.jf@daune-consult.com <da...@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/
Re: BaseThreadPool question
Posted by Trustin Lee <tr...@gmail.com>.
Hi J-F,
2005/10/11, daune.jf@daune-consult.com <da...@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/