2008/10/14 Jeanfrancois Arcand <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.
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 will contribute my code when i have tested it more thorough.
regards
gustav trede