Salut,
Cam Bazz wrote:
> Hello,
>
> Maybe I could not define the problem statement properly.
>
> every client makes a get request to comet servlet. once in every minute,
> the comet context is notified with a message, thus sending messages to
> the clients. all of them at once.
>
> now, imagine I got 10000 clients. how can I make the server notify them
> one by one, in a round robin fashion. which means if the notification
> interval is 60000ms, (1minute) and if I have 600 users lets say, how can
> I notify the first client, wait until it is done, (or 600ms)
> and then notify the next client until we are done, and then start over.
Implementing your strategy using the NotificationHandler. This class is
responsible for invoking all CometHandler.onEvent(...). Hence this is
where you will decide:
+ Do I invoke CometHandler.onEvent() serially (one after the other) or
spawn use a Thread Pool to invoke the CometHandler.onEvent() using a
different Thread that the one who is calling the NotificationHandler.
Of course using a Thread Pool improve performance because instead of
serially calling CometHandler.onEvent(), it call them concurrently. As
an example, if you have 10000 clients, the calling them serially
(without thread pool) will make the first couple of users happy, but the
last one will gets delayed response (like I've described here[1]). So
using a Thread Pool (by setting setBlockingNotification(false)) helps
improving the "push" operation.
Does that help?
Thanks
-- Jeanfrancois
[1]
http://cometdaily.com/2008/04/01/new-technology-new-problems-delayed-pushes-operations/
>
> by the way, what does:
>
> Context.setBlockingNotification(false);
>
> do?
>
> Best.
> -C.B.
>
> On Tue, Jul 8, 2008 at 4:10 AM, Jeanfrancois Arcand
> <Jeanfrancois.Arcand_at_sun.com <mailto:Jeanfrancois.Arcand_at_sun.com>> wrote:
>
> Salut,
>
> Cam Bazz wrote:
>
>
> Hello,
>
>
>
> how can we implement a
>
> logic that smoothly notifies all the clients in a round robin
> fashion?
>
>
> You might want to use a thread pool and get a thread from
> pool when
> you do a notification. With this approach, you also make sure you
> don't block on a client that isn't reading fast enough. You
> waste a
> thread, but at least other clients get the response in a
> "real-time"
> way. <mailto:users-help_at_grizzly.dev.java.net
> <mailto:users-help_at_grizzly.dev.java.net>>
>
>
>
> I am sorry but I have not understood what to do here. are you
> suggesting number of threads = number of clients??? it does not
> sound logical to me.
>
>
> Naaa no :-) My recommendation for you is to:
>
> Context.setBlockingNotification(false);
>
> Just the default NotificationHandler, which will use a Thread pool
> for executing its notification process.
>
> Does that help?
>
> Thanks
>
> -- Jeanfrancois
>
>
>
>
> Best,
> -C.B.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> <mailto:users-unsubscribe_at_grizzly.dev.java.net>
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
> <mailto:users-help_at_grizzly.dev.java.net>
>
>