On 01.10.2026 18:32, Arturo Bernal wrote:
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.
Agreed. This needs to be the top priority task as it basically blocks
the 5.5 release.
One thing that worries me is that having to maintain two types of
timestamps (relative in nano precision and absolute in milli precision)
will harm performance of the i/o reactor. That would be the worst case
scenario.
Oleg
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
