hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: HC 5.0 scope and design decisions
Date Wed, 28 Sep 2016 17:53:52 GMT
On Wed, 2016-09-28 at 18:40 +0300, Dmitry Potapov wrote:
> Oleg,

Hi Dmitry

> I'm not sure I got it right.
> Are you going to drop org.apache.http.protocol.HttpService class?

Yes, I do.

> For now it is the only way to:
>  1. Process full-duplex requests (i.e. start sending reply before complete request entity

Full-duplex data transfer should be massively easier with non-blocking
I/O. If it is not, it is a problem with the actual non-blocking code.

>  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.

Very true. However we likely will have to do it anyway if we want HTTP/2
code to support transparent content compression / decompression. 

>  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.

Exactly the same can be done with non-blocking code very easily as long
as one can live without InputStream / OutputStream compatibility.

>  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.

Non-blocking file channels were implemented in Java 7 with NIO2, were
they not? Besides, NIO with direct channels (zero-copy mode) outperforms
classic I/O considerably when copying content directly from a file. The
problem is that HTTP/2 makes zero-copy impossible due to frame

> 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.

There is no harm in keeping HttpService as long as people find it
useful. I just personally tend to think its usefulness will be
diminishing (beyond cases where one needs good performance and
InputStream / OutputStream compatibility).


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

View raw message