Hi Oleg, My call would be to rework it rather than leave it as is or revert #660 wholesale.
I still think using a monotonic clock is the right thing for purely internal elapsed-time calculations, such as waits, timeout loops, H2 stream timeout accounting and linger periods. I would keep those changes. Where I think we went wrong was changing the semantics of the timestamps exposed by IOSession. Those values cross the reactor boundary and are consumed by pooling code, so making them relative System.nanoTime() values forces the same time domain onto their consumers and creates exactly the inconsistency we are seeing now. I would therefore restore IOSession#getLastReadTime(), getLastWriteTime() and getLastEventTime() to absolute millisecond timestamps, and keep System.nanoTime() only where the value is local to an elapsed-time calculation. That gives us a fairly simple rule: absolute timestamps crossing component boundaries use milliseconds / wall clock; internal duration accounting can use a monotonic clock. I think that would restore the previous conceptual model without throwing away the useful parts of #660. Cheers, Arturo On Thu, Oct 1, 2026 at 4:20 PM Oleg Kalnichevski <[email protected]> wrote: > On Thu, 2026-10-01 at 13:55 +0200, Arturo Bernal wrote: > > Hi Oleg, > > > > The main reason for #660 was not nanosecond precision. The intention > > was to > > use a monotonic clock for timeout and elapsed-time accounting, so > > those > > calculations would not be affected by wall-clock adjustments. > > > > Looking at it now, I think the mistake was changing the timestamps > > exposed > > by IOSession to the monotonic time domain without also considering > > all > > their consumers. The reactor and H2 timeout code moved to > > System.nanoTime(), > > while connection pooling still uses absolute millisecond timestamps. > > > > So if IOSession#getLastEventTime() is meant to remain monotonic, its > > consumers would need to use the same time domain. Alternatively, we > > may > > want to reconsider whether relative reactor timestamps should be > > exposed > > through IOSession at all. > > > > In other words, monotonicity was the goal of #660, not nanosecond > > precision, but I agree that the current split between relative and > > absolute > > timestamps is inconsistent. > > > > Cheers, > > > > Arturo > > > > What do we do now? We can leave everything as is, document the decision > and live with it. But I am sure the lack of conceptual inconsistency > will be hurting us going forward. > > Alternatively we can revert or rework your changes to restore the > previous behavior. What would be your call? > > Oleg > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
