tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pid <...@pidster.com>
Subject Re: Connection is closed when CometEvent.close is called during an event
Date Thu, 10 Jun 2010 09:27:17 GMT
On 08/06/2010 11:26, Reich, Matthias wrote:
> Hello,
> 
> I am using a CometProcessor servlet in a long-poll scenario, and recently had
> a closer look at the life span of connections that are used for poll requests.
> 
> I noticed that connections are closed by Tomcat whenever a poll request 
> was answered (and closed) directly during processing of the BEGIN event.
> In our application this happens for one out of three poll requests approximately
> and thus should not be neglected.   
> 
> I had a look into the source code and found the reason in the 
> CoyoteAdapter.event method - it sets the 'error' flag to true in this situation.
> 
> I modified the code (in 6.0.20 and 6.0.26) so that the error flag is not set.
> With that change Tomcat kept the connection open:
> 
> ...
>     // Calling the container
>     connector.getContainer().getPipeline().getFirst().event(request, response, request.getEvent());
> 
>     if (!error && !response.isClosed() && (request.getAttribute(Globals.EXCEPTION_ATTR)
!= null)) {
>         // An unexpected exception occurred while processing the event, so
>         // error should be called
>         request.getEvent().setEventType(CometEvent.EventType.ERROR);
>         request.getEvent().setEventSubType(null);
>         error = true;
>         connector.getContainer().getPipeline().getFirst().event(request, response, request.getEvent());
>     }
>     if (response.isClosed() || !request.isComet()) {
>         if (status==SocketStatus.OPEN) {
>         //CometEvent.close was called during an event.
>         request.getEvent().setEventType(CometEvent.EventType.END);
>         request.getEvent().setEventSubType(null);
>         
> // don't set the error flag here - otherwise the connection will be closed 
> // whenever a long poll is answered already during event handling:
>         // error = true;
>         
>         connector.getContainer().getPipeline().getFirst().event(request, response, request.getEvent());
>         }
>         res.action(ActionCode.ACTION_COMET_END, null);
>     } else if (!error && read && request.getAvailable()) {
>         // If this was a read and not all bytes have been read, or if no data
>         // was read from the connector, then it is an error
>         request.getEvent().setEventType(CometEvent.EventType.ERROR);
>         request.getEvent().setEventSubType(CometEvent.EventSubType.IOEXCEPTION);
>         error = true;
>         connector.getContainer().getPipeline().getFirst().event(request, response, request.getEvent());
>     }
>     return (!error);
> ...
> 
> In my first tests I did not observe any undesired side effects of the change.
> However, I did not yet do extensive tests - especially not with a steaming client.
> 
> Do you agree that this should be considered a bug and fixed in the next Tomcat
> release?

You'll need one of the devs with Async knowledge to look at this, I think.


p

> Regards,
> Matthias
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
> 



Mime
View raw message