+1
On Sun, Nov 6, 2022 at 2:08 PM Oleg Kalnichevski wrote:
>
> Please vote on releasing these packages as HttpClient 5.2.
> The vote is open for the at least 72 hours, and only votes from
> HttpComponents PMC members are binding. The vote passes if at least
> three binding +1 votes are cast and
+1
On Sun, Nov 6, 2022 at 2:08 PM Oleg Kalnichevski wrote:
>
> Please vote on releasing these packages as HttpClient 5.2.
> The vote is open for the at least 72 hours, and only votes from
> HttpComponents PMC members are binding. The vote passes if at least
> three binding +1 votes are cast and
+1
On Wed, Nov 9, 2022 at 10:23 AM Oleg Kalnichevski wrote:
> Please vote on releasing these packages as HttpCore 5.1.5.
> The vote is open for the at least 72 hours, and only votes from
> HttpComponents PMC members are binding. The vote passes if at least
> three binding +1 votes are cast and t
+1
On Sat, Nov 26, 2022 at 1:51 AM Oleg Kalnichevski wrote:
> Please vote on releasing these packages as HttpCore 4.4.16.
> The vote is open for the at least 72 hours, and only votes from
> HttpComponents PMC members are binding. The vote passes if at least
> three binding +1 votes are cast and
+1
On Wed, Nov 30, 2022 at 10:48 AM Oleg Kalnichevski wrote:
> Please vote on releasing these packages as HttpClient 4.5.14.
> The vote is open for the at least 72 hours, and only votes from
> HttpComponents PMC members are binding. The vote passes if at least
> three binding +1 votes are cast a
I'm sending this along on behalf of a colleague who is having trouble
getting through to the distribution list.
Hi Apache client developers,
It looks like the org.brotli.dec dependency was updated upstream for three
years after the final version was published in Maven Central [1], including
[x] +1 Release the packages as HttpClient 5.3-alpha1
On Tue, Aug 15, 2023 at 2:39 AM Oleg Kalnichevski wrote:
> Please vote on releasing these packages as HttpClient 5.3-alpha1.
> The vote is open for the at least 72 hours, and only votes from
> HttpComponents PMC members are binding. The vote p
+1
On Fri, Nov 24, 2023 at 11:12 AM Oleg Kalnichevski wrote:
> Please vote on releasing these packages as HttpCore 5.2.4.
> The vote is open for the at least 72 hours, and only votes from
> HttpComponents PMC members are binding. The vote passes if at least
> three binding +1 votes are cast and
+1
On Sun, Dec 3, 2023 at 1:43 AM Oleg Kalnichevski wrote:
> Please vote on releasing these packages as HttpClient 5.3.
> The vote is open for the at least 72 hours, and only votes from
> HttpComponents PMC members are binding. The vote passes if at least
> three binding +1 votes are cast and th
+1
On Fri, Dec 15, 2023 at 5:39 AM Oleg Kalnichevski wrote:
>
> Please vote on releasing these packages as HttpCore 5.3-alpha1.
> The vote is open for the at least 72 hours, and only votes from
> HttpComponents PMC members are binding. The vote passes if at least
> three binding +1 votes are cas
+1
On Wed, Dec 20, 2023 at 10:01 AM Oleg Kalnichevski wrote:
> Please vote on releasing these packages as HttpCore 5.3-alpha1.
> The vote is open for the at least 72 hours, and only votes from
> HttpComponents PMC members are binding. The vote passes if at least
> three binding +1 votes are cast
+1
On Tue, Dec 26, 2023 at 6:42 AM Oleg Kalnichevski wrote:
> Please vote on releasing these packages as HttpClient 5.4-alpha1.
> The vote is open for the at least 72 hours, and only votes from
> HttpComponents PMC members are binding. The vote passes if at least
> three binding +1 votes are cas
+1
On Sat, Feb 10, 2024 at 6:37 AM Oleg Kalnichevski wrote:
> Please vote on releasing these packages as HttpCore 5.3-alpha2.
> The vote is open for the at least 72 hours, and only votes from
> HttpComponents PMC members are binding. The vote passes if at least
> three binding +1 votes are cast
The way I look at it is that Apache HttpComponents is a pure Java library
that implements HTTP semantics as completely and correctly as possible. The
feature-richness is what distinguishes us from HttpURLConnection, and the
simplicity and WORA-ness of pure Java (with a tiny dependency closure) is
w
We've also seen some integration test failures with the latest releases,
but I'm struggling to find the time to investigate. If it comes down to it,
I won't vote against a release unless I have decent evidence of a
regression.
On Mon, May 20, 2024 at 12:42 PM Gary D. Gregory
wrote:
> Hi All,
>
>
+1
On Thu, Jun 27, 2024 at 1:25 AM Oleg Kalnichevski wrote:
> Please vote on releasing these packages as HttpCore 5.2.5.
> The vote is open for the at least 72 hours, and only votes from
> HttpComponents PMC members are binding. The vote passes if at least
> three binding +1 votes are cast and t
I don't know, but the build is broken due to a single trailing space on
line 139 of that class. (I don't know why the Travis badge says otherwise.)
On Sat, Nov 10, 2018 at 9:56 AM Gary Gregory wrote:
> Hi All:
>
> Is there any reason the following is not an enum?
>
> org.apache.hc.core5.http.imp
I've been looking into an issue with TLS handshake timeouts on the
async client (see
https://github.com/apache/httpcomponents-client/pull/118), and I think
that this topic might benefit from a broader audit.
Currently, there are three types of timeouts we expose through RequestConfig:
1. Connecti
Defaults are another good topic of discussion. I personally think that
there should be some reasonable, finite default value for every
timeout. (I also think that max conns should be unlimited by default.)
But the first order of business is deciding exactly how we want the
existing timeout paramete
> I am sorry I fail to see any real issue with the current implementation
> of timeouts other than lack of documentation, so I am not sure I
> understand what you are proposing.
It very well may come down to documentation for the most part,
although I am curious what you think about the problems a
ssuring
me that this timeout *only* applies to connection initialization and
not request execution, but really either behavior is surprising.
TLS handshake timeouts have been discussed previously here:
https://issues.apache.org/jira/browse/HTTPCLIENT-1478
On Thu, Nov 15, 2018 at 12:29 PM Ryan Schm
Fair enough, this mainly sounds like a matter of documentation. I
still think there's some connectTimeout/socketTimeout confusion in the
synchronous client, which I'm working on fixing.
On Fri, Nov 16, 2018 at 2:50 AM Oleg Kalnichevski wrote:
> I personally do not see a problem here. Connect time
Where's the grief, exactly? The fact that these objects are showing up
in heap dumps does not imply performance impact, and no performance
impact was claimed, nor were any measurements provided. To state that
iterators "have to be garbage collected" is misleading; the Java
garbage collector traces
I threw together a quick JMH benchmark which shows that the iterator
is completely optimized out (results at bottom):
https://pastebin.com/eS7GbmNx
I take this as a demonstration of a more general principle, which is
that basic patterns in Java programming (e.g. virtual method calls,
object creat
I'm not sure what point you're making with these numbers. They're
effectively identical; the GC numbers in particular show no
appreciable allocation or collection in either benchmark.
On Mon, Nov 26, 2018 at 4:05 AM Oleg Kalnichevski wrote:
>
> I clearly cannot agree with your conclusion based on
33 AM Oleg Kalnichevski wrote:
>
> On Tue, 2018-11-27 at 11:12 -0800, Ryan Schmitt wrote:
> > I'm not sure what point you're making with these numbers. They're
> > effectively identical; the GC numbers in particular show no
> > appreciable allocation or collect
I looked into this a bit more, and it turns out that "how many
operations got executed within the same given period of time" is *not*
what you are measuring. Based on your JMH output, you are running in
SampleTime mode [1]:
/*
* Mode.SampleTime samples the execution time. With this mode,
The sampling interval is not fixed, and JMH tries to auto-adjust it
(according to the documentation).
On Tue, Nov 27, 2018 at 2:10 PM Oleg Kalnichevski wrote:
>
> Same benchmark time but different number of samples? This makes no
> sense.
>
> Oleg
I suppose that's possible, but there are several other modes available
that don't use sampling. If you're interested in throughput of heap
allocation, you can use Mode.Throughput with the GC profiler (partial
results shown):
Benchmark Mode Cnt
Score
If you're measuring throughput, it's better to disable GCProfiler, so
that the output will include error bounds (which can vary
substantially). On JDK8, I can only partially reproduce your results:
when asking for the tenth header in a list, `index` is 3-4% faster
than `iterator`:
Benchmark
I had a few basic questions about the division between core and client:
1. Why the split between core and client?
2. Are there consumers of core who don't also consume client?
3. What determines whether an abstraction lives in core or client? (For
example,
4. Does core contain any interfaces th
e to attack the root of this problem.
On Tue, Dec 4, 2018 at 3:21 AM Oleg Kalnichevski wrote:
> On Mon, 2018-12-03 at 14:11 -0800, Ryan Schmitt wrote:
> > I had a few basic questions about the division between core and
> > client:
> >
> > 1. Why the split between c
Kalnichevski wrote:
> On Tue, 2018-12-04 at 14:36 -0700, Gary Gregory wrote:
> > On Tue, Dec 4, 2018 at 12:54 PM Ryan Schmitt
> > wrote:
> >
> > > My concern with the core/client split is that I think it exposes
> > > tons of
> > > additional API
Would anyone be opposed to releasing another beta of httpcore5 soon? I have
some unfinished business on the client side (improved support for TLS
handshake timeouts), and that work depends on corresponding changes in core
that just barely missed the beta6 release cycle.
Sounds good.
On Wed, Jan 23, 2019 at 1:47 PM Oleg Kalnichevski wrote:
> On Wed, 2019-01-23 at 13:43 -0800, Ryan Schmitt wrote:
> > Would anyone be opposed to releasing another beta of httpcore5 soon?
> > I have
> > some unfinished business on the client side (imp
* Added convenience method to test if ContentType instances are of the same
MIME type
Contributed by Oleg Kalnichevski
* Merge connect and handshake timeouts in AbstractIOSessionPool
Contributed by Ryan Schmitt
* HTTPCLIENT-1960: URIBuilder incorrect handling of multiple leading
slashes in path
A member of my team has discovered a regression in beta6. I'll try to get
you a bug report today. This regression is a blocker, at least for our own
adoption and testing, so I'd like to fix it for beta7.
On Tue, Feb 5, 2019 at 6:39 AM Oleg Kalnichevski wrote:
> Ryan et al
>
> Would you like me t
https://issues.apache.org/jira/browse/HTTPCORE-568
On Tue, Feb 5, 2019 at 6:39 AM Oleg Kalnichevski wrote:
> Ryan et al
>
> Would you like me to cut 5.0-beta7 this weekend or should you like to
> be a release manager for this release?
>
> Oleg
>
>
>
>
Almost! My colleague has one more subtle bugfix to merge first:
https://github.com/apache/httpcomponents-core/pull/111
On Fri, Feb 22, 2019 at 11:31 AM Gary Gregory
wrote:
> Let's fire up the new beta! :-)
>
> Gary
>
> On Sat, Feb 16, 2019, 09:26 Oleg Kalnichevski
> > On Sat, 2019-02-16 at 09:
I have a local commit that upgrades HttpClient5 to HttpCore5-beta7. I'll
most likely be able to submit a PR for it tomorrow, I just wanted to give a
heads up before anyone else duplicates the same work.
[x] +1 Release the packages as HttpCore 5.0-beta7.
On Wed, Feb 27, 2019 at 12:02 AM Oleg Kalnichevski wrote:
> Please vote on releasing these packages as HttpCore 5.0-beta7.
> The vote is open for the at least 72 hours, and only votes from
> HttpComponents PMC members are binding. The vote passe
Rats. We'll take a look.
On Sat, Mar 2, 2019 at 9:10 AM Oleg Kalnichevski wrote:
> On Sat, 2019-03-02 at 13:04 +, Apache Jenkins Server wrote:
> > See <
> >
> https://builds.apache.org/job/httpcomponents-core-5.x/681/display/redirect?page=changes
> > >
> >
>
> Ryan
>
> It looks like there is
None here.
On Mon, Mar 18, 2019 at 2:36 PM Oleg Kalnichevski wrote:
> Folks
>
> Any objections to releasing HttpClient 4.5.8 and 5.0-beta4 this month?
>
> Cheers
>
> Oleg
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@hc.apac
+1
On Tue, Mar 26, 2019 at 7:38 AM Oleg Kalnichevski wrote:
> Please vote on releasing these packages as HttpClient 4.5.8.
> The vote is open for the at least 72 hours, and only votes from
> HttpComponents PMC members are binding. The vote passes if at least
> three binding +1 votes are cast an
I think I can live with AsyncDataConsumer as-is, now that the #consume
returns void. Since it seems that initial buffering requirements are here
to stay (as per our discussion in [1]), it would be nice to reify them in
the interface somehow.
[1]
https://github.com/apache/httpcomponents-core/pull/9
5.0.x? (I remember you mentioning that the 5.1.x series may include an
upgrade to JDK8, but that's not quite the same thing as a breaking API
change.)
On Fri, Apr 5, 2019 at 2:30 PM Oleg Kalnichevski wrote:
> On Fri, 2019-04-05 at 12:10 -0700, Ryan Schmitt wrote:
> > I think I can live w
[x] +1 Release the packages as HttpClient 4.5.9
On Fri, Jun 7, 2019 at 6:33 AM Oleg Kalnichevski wrote:
> Please vote on releasing these packages as HttpClient 4.5.9.
> The vote is open for the at least 72 hours, and only votes from
> HttpComponents PMC members are binding. The vote passes if a
> Therefore the HttpClient's default retry implementation does no longer
retry Connection Resets happening while reading on an established
connection, because all SSLException are excluded from retries.
I'm trying to understand exactly which failure mode is affected by the
underlying change. I thi
My numbers show roughly the opposite, but unfortunately I can't share the
code.
=
Apache-HttpClient5
=
Concurrency level : 50
Time taken for tests: 4.91 secs
Complete requests : 100,000
Failed requests : 0
Requests per
+1
On Thu, Jul 18, 2019 at 3:41 AM Oleg Kalnichevski wrote:
> Please vote on releasing these packages as HttpClient 5.0-beta5.
> The vote is open for the at least 72 hours, and only votes from
> HttpComponents PMC members are binding. The vote passes if at least
> three binding +1 votes are cast
In testing the beta5 release, I've noticed an apparent regression in the
async client. I have integration tests that exercise the code path where
TLS hostname verification fails (such as due to the use of a self-signed
certificate). On beta5, these tests hang forever, because the
`SSLPeerUnverified
The root cause is here:
https://github.com/apache/httpcomponents-core/commit/5c28eb27ee7504386aa788fbd688d5f885b6e68f#diff-6f4c6659a6b5b77a4c947b89d59d82c1R174
Because we are dealing with a TLS handshake exception, a `protocolHandler`
has not yet been set. I'm not sure how to fix this.
As for my
Do you want OracleJDK, or is OpenJDK acceptable? It looks like there's some
discussion about this elsewhere, e.g.:
https://travis-ci.community/t/cannot-install-oracle-jdk-11/3892/5
On Tue, Jul 23, 2019 at 3:26 AM Oleg Kalnichevski wrote:
> Folks
>
> Is there anyone here familiar enough with Trav
I don't understand how to fetch this commit, since it does not appear to be
associated with a branch.
On Thu, Jul 25, 2019 at 4:41 AM Oleg Kalnichevski wrote:
> On Wed, 2019-07-24 at 10:51 +0200, Oleg Kalnichevski wrote:
> > On Tue, 2019-07-23 at 12:21 -0700, Ryan Schmitt wrote:
I've applied these fixes locally and can confirm that they fix the issue.
On Sat, Jul 27, 2019 at 5:49 AM Oleg Kalnichevski wrote:
> On Fri, 2019-07-26 at 16:07 +0200, Oleg Kalnichevski wrote:
> > On Thu, 2019-07-25 at 14:06 -0700, Ryan Schmitt wrote:
> > > I don't
+1
On Sun, Sep 1, 2019 at 4:45 AM Oleg Kalnichevski wrote:
> Please vote on releasing these packages as HttpCore 4.4.12.
> The vote is open for the at least 72 hours, and only votes from
> HttpComponents PMC members are binding. The vote passes if at least
> three binding +1 votes are cast and t
Have you looked at the reactive extensions for HttpCore5? They demonstrate
how to implement AsyncEntityProducer/AsyncDataProducer with support for
backpressure (or you can just use the Reactive Streams API instead):
https://github.com/apache/httpcomponents-core/tree/master/httpcore5-reactive/src/m
+1
On Thu, Sep 5, 2019 at 5:01 AM Oleg Kalnichevski wrote:
> Please vote on releasing these packages as HttpClient 4.5.10.
> The vote is open for the at least 72 hours, and only votes from
> HttpComponents PMC members are binding. The vote passes if at least
> three binding +1 votes are cast and
ve a specific use case for a slow consumer, just want to know if
> I'm misunderstanding something.
>
> Thanks!
> Roy
>
> On Fri, Sep 6, 2019 at 10:15 AM Roy Hashimoto
> wrote:
>
> > Those are good leads, I'll pursue them.
> >
> > Thanks!
> >
JDK13 is out today, and it includes JEP 353, a rewrite of the legacy
(blocking) socket support. I installed it and ran some integration tests
that use HttpClient 4 and 5, and everything looks good so far.
The full JDK13 release notes are here: https://jdk.java.net/13/release-notes
According to RFC 7540, an HTTP/2 implementation may treat the negotiation
of a weak cipher suite (i.e. most cipher suites that have ever existed) as
a connection error. I'm skeptical of the way the client is currently
interpreting this part of the RFC: it is preemptively removing all of the
blackli
I'd like to do another beta release: beta9 for core, and beta6 for client.
Which bugs need to get fixed before the next release?
I'm working on it now. Relaxing the blacklisting behavior is a trivial
change. Verifying the chosen cipher suite after negotiation is not.
On Thu, Sep 26, 2019 at 2:07 PM Oleg Kalnichevski wrote:
> On Thu, 2019-09-26 at 14:03 -0700, Ryan Schmitt wrote:
> > I'd like to do a
Come to think of it, it looks like this fix won't require changes in core.
All the relevant code appears to live in the client (specifically the
`AbstractClientTlsStrategy` hierarchy).
On Thu, Sep 26, 2019 at 2:09 PM Ryan Schmitt wrote:
> I'm working on it now. Relaxing the
How is the `tlsDetailsFactory` field of `DefaultClientTlsStrategy` supposed
to get set when running on JDK11? I have a client that is successfully
negotiating h2 with ALPN, but `DefaultClientTlsStrategy#createTlsDetails`
is returning `null`. Without access to correct `TlsDetails`, I'm not able
to d
+1
On Tue, Oct 1, 2019 at 12:58 AM Oleg Kalnichevski wrote:
> Please vote on releasing these packages as HttpCore 5.0-beta9.
> The vote is open for the at least 72 hours, and only votes from
> HttpComponents PMC members are binding. The vote passes if at least
> three binding +1 votes are cast a
[x] +1 Release the packages as HttpClient 5.0-beta6
On Sun, Oct 6, 2019 at 8:09 AM Oleg Kalnichevski wrote:
> [x] +1 Release the packages as HttpClient 5.0-beta6
>
>
> On Sun, 2019-10-06 at 11:42 +0200, Oleg Kalnichevski wrote:
> > Please vote on releasing these packages as HttpClient 5.0-beta6
And my axe!
On Thu, Oct 24, 2019 at 11:39 AM Gary Gregory
wrote:
> I will be available :-)
>
> On Thu, Oct 24, 2019 at 9:26 AM Oleg Kalnichevski
> wrote:
>
> > Folks
> >
> > There has been a number of important fixes in master and 4.4.x branch.
> > I would like to cut new versions from both bra
[x] +1 Release the packages as HttpCore 5.0-beta10.
On Mon, Oct 28, 2019 at 1:56 AM Oleg Kalnichevski wrote:
> Please vote on releasing these packages as HttpCore 5.0-beta10.
> The vote is open for the at least 72 hours, and only votes from
> HttpComponents PMC members are binding. The vote pass
While we're on the subject, I want to add that upgrading from beta9 to
beta10 caused some of my integration tests to fail. I have not yet had a
chance to investigate the root cause.
On Sun, Nov 3, 2019 at 1:50 PM Michael Osipov wrote:
> Hi folks,
>
> I have made a shallow, non-exhaustive (maybe
7;ll do on Monday is git-bisect the changes between beta9 and beta10, and
just hope like hell that the problem is reasonably deterministic.
On Sun, Nov 3, 2019 at 2:00 PM Michael Osipov wrote:
> Am 2019-11-03 um 22:58 schrieb Ryan Schmitt:
> > While we're on the subject, I want t
Nevermind, false alarm. This turned out to be a compatibility issue between
core and client. I tried client version 5.0-beta7-SNAPSHOT (namely
commit d62616bb2929167b0cf25637df39aa912bcfd12c) and now everything works
fine.
On Sun, Nov 3, 2019 at 2:25 PM Ryan Schmitt wrote:
> To clarify,
Do you intend to remove the old connection pool implementations from 4.5.x,
or just deprecate them?
I would also like to echo Gary's question about binary compatibility, and
what the compatibility implications are more generally for the client.
On Tue, Nov 26, 2019 at 7:42 AM Oleg Kalnichevski w
There is one thing I was hoping to do before the GA release, which is to
build support for the Apache 5 client as an HTTP backend for the AWS Java
SDK V2 (which supports pluggable HTTP clients) and run their full suite of
integration tests. Unfortunately, the time leading up to re:Invent is
extreme
I fully agree with your sense of urgency around getting the GA out. In
every project there comes a time to shoot the engineers and start
production.
On Sat, Nov 30, 2019 at 2:18 AM Oleg Kalnichevski wrote:
> On Fri, 2019-11-29 at 14:44 -0800, Ryan Schmitt wrote:
> > There is one th
I'm working on an HTTP client integration that will allow Apache 5's async
client to be used as the HTTP backend for the AWS Java SDK [1]. One of the
first smoke tests I ran failed because the server responded to my request
with a TCP RST. I quickly realized that it was doing this because I was
sen
How does one enable session and wire logging? My code isn't doing anything
to enable it, although DEBUG logging is enabled in the underlying logging
framework (for testing).
On Fri, Dec 6, 2019 at 3:44 AM Oleg Kalnichevski wrote:
> On Thu, 2019-12-05 at 18:31 -0800, Ryan Schmitt wrote:
I'm running some HTTP/2 integration tests and I'm seeing the following in
the wire log:
15:33:11,667 - c- <<
"[0xffec][0x10][0xffe4])a[0xffbc][0x6]?:J[0xffc1]T[0xffb7];"
15:33:11,667 - c- << stream 0 frame: GOAWAY (0x7); flags: (0x0);
length: 35
15:33:11,667 - c
I've opened a PR [1] that adds a decent amount of client-based test
coverage for the reactive extensions. As I mentioned in the commit message,
these tests indicate the existence of at least two bugs that need to be
addressed. In the case of `testSequentialHeadRequests`, I have additional
changes (
not using Huffman compression?
I'll take whatever I can get. The more sources of complexity I can disable,
the more code I can rule out (or rule in). I'll see about the approach of
marking all the headers sensitive.
On Tue, Dec 10, 2019 at 5:06 AM Oleg Kalnichevski wrote:
> On Mon, 2
ommit/754d24853312d92a792a68ce21f062fe0fa5c0da
On Tue, Dec 10, 2019 at 5:11 AM Oleg Kalnichevski wrote:
> On Mon, 2019-12-09 at 21:10 -0800, Ryan Schmitt wrote:
> > I've opened a PR [1] that adds a decent amount of client-based test
> > coverage for the reactive extensions. As I mentioned in the comm
I've submitted a pull request [1] to add support for the Apache 5 async
client as an HTTP backend for the AWS Java SDK v2. Please take a look and
let me know what you think.
[1] https://github.com/aws/aws-sdk-java-v2/pull/1543
.
On Wed, Dec 11, 2019 at 1:40 AM Oleg Kalnichevski wrote:
> On Tue, 2019-12-10 at 12:15 -0800, Ryan Schmitt wrote:
> > Take a look at [1], which fixes the empty response bug in the non-
> > minimal
> > clients. Does this look right to you? I'm not really convinced. It
>
11 at 09:33 +0100, Oleg Kalnichevski wrote:
> > On Tue, 2019-12-10 at 10:54 -0800, Ryan Schmitt wrote:
> > > > That sounds a bit unsettling. Any theory as to why the defect has
> > > > not
> > > > been manifesting itself with the existing integration tests?
>
Is the legal "grammar" of calls to AsyncResponseConsumer or
AsyncDataConsumer spelled out anywhere? For instance, can I assume that
`consumeResponse` is always called before `releaseResources`?
On Wed, Dec 11, 2019 at 10:14 AM Ryan Schmitt wrote:
> Okay. This is another possibi
I've discovered a few things about the HPACK errors I'm seeing during
integration testing:
- They are deterministic: they always occur on the
first RegisterStreamConsumer call, which is usually assigned streamId 17 or
so on the h2 connection.
- They are completely unaffected by disabling Huffman e
I've isolated the HEADER frames [1] and locally replicated Netty's decoding
errors:
DefaultHttp2Headers[:method: POST, :scheme: https, :authority:
kinesis.us-west-2.amazonaws.com, :path: /, amz-sdk-invocation-id:
792fc679-6a8f-5de3-3298-ab18e2e027cc, amz-sdk-retry: 0/0/500,
authorization: AWS4-HMA
I've cracked it. I'll soon send out a PR, which will be self-explanatory.
On Thu, Dec 12, 2019 at 1:21 AM Oleg Kalnichevski wrote:
> On Wed, 2019-12-11 at 23:25 -0800, Ryan Schmitt wrote:
> > I've discovered a few things about the HPACK errors I'm seeing d
For what it's worth, there are still a lot of serious bugs that need to be
tracked down. It took me a day and a half just to find and fix the HPACK
bug, and while running and re-running various tests I've seen all kinds of
bizarre behaviors, including tests deadlocking, GOAWAY (INTERNAL_ERROR)
fram
I would like to propose the following changes:
1. The `parent`, `core`, `client`, `website`, and `stylecheck` source trees
shall be consolidated into a single Git repository for all of Apache
HttpComponents 5.
2. All artifacts contained in this repository shall be co-versioned (i.e.
released in co
I don't think core is special in this regard, but I *do* think it is
special in having a separate release cycle. Most Java projects these days
use version alignment (and usually a unified repository as well), despite
featuring many distinct components that all move at different speeds.
Examples inc
I'm chasing down the flow control bugs in AbstractH2StreamMultiplexer, and
I had a few questions:
1. Why do we use `Integer.MAX_VALUE` on lines 378 and 1007?
2. Why is there only one `lowMark` field, used for both input and output
windows? Shouldn't there be two, since the local and remote windows
Does httpcore5 have an equivalent to IOReactor#getAuditLog?
It sounds like these changes aren't going to happen, but I'm going to press
the point anyway because I think this is important.
> I am not sure I can agree with that. Usually one should care about the
> top level library such as HttpClient or HttpAsyncClient only. One needs
> to manually override
Adding the list.
On Wed, Dec 18, 2019 at 12:12 AM Ryan Schmitt wrote:
> I found and fixed the main flow control bug that was tormenting me, but I
> still think that this `lowMark` business needs a second look. It doesn't
> impact correctness as far as I can tell, but the curre
>
> My original intention with lowMark was to allow individual data
> producers to produce capacity updates before their respective capacity
> window hits zero and the data stream stalls. I am open to newer ideas
> or better solutions.
>
The concept makes perfect sense, the implementation is just
Does "single core" mean single-threaded?
>
> Single core reactors now use Callback exceptionCallback to
> report any unexpected error instead of maintaining an internal queue of
> events. Usually the default callback implementation logs exceptions
> with ERROR priority.
>
> Oleg
>
>
> I could definitely use help with these. I think I'll push my HttpClient
> branch to GitHub so you can run what I'm running and hopefully reproduce
> the problem. It's non-deterministic, but I get a test failure at least 25%
> of the time in my IDE.
>
Here it is (requires the latest commit of H
>
> I do not know what IDE you use but IntelliJ IDEA makes it completely
> effortless to run SNAPSHOT versions of multiple modules within the same
> project.
I don't know how to develop separate Maven projects as if they were a
single project. I do know how to do this with Gradle, which has a fea
My first instinct here is to rewrite `publisherToByteArray` without the use
of RxJava. I'll take a crack at that, but first I need to figure out how to
set up IntelliJ with core and client in the same workspace.
On Sun, Dec 22, 2019 at 5:10 AM Oleg Kalnichevski wrote:
> On Sun, 2019-12-22 at 10:
1 - 100 of 361 matches
Mail list logo
