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 (nike.apache.org: domain of henri.gomez@gmail.com
 designates 209.85.212.177 as permitted sender)
References: <4FB939F5.8020109@apache.org>
In-Reply-To: <4FB939F5.8020109@apache.org>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8
Message-Id: <8CE19033-A020-4FCE-9C17-918ACCADEAF8@gmail.com>
Cc: Tomcat Developers List <dev@tomcat.apache.org>
From: Henri Gomez <henri.gomez@gmail.com>
Subject: Re: APR/native and per socket timeouts.
Date: Sun, 20 May 2012 20:44:42 +0200
To: Tomcat Developers List <dev@tomcat.apache.org>

Did there is a need to have sockets with differents timeout in day to day ca=
se ?

For example did it is required by specs or API ?

The finer, the better but only if there is a real need :-)

Btw, i'll take a look to your commits.=20

Le 20 mai 2012 =C3=A0 20:37, Mark Thomas <markt@apache.org> a =C3=A9crit :

> Currently, time outs for APR/native sockets are managed at the Pollset
> level. This means all sockets in a single Pollset must have the same
> time out. This is starting to become a nuisance.
>=20
> I have already had to add a second Pollset to AprEndpoint to handle
> separate connection and keep-alive time outs. Now I need to be able to
> handle infinite time outs for WebSocket and I do not want to have to add
> a third Pollset.
>=20
> Therefore, I intend modifying the APR/native code to support per socket
> time outs. I would be grateful if those of you with more C knowledge
> than I (which is most people on this list) could:
> a) tell me now if this is a crazy idea (and why)
> b) keep an extra close eye on any commit of mine that touches the C code.
>=20
> I intend to retain backwards compatibility so newer versions of the
> native connector will work with older Tomcat versions but Tomcat 7 will
> have a new minimum native version so that this feature is available.
> This means that the next Tomcat 7 release is likely to have to wait for
> the next native release.
>=20
> Looking at the code so far, I am likely to start with some renaming to
> clarify the current code before actually changing anything functional.
>=20
> Mark
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>=20

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