On Mon, 2020-05-25 at 11:45 +0200, Michael Osipov wrote: > Am 2020-05-25 um 09:47 schrieb Oleg Kalnichevski: > > On Sat, 2020-05-23 at 01:10 +0200, Michael Osipov wrote: > > > > > > > > ... > > > > > Am 2020-05-22 um 22:18 schrieb Oleg Kalnichevski: > > > > Theoretically we could enhance the classic client-side protocol > > > > handler > > > > to check if the length of the request entity is known and is > > > > greater, > > > > say, than 1MB, send the request head first, stop and wait for > > > > an > > > > early > > > > response, but this could potentially kill performance of entity > > > > enclosing requests processed in proper request-response > > > > sequence. > > > > This > > > > approach has been considered on several occasions but always > > > > decided > > > > against. > > > > > > So basically, if I understand your idea correctly, we could have > > > either > > > at client or request level a #setEarlyResponseThreshold(long, > > > Timeout) > > > (in bytes, how long to wait for an early response) which checks > > > for > > > "Content-Length" and sends headers first, tries to read, no > > > response, > > > continues sending else process early response -- all in the same > > > thread?! > > > > > > > I am not sure I understand the question. How many threads would you > > like? > > My wording was bad. The basic idea is to read from the socket > (possible > early response) before invoking > org.apache.hc.core5.http.HttpEntity.writeTo(OutputStream). Forget > about > the threads. >
Got you now. This is an option but this extra read will add to the overall response processing time and can be potentially very expensive for small payload messages. The idea to use SocketInputStream#available might actually solve the problem. I am going to look into it. Cheers Oleg > > > Michael > > > > > > [1] https://stackoverflow.com/a/9176445/696632 > > > [2] https://stackoverflow.com/a/14483857/696632 > > > > > > --------------------------------------------------------------- > > > ------ > > > To unsubscribe, e-mail: > > > [email protected] > > > For additional commands, e-mail: > > > [email protected] > > > > > > > > > ----------------------------------------------------------------- > > ---- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: > > [email protected] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
