Am 2020-05-25 um 11:48 schrieb Oleg Kalnichevski:
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.

Yes, that would be an implication, but this could be configurable with the aforementioned method:
> setEarlyResponseThreshold(long, Timeout)

Where long denotes the min size of the request body and Timeout how long we want to wait for the early response.

Let me know if you have somthing to test, setup is there at work.

Michael

[1] https://stackoverflow.com/a/9176445/696632
[2] https://stackoverflow.com/a/14483857/696632

---------------------------------------------------------------
------
To unsubscribe, e-mail:
httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail:
httpclient-users-h...@hc.apache.org



-----------------------------------------------------------------
----
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail:
httpclient-users-h...@hc.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org

Reply via email to