Salut,
gustav trede wrote:
>
>
> 2008/10/14 Jeanfrancois Arcand <Jeanfrancois.Arcand_at_sun.com
> <mailto:Jeanfrancois.Arcand_at_sun.com>>
>
> Salut.
>
> sorry for the delay...was on vacation :-)
>
>
> gustav trede wrote:
>
>
>
> Salut,
>
> have you called
> CometContext.setBlockingNotification(false)?
>
> well, the value of blockingflag is not
> importent as long as the
> pipe itself is null.
> DefaultNotificationHandler needs to create a Pipe
> when the
> setBlockingNotification(FALSE) is called.
>
>
> Ok, so what you are recommending is we create a Pipeline
> independent
> of the value of setBlockingNotification?
>
> Currently its strange when checking the boolean and it
> returns
> a value that can be incorrect, due to the pipeline is
> independent of what that boolean represents.
> In my opinion its just unneeded extra complexity to keep
> those
> 2 in sync.
>
>
> Agree. Any patch for me :-) :-)
>
>
>
> now things get complicated, but thats where the fun is!
>
> ex: i broadcast a message to 200 clients, if some of them are
> slow and gets alot of tcp packet resend etc, a single such bad
> client can in theory cause several minutes delay
>
>
> Right. The push operations might deadlock because of slow clients.
>
>
> .
> hence some kind of tiered thread pooling is needed.
> one to keep the calling thread free from the broadcast requests
> , and a 2nd level one to keep messages flowing concurrently to
> several clients per broadcast.
>
> The max number of threads that handle individual messages will
> need to be manualy configurable though, (according to what the
> server connection can manage without causing congestion), a
> reasonable low default value like 8 or so can be used.
>
> The concurrent use of cometHandler.onEvent(
> cometEvent) needs to be dealt with also, messages needs to wait
> until until the comethandlers outputstream is ready.
> that wait list cant be allowed to grow forever, in my private
> implementation i will kill the comethandler if that happens, for
> the public i dont know whats best.
>
>
> Can you elaborate when this will happens (under which circumstance?)
>
>
> It happens when multiple worker threads in the notification pipeline
> need to send message to the same client in the same timefrime.
> the timeframe for sending a message, using the outputstream never is 0,
> this situation will happen.
>
> I have solved that situation in my private comethandler, i simple put
> messages in a list in the comethandler and let all threads but the first
> one return, leaving the first thread to do all the work until finished.
> If that list gets too large, its a problem that needs to be dealt with.
> JMS handles this by putting stuff on disk or DB.
> i simple kill the connection =), client needs to ask for the data again.
> works fine for my usage case.
Wow can you share your code? What I envision is we can add a new
BaseCometHandler peoples can extends and get the above behavior. That
sound pretty useful IMO.
>
> I managed to use one pipeline only, 2nd level one is not needed.
> By putting each single operation in its own runnable we get full
> concurrency where no single slow operation can put others on hold.
>
> I also use one notificationhandler with one fat pipeline to handle all
> my cometcontexts, its more resourse efficent to share a thread pool
> like that, and it also controlls the maximum number of outgoing message
> sends in a easy to understand way.
I agree.
>
> I will contribute my code when i have tested it more thorough.
Many many thanks. We can certainly add that code to GF v2 as well (we
have until november 5 to backport Comet works).
Thanks for the explanation!
-- Jeanfrancois
>
> regards
> gustav trede