>
>
>>
>> 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
.
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.
I got some other code that i need to do before i can implement and test it,
but i will do this within a few days.
do you have any opinion regarding this matter ?
regards
gustav trede