Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: domain of alex@planet-barclay.com
 designates 69.17.115.243 as permitted sender)
Message-ID: <483494D0.2080703@planet-barclay.com>
Date: Wed, 21 May 2008 14:32:00 -0700
From: Alex Barclay <alex@planet-barclay.com>
User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421)
MIME-Version: 1.0
To: Tomcat Developers List <dev@tomcat.apache.org>
Subject: Re: Potential problem with COMET & sendfile
References: <4833536E.9070108@planet-barclay.com>
 <1211357426.3241.4.camel@localhost.localdomain>
 <48346063.9040706@planet-barclay.com> <48348F64.4060707@hanik.com>
In-Reply-To: <48348F64.4060707@hanik.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Filip Hanik - Dev Lists wrote:
> I don't see any use case for Comet+sendfile make sense.
>
> but if you do it, you should
>
> ...
> set your sendfile stuff
> call CometEvent.close()
> .....
>
> ie, the event shouldn't be cometized when doing sendfile, it makes 
> zero sense since when the file is sent, the HTTP request is over.
You're right. In this case because I'm dealing with the request in the 
begin event and doing a sendfile the request won't be cometized. The 
other case is where the verb is a put or a post at which point it will 
be cometized. Yes I am doing a close on the event, it breaks really 
horribly if you don't do this.

Alex.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org