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?)
>
>
> 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 ?
So you want to:
+ be able to configure your own Pipeline
+ fix the current code so Pipeline = null is used instead of the
blockingNotification variable, right? Can you file issues so I don't
forget to fix them as soon as possible?
A+
-- Jeanfrancois
>
>
> regards
> gustav trede