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 consumption) 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 multiplexing. > 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). Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
