cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <eoghan.gl...@iona.com>
Subject RE: Port HttpTransport from Jetty5 toJetty6
Date Wed, 13 Dec 2006 12:17:07 GMT

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. 

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

Mime
View raw message