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 Queue<ByteBuffer> instance variable.
> 
> 
> I don't believe your fix is correct, because you appear to have
> removed the
> reentrancy checks in `flushToSubscriber`. Those checks are there to
> prevent
> *the same thread* from calling into `flushToSubscriber` multiple
> times, and
> racing against itself. This is more straightforward than it sounds;
> the
> call stack looks like:
> 
> `flushToSubscriber` -> `Subscriber#onNext` -> `Subscription#request`
> ->
> `flushToSubscriber`
> 

I was not aware of that. The #flushToSubscriber called recursively from
itself sounds quite nasty. It is something I would rather avoid but I
suppose you have considered that.    


> I actually like it a lot that core components do not depend on any
> > particular logging framework but feel free to add it to the
> > reactive
> > module if you deem it justified.
> 
> 
> I strongly agree that core should not depend on a logging _runtime_,
> but
> depending on a logging API is completely reasonable. I personally use
> log4j2 as my logging framework, but I routinely install bridges for
> JakartaCommons-logging, java.util.logging, log4j 1.2, and Slf4j 1.7,
> so the
> API doesn't really matter terribly. I'm surprised to hear that there
> was
> apparently some sort of religious war about this in the past.
> 

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 logging APIs unless necessary.

Oleg


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to