As you see from:
http://issues.apache.org/jira/browse/DIRMINA-95
your issue has been resolved.
HTH,
Trustin
2005/10/17, Trustin Lee <[EMAIL PROTECTED]>:
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/
