>
> There are multiple logging APIs out there: Commons Logging, native
> Log4j2 logging facade, slf4j, Java util logging. There used to be a
> great deal of hatred directed at Commons Logging some while ago. We
> cannot make everyone happy. It is easier to not impose a particular
> choice of loggin
On Mon, 2019-12-23 at 12:00 -0800, Ryan Schmitt wrote:
> I don't even know what GMT+5 is. Yekaterinburg?
>
Hah! There is a number of relatively big cities in that time zone but
you have picked the right one.
> I have prepared a fix similar to yours that also removes extra
> > synchronization on
I don't even know what GMT+5 is. Yekaterinburg?
I have prepared a fix similar to yours that also removes extra
> synchronization on Queue instance variable.
I don't believe your fix is correct, because you appear to have removed the
reentrancy checks in `flushToSubscriber`. Those checks are ther
Since RxJava has been exonerated, I don't see a need to get rid of it here.
(And, in fact, I never ended up getting rid of it when I debugged the
problem on my end.)
On Mon, Dec 23, 2019 at 12:38 AM Oleg Kalnichevski wrote:
> On Sun, 2019-12-22 at 13:34 -0800, Ryan Schmitt wrote:
> > My first in
On Sun, 2019-12-22 at 15:37 -0800, Ryan Schmitt wrote:
> I think there are actually two field stores where we can race: one is
> `subscription`, and the other is `requests`. Also, I think that the
> simplest thing to do is to mark the `flushToSubscriber` method
> `synchronized`. (The `flushInProgre
On Sun, 2019-12-22 at 13:34 -0800, Ryan Schmitt wrote:
> My first instinct here is to rewrite `publisherToByteArray` without
> the use
> of RxJava.
This is the very first thing I had to do. Please consider incorporating
this change-set into your PR
https://github.com/rschmitt/httpcomponents-cli
I think there are actually two field stores where we can race: one is
`subscription`, and the other is `requests`. Also, I think that the
simplest thing to do is to mark the `flushToSubscriber` method
`synchronized`. (The `flushInProgress` field is used to implement
non-reentrancy, rather than mutu
I think I figured it out. I added debug logging to ReactiveDataConsumer and
ReactiveEntityConsumer, and then I injected randomized sleeps at various
points in the code in order to try to induce races. Check out the following:
https://gist.githubusercontent.com/rschmitt/51ba439f5141e6cac8b6e148e29c
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:
On Sun, 2019-12-22 at 10:28 +0100, Oleg Kalnichevski wrote:
> On Sat, 2019-12-21 at 10:58 +0100, Oleg Kalnichevski wrote:
> >
>
>
> ...
>
> >
> > It appears that the defect only occurs with TLS transport and
> > entity
> > enclosing requests. It also looks to be a race condition of some
> > so
On Sat, 2019-12-21 at 10:58 +0100, Oleg Kalnichevski wrote:
>
...
>
> It appears that the defect only occurs with TLS transport and entity
> enclosing requests. It also looks to be a race condition of some
> sort.
> It is nearly impossible to reproduce with context / wire logging on.
>
> I wi
11 matches
Mail list logo
