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 On Thu, Oct 1, 2026 at 10:06 AM Oleg Kalnichevski <[email protected]> wrote: > Hi Arturo > > I must admit I made a mistake reviewing this change-set you contributed > several months ago: > > https://github.com/apache/httpcomponents-core/pull/660 > > I misunderstood how System.nanoTime() worked and did not realize the > time values kept by the i/o reactor were now relative. > > This now creates the problem that out connection pooling code uses > millisecond based absolute values for time tracking but the i/o reactor > uses nanosecond based relative values. This makes the principles of > time tracking in our code inconsistent and more complex > > what is exactly the benefit of using nanosecond precision for i/o > reactor time tracking when the framework operates with _second_ > precision only. What do those nanoseconds really buy us? > > Oleg > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
