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: <463B12FE.5070708@apache.org>
Date: Fri, 04 May 2007 13:03:26 +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>
In-Reply-To: <463A0BDF.7060406@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Remy Maucherat wrote:
> No, I don't agree with reading bytes in the lower layer as it would 
> swallow problems even more than doing it in the adapter without any 
> additional benefit (BTW, read cannot return 0). There's also a likely 
> problem that it would require additional structures to hold that data, 
> and which are present in the adapter.

Speaking of swallowing problems due to reading, you wrote this on the 
user list:

On 5/4/07, Filip Hanik - Dev Lists <devlists@hanik.com> wrote:
 > This is because when an event happens, CoyoteAdapter will now check the
 > channel by doing a read(in order for available to work). This will close
 > the underlying connection, and you'll get this error.

CoyoteAdapter reads and generates the appropriate event according to the 
read result (previously, it generated a read event without doing a 
read). There's no close being done in CoyoteAdapter (except if there's 
an exception, in which case everything is recycled, but it doesn't seem 
to be the siutation you describe).

R�my

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