cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Async HTTP client side
Date Fri, 10 Sep 2010 18:38:16 GMT

I just committed some stuff I've been working on to a branch (async-client) to 
enable the use of the Apache HTTP 4.x NIO core/http client stuff for the HTTP 
client side.   It's a work in progress, but thought I'd share it with everyone 
to get some others possibly looking at it.

Basically, by using the NIO stuff, all the Async client calls don't consume 
threads at all.  The NIO core creates a number of dispatch threads (currently 
4, need to make this configurable) and those are what's used as requests come 
in.  As such, you can have 100 requests outstanding, and only those 4 threads 
are extra.  (note: those 4 threads are also used for sending requests as 
sockets free up for sending)  Anyway, it really is a work in process and would 
need quite a bit more work to get merge able to trunk in any form.

What works:

1) Most of the basic features we had in the HTTPConduit such as chunking 
control, timeouts, redirects, authentication, keep-alives, etc...    

2) All of the system tests except the ws-specs stuff.  (not sure why on the 
ws-specs yet)

Thus, things look pretty good as a starting point.  :-)

What doesn't work and stuff todo:

1) HTTPs - for now, if https is used, it delegates up to the old HTTPConduit.   
Definitely need to research quite a bit more for this.

2) JAX-RS webclient - the JAX-RS client has a bunch of issues.  It assumes an 
HttpURLConnection is available in a bunch of places.  It also assume the 
synchronous nature of the old HTTPConduit (when "close" is called on the 
output stream and it returns, the response is ready.  Not the case anymore.)  
Definitely some cleanup needed in there.  I added a flag to force the new 
conduit to delegate to the old conduit and have jax-rs setting that.

3) ws-specs systests - I think some RM things are also assuming some sync 
behavior, but I'm not sure yet.  Need to dig some.  It looks like some partial 
responses aren't getting sent somehow.

4) Proxy server - not sure how to configure proxy server things with the HTTP 
NIO client stuff yet.   

5) Detection of http nio stuff - ideally, the http nio stuff would be marked 
provided in the pom and we'd just use it if avail and default to the old 
conduit if not.   I'm forcing the usage right now to test things.

6) HTTP Unit tests - I hate mocks.  :-)

7) Configuration - ideally, there would be a way to configure some of the 
controllers settings such as number of worker threads, probably number of 
keep-alive sessions to hold open, session timeout things, etc....

Also note that it requires the LATEST 4.1-beta2 of the NIO stuff.   There are 
some bugs in the previous versions that have fixes in place that we need.

Anyway, wanted everyone to know about it and possibly take a look and maybe 
even help out.  If we get it all working, it could definitely help with the 
scalability of the CXF/Camel and SMX integrations.

Daniel Kulp

View raw message