hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitry Potapov <potapo...@gmail.com>
Subject Re: HC 5.0 scope and design decisions
Date Wed, 28 Sep 2016 15:40:28 GMT
Oleg,

I'm not sure I got it right.
Are you going to drop org.apache.http.protocol.HttpService class?
For now it is the only way to:
 1. Process full-duplex requests (i.e. start sending reply before complete request entity
consumption)
 2. Compless/decomplress requests and responses on the fly (DecompressingEntity really does
the job for servers). This is possible for NIO too, but will require to implement non-blocking
analog for GzipInputStream.
 3. Reduce threads contention by using fixed number of workers with connections queue. This
allows to limit CPU usage with native system mechanisms: you spawn 4 threads and you know
that only 4 requests and responses will be served simultaneously, without excessive context
switching and risk of response being blocked by other heavy task.
 4. Blocking server is the only effective way to stream static files from disk, as there is
no such thing as non-blocking file channels (unless you're crazy and use direct i/o). For
instance, recent nginx versions uses separate pool with blocking operations for this task,
otherwise static files streaming will preempt other requests.

Every item listed above can be achieved in HttpAsyncService but this will require some software
crutches and won't allow to achieve maximum throughput and performance.

-- 
Dmitry Potapov

On Wed, Sep 28, 2016 at 04:39:53PM +0200, Oleg Kalnichevski wrote:
> Folks
> 
> The HTTP/2 transport in trunk has been shaping up reasonably well. I
> have made some good progress recently and am cautiously optimistic that
> there should be a HttpCore 5.0 alpha release with the new non-blocking
> HTTP/1.1 and HTTP/2 transports within a month or two. HttpClient 5.0
> alpha should follow in Jan 2017.
> 
> There is a few points I wanted to discuss and get some feedback upon.
> 
> (1) I no longer see any reason to continue developing the classic
> (blocking) server side transport. We only use it for integration tests
> internally for integration tests and I feel there is no reason to not
> use non-blocking transport for all integration tests instead. 
> 
> (2) What would you say about HttpCore 5.0 remaining Java 7 compatible
> but HttpClient 5.0 requiring Java 8? 
> 
> I do not see HC 5.0 going GA any time sooner than Q4 2017. By that time
> Java 9 should be out and Java 8 might be approaching EOL. Two years ago
> Java 7 compatibility sounded like a good idea but it looks less so
> today.  
> 
> (3) Never ending trouble with logging toolkits. 
> 
> Should be remain faithful to Commons Logging or shall we finally migrate
> to SLF4J?
> 
> What do you think?
> 
> Oleg
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
> 

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


Mime
View raw message