2008/10/10 Jeanfrancois Arcand <Jeanfrancois.Arcand_at_sun.com>
>
>
> gustav trede wrote:
>
>>
>>
>> 2008/10/9 Jeanfrancois Arcand <Jeanfrancois.Arcand_at_sun.com <mailto:
>> Jeanfrancois.Arcand_at_sun.com>>
>>
>>
>>
>> gustav trede wrote:
>>
>> 2008/10/9 Jeanfrancois Arcand <Jeanfrancois.Arcand_at_sun.com
>> <mailto:Jeanfrancois.Arcand_at_sun.com>
>> <mailto:Jeanfrancois.Arcand_at_sun.com
>> <mailto:Jeanfrancois.Arcand_at_sun.com>>>
>>
>>
>> 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 :-) :-)
>
i will make a patch, but to do it proper requires more then a simple
threadpool:
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
.
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.
I got some other code to do before i can fully test this implementation
myself.
So i need a few days.
regards
gustav trede