Hi Richard,
> heres the code that I use in the event that I have to fall back to
> long polling.
> 1. the connection
> -----------
> new CometHandlerImpl(session, this.UA, response);
>
> Every session has a sessionContainer that brokers its client state
> with the system. When a connection is made and I instanate this
> handler it registers it's self with the session controllers Context
> handler.
>
>
> 2. After push
> ---------------------------
> public void doRemoveCometHandler(){
> try{
> // block write queue... so we can tank this guy without
> collision
> this.setCometHandlerBusy(true);
>
> if(this.cometHandler != null){
>
> if(this.SessionContext != null &&
> this.SessionContext.isActive(this.cometHandler))
> if(this.cometHandler != null)
> this.SessionContext.removeCometHandler(this.cometHandler);
>
> // make null so we expedite GC
> this.cometHandler = null;
> }
> // Tell the system that I cant talk to the client
> this.ConnectionStatus.setDisconnect();
>
> }catch(Exception e){
> e.printStackTrace();
> }
>
> }
>
> As you can see, this is somewhat inefficient, Actually this is about
> as inefficient as it gets. Long polling Comet is on its death bed
> and streaming is waiting to take over. Till then I need to squeeze
> more out of the frame than this. Have we implemented a way to
> suspend the connection handler object that lets it just discard the
> ServletResponse object and not have to be constantly re-instanated
> since 1.9.9?
I think we don't have that and I'm not even sure it would be correct
to have such an implementation. From one side I understand, that when
you have some stateful scenario, it looks natural, but for stateless
it may add some confusion.
WBR,
Alexey.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>