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