Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cxf-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: domain of eoghan.glynn@iona.com
 designates 62.221.12.33 as permitted sender)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Port HttpTransport from Jetty5 toJetty6
Date: Wed, 13 Dec 2006 12:17:07 -0000
Message-ID: <FA1787F64A095C4090E76EBAF8B183E071FB38@owa-emea.iona.com>
Thread-Topic: Port HttpTransport from Jetty5 toJetty6
Thread-Index: AcceoydcMvcd+3GuRHuzPCsCdnHxTQACl0iw
From: "Glynn, Eoghan" <eoghan.glynn@iona.com>
To: <cxf-dev@incubator.apache.org>


It depends on whether Jetty6 provides a truly asynchronous API for
processing incoming HTTP requests.

Note that this question is orthogonal to Jetty6 leveraging the
non-blocking nature of Java NIO to reduce the number of threads required
to manage I/O (i.e. to avoid a blocking accept per listener and a
blocking read per incoming connection). Obviously using NIO to reduce
the number of IO threads in this way is a good thing, and clearly Jetty6
will be of benefit to us there.

However, I think the Xfire AsyncWeb concept went a bit further than this
(correct me, DanD, if necessary). The idea would be to also avoid
blocking the dispatch threads where possible. For example if a thread
processing a chunked request from client c1 detects a pause in the
stream of incoming chunks, this thread could conceivably start
processing a request from another client in the meantime.

Note that this is a different scenario to HTTP pipelining, where a
individual client may issue a sequence of idempotent requests on a
*single* connection, without waiting for the responses. Since the PUT
verb is obviously non-idempotent, we wouldn't generally be in a position
to interleave requests on the client-side in this way.=20

In any case, I don't know if Jetty6 provides a non-blocking API
throughout (e.g. whether HTTPRequest.getInputStream().read() is
non-blocking). If it does, then we'd have the tools to fully address
CXF-228. Otherwise we'd need to look at something like AsyncWeb[1].

Cheers,
Eoghan

[1] http://docs.safehaus.org/display/ASYNCWEB/Home

> -----Original Message-----
> From: Bozhong Lin [mailto:blin@iona.com]=20
> Sent: 13 December 2006 10:40
> To: cxf-dev@incubator.apache.org
> Subject: Re: Port HttpTransport from Jetty5 toJetty6
>=20
> Willem,
>=20
> Does this mean that ApacheCXF will get asynchronous HTTP=20
> support [1] automatically by doing this porting? Will porting=20
> have any performance implication to Apache CXF? If so, it=20
> might be a good idea to measure performance before we commit=20
> any porting code.
>=20
> Regards,
> Bo
>=20
> [1] https://issues.apache.org/jira/browse/CXF-228
>=20
> Willem Jiang wrote:
> > Hi ,
> > Since Jetty6 provides NIO support, I'd like to port the=20
> HttpTransport=20
> > from Jetty5 to Jetty6 [1].
> >
> > I just went through the http code, here is something that I just=20
> > figured out.
> > Please point out if I am wrong.
> >
> > Porting
> > 1. In HttpTransport the mainly class related with Jetty5 is=20
> > JettyHTTPServerEngine, JettyHttpDestination, JettySslListenerFactory
> >
> > 2. Replace the Jetty5 class with Jetty6
> > Jetty 5                                       Jetty 6
> > SocketListener                      SelectChannelConnector
> > SslListener                            SSLSelectChannelConnector
> > HttpHandler                          Handler
> > HttpContext                          ContextHandler
> >
> > [1]
> >=20
> http://docs.codehaus.org/display/JETTY/Porting+from+jetty5.x+to+jetty6
> >
> > Cheers,
> > Willem.
>=20