Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: <463A88B1.6030901@apache.org>
Date: Fri, 04 May 2007 03:13:21 +0200
From: Remy Maucherat <remm@apache.org>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Tomcat Developers List <dev@tomcat.apache.org>
Subject: Re: Proposed new CometEvent.notify method
References: <4638B4DE.4090800@apache.org> <463945DC.9050606@apache.org>
 <4639F5F0.8030008@hanik.com> <4639FB90.3020406@apache.org>
 <463A064A.2090709@hanik.com> <463A0BDF.7060406@apache.org>
 <463A1520.5070104@hanik.com> <463A18AE.60804@apache.org>
 <463A6CC5.5090804@hanik.com> <463A77A8.9020406@apache.org>
 <463A8130.9060106@hanik.com>
In-Reply-To: <463A8130.9060106@hanik.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Filip Hanik - Dev Lists wrote:
>> Ok, I'll try something in the meantime in CoyoteAdapter, since it's 
>> trivial (and I think does all that is needed at this point).
> The available() has a side effect, if there is a partial or non valid 
> chunked header (ie the client also sends some garbage), available() 
> returns >0, and the read() goes into a forever blocking read as no more 
> data is coming in.
> this was not the case before, as a READ event, you did one read, and 
> then available returned 0, and you'd be fine until next READ event.
> since it's a client data error, I'm ok with it, question is, how common 
> are these client errors.

It doesn't really make a difference. Even if you do only one read during 
the read event, it is possible to only send a portion of the chunk 
header, causing the ChunkedInputBuffer to block if its previous chunk 
was fully read (or if it is the first chunk). The only realistic 
solution is to add a system property forbidding reads during parsing of 
the chunk header, as I don't think it's a very reasonable situation.

>> I would be ok to tag 6.0.13 before doing any further functional 
>> changes, as it contains numerous bugfixes since 6.0.10.
> Let us wait a few days for these available() changes to get some 
> feedback, then we can tag and go through our stability tests.

Ok. I was ready to tag tomorrow evening before starting on the timeout 
feature for APR, but I can wait more if you have changes to do 
(otherwise, I don't think anyone is going to really test since it's the 
WE). I can tag again if there's a horrible bug.

R�my


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