Trustin Lee wrote:
2005/10/11, [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>:
I don't want to reorder messages received per session.
Instead, when my server 'elects' the next session for processing,
I want it to
first promote the sessions having a message X older than (Y-Z)
seconds.
I see.
I have checked BaseThreadPool, and if I understand well, I would need
to change
'fetchBuffer' so that it first chooses SessionBuffer containing
such message.
Is that correct?
Yes, you're correct. You'll have to maintain the number of the
messages of that type so you don't waste the time while iterating the
buffer.
I guess you mean skipping search if number of that message X is 0.
That's a good idea.
I am not sure as the difference between readySessionBuffers and
busySessionBuffers does not appear clearly to me (why is a
BufferSession added
to busySessionBuffers in fireEvent?)
busySessionBuffers contains the SessionBuffers which have any events
to fire in them.
I am sorry, but I don't get it. What do you exactly mean by "have any
events to fire in them"?
For me, the SessionBuffers waiting for processing (by leader) are the
ones having pending events.
readySessionBuffers contains the SessionBuffers which are waiting for
the leader thread to process them. So a SessionBuffer is removed from
readySessionBuffers when the leader thread takes it, but not from
busySessionBuffers to prevent the same SessionBuffer from being added
to readySessionBuffers and busySessionBuffers because it will cause
severe synchronization issue.
But that is exactly what fireEvent does. It adds a same SessionBuffer to
the two sets. I am a bit confused.
BTW the names are really confusing. I had to spend some time to
explain this to you. I'd better change them to more clear ones. Any
suggestions? :)
I prefer waiting until I have a better understanding of the purpose of
each set.
Regards,
J-F
