Am 2020-06-02 um 11:40 schrieb Oleg Kalnichevski:
On Tue, 2020-06-02 at 11:36 +0200, Oleg Kalnichevski wrote:
On Tue, 2020-06-02 at 11:09 +0200, Michael Osipov wrote:
Am 2020-06-02 um 00:09 schrieb Michael Osipov:
Am 2020-06-01 um 15:11 schrieb Oleg Kalnichevski:
On Sun, 2020-05-31 at 23:13 +
Am 2020-06-02 um 11:36 schrieb Oleg Kalnichevski:
On Tue, 2020-06-02 at 11:09 +0200, Michael Osipov wrote:
Am 2020-06-02 um 00:09 schrieb Michael Osipov:
Am 2020-06-01 um 15:11 schrieb Oleg Kalnichevski:
On Sun, 2020-05-31 at 23:13 +0200, Michael Osipov wrote:
Am 2020-05-30 um 22:53 schrieb O
On Tue, 2020-06-02 at 11:36 +0200, Oleg Kalnichevski wrote:
> On Tue, 2020-06-02 at 11:09 +0200, Michael Osipov wrote:
> > Am 2020-06-02 um 00:09 schrieb Michael Osipov:
> > > Am 2020-06-01 um 15:11 schrieb Oleg Kalnichevski:
> > > > On Sun, 2020-05-31 at 23:13 +0200, Michael Osipov wrote:
> > > >
On Tue, 2020-06-02 at 11:09 +0200, Michael Osipov wrote:
> Am 2020-06-02 um 00:09 schrieb Michael Osipov:
> > Am 2020-06-01 um 15:11 schrieb Oleg Kalnichevski:
> > > On Sun, 2020-05-31 at 23:13 +0200, Michael Osipov wrote:
> > > > Am 2020-05-30 um 22:53 schrieb Oleg Kalnichevski:
> > > > > On Sat,
Am 2020-06-02 um 00:09 schrieb Michael Osipov:
Am 2020-06-01 um 15:11 schrieb Oleg Kalnichevski:
On Sun, 2020-05-31 at 23:13 +0200, Michael Osipov wrote:
Am 2020-05-30 um 22:53 schrieb Oleg Kalnichevski:
On Sat, 2020-05-30 at 21:58 +0200, Michael Osipov wrote:
...
Now we need to decide if thi
Am 2020-06-01 um 15:11 schrieb Oleg Kalnichevski:
On Sun, 2020-05-31 at 23:13 +0200, Michael Osipov wrote:
Am 2020-05-30 um 22:53 schrieb Oleg Kalnichevski:
On Sat, 2020-05-30 at 21:58 +0200, Michael Osipov wrote:
...
Now we need to decide if this is as good as it gets or we want
to
put
more r
On Sun, 2020-05-31 at 23:13 +0200, Michael Osipov wrote:
> Am 2020-05-30 um 22:53 schrieb Oleg Kalnichevski:
> > On Sat, 2020-05-30 at 21:58 +0200, Michael Osipov wrote:
> > ...
> > > > Now we need to decide if this is as good as it gets or we want
> > > > to
> > > > put
> > > > more research into
Am 2020-05-30 um 22:53 schrieb Oleg Kalnichevski:
On Sat, 2020-05-30 at 21:58 +0200, Michael Osipov wrote:
...
Now we need to decide if this is as good as it gets or we want to
put
more research into it.
I read liked you idea of the chunks. 2048 seems too low for me
because
most well write wit
On Sat, 2020-05-30 at 21:58 +0200, Michael Osipov wrote:
>
...
> > #isDataAvailable is not cheap even with 1 ms timeout. Socket
> > timeout
> > granularity is far from being 1 ms. In fact it is pretty close to
> > 50
> > ms. If we are not careful we can easily end up with 50 ms overhead
> > for
Am 2020-05-29 um 10:04 schrieb Oleg Kalnichevski:
On Fri, 2020-05-29 at 00:46 +0200, Michael Osipov wrote:
Am 2020-05-28 um 22:51 schrieb Oleg Kalnichevski:
On Thu, 2020-05-28 at 22:01 +0200, Michael Osipov wrote:
Am 2020-05-28 um 10:40 schrieb Oleg Kalnichevski:
On Thu, 2020-05-28 at 00:02 +
On Fri, 2020-05-29 at 00:46 +0200, Michael Osipov wrote:
> Am 2020-05-28 um 22:51 schrieb Oleg Kalnichevski:
> > On Thu, 2020-05-28 at 22:01 +0200, Michael Osipov wrote:
> > > Am 2020-05-28 um 10:40 schrieb Oleg Kalnichevski:
> > > > On Thu, 2020-05-28 at 00:02 +0200, Michael Osipov wrote:
> > > >
Am 2020-05-28 um 22:51 schrieb Oleg Kalnichevski:
On Thu, 2020-05-28 at 22:01 +0200, Michael Osipov wrote:
Am 2020-05-28 um 10:40 schrieb Oleg Kalnichevski:
On Thu, 2020-05-28 at 00:02 +0200, Michael Osipov wrote:
...
Please try out this patch. This should now give us proper out
of
seque
On Thu, 2020-05-28 at 22:01 +0200, Michael Osipov wrote:
> Am 2020-05-28 um 10:40 schrieb Oleg Kalnichevski:
> > On Thu, 2020-05-28 at 00:02 +0200, Michael Osipov wrote:
> > >
> >
> >
> > ...
> >
> > > > Please try out this patch. This should now give us proper out
> > > > of
> > > > sequence r
Am 2020-05-28 um 10:40 schrieb Oleg Kalnichevski:
On Thu, 2020-05-28 at 00:02 +0200, Michael Osipov wrote:
...
Please try out this patch. This should now give us proper out of
sequence response check with minimal overhead. The check will now
be
performed for chunks of 2048 bytes instead of
On Thu, 2020-05-28 at 00:02 +0200, Michael Osipov wrote:
>
...
> > Please try out this patch. This should now give us proper out of
> > sequence response check with minimal overhead. The check will now
> > be
> > performed for chunks of 2048 bytes instead of each and every write
> > operations.
Am 2020-05-27 um 22:51 schrieb Oleg Kalnichevski:
On Wed, 2020-05-27 at 22:14 +0200, Oleg Kalnichevski wrote:
On Wed, 2020-05-27 at 21:10 +0200, Michael Osipov wrote:
Am 2020-05-27 um 19:13 schrieb Oleg Kalnichevski:
On Wed, 2020-05-27 at 18:26 +0200, Michael Osipov wrote:
...
http
On Wed, 2020-05-27 at 22:14 +0200, Oleg Kalnichevski wrote:
> On Wed, 2020-05-27 at 21:10 +0200, Michael Osipov wrote:
> > Am 2020-05-27 um 19:13 schrieb Oleg Kalnichevski:
> > > On Wed, 2020-05-27 at 18:26 +0200, Michael Osipov wrote:
> > > >
> > >
> > > ...
> > >
> > >
> > >
> > >
>
>
htt
On Wed, 2020-05-27 at 21:10 +0200, Michael Osipov wrote:
> Am 2020-05-27 um 19:13 schrieb Oleg Kalnichevski:
> > On Wed, 2020-05-27 at 18:26 +0200, Michael Osipov wrote:
> > >
> >
> > ...
> >
> >
> >
> >
https://github.com/ok2c/httpcomponents-core/commit/732a99563e73529e0359625fda54351b843b2e
Am 2020-05-27 um 19:13 schrieb Oleg Kalnichevski:
On Wed, 2020-05-27 at 18:26 +0200, Michael Osipov wrote:
...
https://github.com/ok2c/httpcomponents-core/commit/732a99563e73529e0359625fda54351b843b2e34
This patch does not work (reliably):
* I have never seen EarlyResponseException
* Wh
On Wed, 2020-05-27 at 18:26 +0200, Michael Osipov wrote:
>
...
https://github.com/ok2c/httpcomponents-core/commit/732a99563e73529e0359625fda54351b843b2e34
>
> This patch does not work (reliably):
>
> * I have never seen EarlyResponseException
> * When run over HTTPS I see early responses som
Am 2020-05-27 um 14:47 schrieb Oleg Kalnichevski:
On Wed, 2020-05-27 at 14:32 +0200, Oleg Kalnichevski wrote:
...
https://github.com/apache/httpcomponents-client/commit/a554aadabafe26ae5412b26a311ffa105e623cc2
Tried with various timeouts, 5 ms, 15 ms, 25 ms, 50 ms, 500 ms.
Connections
On Wed, 2020-05-27 at 14:32 +0200, Oleg Kalnichevski wrote:
>
...
>
https://github.com/apache/httpcomponents-client/commit/a554aadabafe26ae5412b26a311ffa105e623cc2
> >
> > Tried with various timeouts, 5 ms, 15 ms, 25 ms, 50 ms, 500 ms.
> > Connections are correctly closed when:
> > * early re
On Wed, 2020-05-27 at 14:23 +0200, Michael Osipov wrote:
> Am 2020-05-27 um 12:14 schrieb Oleg Kalnichevski:
> > On Wed, 2020-05-27 at 00:01 +0200, Michael Osipov wrote:
> > > Am 2020-05-26 um 23:09 schrieb Oleg Kalnichevski:
> > > > On Tue, 2020-05-26 at 22:28 +0200, Michael Osipov wrote:
> > > >
Am 2020-05-27 um 12:14 schrieb Oleg Kalnichevski:
On Wed, 2020-05-27 at 00:01 +0200, Michael Osipov wrote:
Am 2020-05-26 um 23:09 schrieb Oleg Kalnichevski:
On Tue, 2020-05-26 at 22:28 +0200, Michael Osipov wrote:
Am 2020-05-26 um 20:20 schrieb Oleg Kalnichevski:
On Tue, 2020-05-26 at 17:58 +
On Wed, 2020-05-27 at 00:01 +0200, Michael Osipov wrote:
> Am 2020-05-26 um 23:09 schrieb Oleg Kalnichevski:
> > On Tue, 2020-05-26 at 22:28 +0200, Michael Osipov wrote:
> > > Am 2020-05-26 um 20:20 schrieb Oleg Kalnichevski:
> > > > On Tue, 2020-05-26 at 17:58 +, Bernd Eckenfels wrote:
> > > >
On Wed, 2020-05-27 at 11:48 +0200, Michael Osipov wrote:
> Am 2020-05-27 um 11:39 schrieb Oleg Kalnichevski:
> > On Wed, 2020-05-27 at 00:01 +0200, Michael Osipov wrote:
> > >
> >
> >
> > ...
> >
> > > So far, the patch works and I can access the first 401 response.
> > >
> >
> > I found a pr
Am 2020-05-27 um 11:39 schrieb Oleg Kalnichevski:
On Wed, 2020-05-27 at 00:01 +0200, Michael Osipov wrote:
...
So far, the patch works and I can access the first 401 response.
I found a pretty nasty bug in HttpClient that leads to re-use of
connections after request termination. I am wo
On Wed, 2020-05-27 at 00:01 +0200, Michael Osipov wrote:
>
...
> So far, the patch works and I can access the first 401 response.
>
I found a pretty nasty bug in HttpClient that leads to re-use of
connections after request termination. I am working on a fix.
Oleg
-
Am 2020-05-26 um 23:09 schrieb Oleg Kalnichevski:
On Tue, 2020-05-26 at 22:28 +0200, Michael Osipov wrote:
Am 2020-05-26 um 20:20 schrieb Oleg Kalnichevski:
On Tue, 2020-05-26 at 17:58 +, Bernd Eckenfels wrote:
Michael, this looks a bit like the packets in between have been
TLS
handshakes
On Tue, 2020-05-26 at 22:28 +0200, Michael Osipov wrote:
> Am 2020-05-26 um 20:20 schrieb Oleg Kalnichevski:
> > On Tue, 2020-05-26 at 17:58 +, Bernd Eckenfels wrote:
> > > Michael, this looks a bit like the packets in between have been
> > > TLS
> > > handshakes which have not been carried out
Am 2020-05-26 um 20:20 schrieb Oleg Kalnichevski:
On Tue, 2020-05-26 at 17:58 +, Bernd Eckenfels wrote:
Michael, this looks a bit like the packets in between have been TLS
handshakes which have not been carried out because the engine was not
kicked off. Maybe a starHandshake() would help? Or
_
> Von: Michael Osipov
> Gesendet: Dienstag, Mai 26, 2020 7:53 PM
> An: HttpClient User Discussion
> Betreff: Re: Server-side mid-air connection close on upload
>
> Am 2020-05-26 um 09:14 schrieb Oleg Kalnichevski:
> > On M
Von: Michael Osipov
Gesendet: Dienstag, Mai 26, 2020 7:53 PM
An: HttpClient User Discussion
Betreff: Re: Server-side mid-air connection close on upload
Am 2020-05-26 um 09:14 schrieb Oleg Kalnichevski:
> On Mon, 2020-05-25 at 11:56 +0200, Michael Osipov wr
Am 2020-05-26 um 09:14 schrieb Oleg Kalnichevski:
On Mon, 2020-05-25 at 11:56 +0200, Michael Osipov wrote:
...
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.
On Mon, 2020-05-25 at 11:56 +0200, Michael Osipov wrote:
>
...
> 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.
>
Hi Michael
Please try out this bran
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 cou
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 cla
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
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, se
22, 2020 10:18:02 PM
> An: HttpClient User Discussion
> Betreff: Re: Server-side mid-air connection close on upload
>
> On Fri, 2020-05-22 at 19:25 +0200, Michael Osipov wrote:
> > Hi folks,
> >
> > I believe that this is a wellknown limitation in blocking I/O, but
>
Am 2020-05-22 um 22:18 schrieb Oleg Kalnichevski:
On Fri, 2020-05-22 at 19:25 +0200, Michael Osipov wrote:
Hi folks,
I believe that this is a wellknown limitation in blocking I/O, but
would
like to know how to solve/workaround this issue. The source
discussion
is here [1].
Bascially, I am post
Expect-continue was among first things implemented in Proximity, and it
worked well, as Maven Wagon uses it as well. No other "generic" solution
with plain httpClient (and back there it was 3.x).
T
On Fri, May 22, 2020, 22:18 Oleg Kalnichevski wrote:
> On Fri, 2020-05-22 at 19:25 +0200, Michae
User Discussion
Betreff: Re: Server-side mid-air connection close on upload
On Fri, 2020-05-22 at 19:25 +0200, Michael Osipov wrote:
> Hi folks,
>
> I believe that this is a wellknown limitation in blocking I/O, but
> would
> like to know how to solve/workaround this issue. The sour
On Fri, 2020-05-22 at 19:25 +0200, Michael Osipov wrote:
> Hi folks,
>
> I believe that this is a wellknown limitation in blocking I/O, but
> would
> like to know how to solve/workaround this issue. The source
> discussion
> is here [1].
>
> Bascially, I am posting a large file (~7 MB) to Tomca
Hi folks,
I believe that this is a wellknown limitation in blocking I/O, but would
like to know how to solve/workaround this issue. The source discussion
is here [1].
Bascially, I am posting a large file (~7 MB) to Tomcat 8.5.54 where the
resource needs to be authenticated:
69 [main] DEBU
45 matches
Mail list logo