Salut,
gustav trede wrote:
> Salut !,
>
>
> The nature of io, with tcp and its packet resend logic etc, can make
> even small messages take long time on a slow connections.
> with mobile clients today, this problem is even more amplified.
Agree.
>
> Therefore there is a need to do the actual message sending
> concurrently, up to a configurable limit,( lower then the saturation
> the of server pipe ).
Just to clarify. The current DefaultNotificationHandler allow you to
send using the calling thread or a thread pool (the heavy thread pool
you describe below :-))
>
>
> I have solved it in my private notificationhandler:
>
>
> public void notify(final CometEvent cometEvent, final
> Iterator<CometHandler> iteratorHandlers) {
> if (pipeline == null) {
> notify0(cometEvent, iteratorHandlers);
> } else {
> while (iteratorHandlers.hasNext()){
> addToPipeline(cometEvent, iteratorHandlers.next());
> }
> }
> }
>
> private void addToPipeline(final CometEvent cometEvent, final
> CometHandler cometHandler){
> pipeline.execute(new Runnable() {
> public void run(){
> notify0(cometEvent, cometHandler);
> }});
> }
>
>
>
> public void setBlockingNotification(final boolean
> blockingNotification) {
> if (pipeline == null){
> if (!blockingNotification){
> pipeline = new ThreadPoolExecutor( 64, 64,
> 0L, TimeUnit.SECONDS,
> new ArrayBlockingQueue<Runnable>(32768, false));
> }
> }else{
> if (blockingNotification){
> pipeline.shutdown(); // can take long time
> pipeline = null;
> }
> }
> }
>
>
> Here i use a 64 threads and max queue of 32k, Runnable instead of the
> heavier grizzly Task object.
LOL :-)
> several K messages to several K users translates into millions of
> objects, and suddenly its of interest to keep the overhead down.
>
> perhaps we should offer the same functionality as standard or at least
> as an configurable option so people dont
> have to code their own notificationhandler.
I think the concept of NotificationHandler could be improved. Right now
you use a NotificationHandler for:
+ Send message using the calling thread or concurrently using a thread pool
+ Filter/Aggregate messages before the reach the CometHandler. This is
where you can decide to discard some messages based on some metrics.
+ Do whatever transformation you want on the message. An example would
consist of subscribing to a JMS queue and push the message on that queue
so other subscriber can read the message as well. This is something I
want to have with Grizzly Comet because when you use Comet inside a
cluster, you want to be able to share notification among instance.
>
> I can implement it with the grizzly standard pipe and its Task
> inorder to fit for normal usage,
No I think we can continue using your approach. We just need a way for
the user to be able to configure your new NotificationHandler.
> that Task will give some minor overhead , its a more heavyweight object
> then an empty Runnable, but thats the only compatible option ?.
I think we should leave the DefaultNotificationHandler as it is, and
instead add a new NotificationHandler user can configure (and blog about
it because this will be quite of interest!). So we don't break the
current behavior. What do you think?
Great work!
-- Jeanfrancois
>
>
> regards
> gustav trede