[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jetty-users] Non deterministic behaviour of Request#getBeginNanoTime()
|
After further testing, we found that Request#getBeginNanoTime() is broken for https connectors in current jetty version. It seems like timestamps from the connection are propagated to a request that is actually done at a later point in time.
We will create an issue about this.
Best,
Matthias
Dec 6, 2024, 15:16 by jetty-users@xxxxxxxxxxx:
> So we noted that this only occurs if we run with https. When we run with http connector, Request#getBeginNanoTime() always returns the correct value.
>
> Best,
> Matthias
> Dec 5, 2024, 17:28 by jetty-users@xxxxxxxxxxx:
>
>> Hi,
>> we wanted to detect requests that were stuck in the Queue of the QueuedThreadPool for longer than 5 seconds. We therefore read Request#getBeginNanoTime() as soon as a request is dispatched and fail-fast in that case:
>>
>> var pendingTime = NanoTime.secondsSince(_request.getBeginNanoTime());
>> if (pendingTime > 5) { // send TooManyRequests with Retry-After} else { // handle request}
>>
>> We randomly get requests that are immediately dispatched but hit this requirement with several seconds of pendingTime and suspend our client. We're not quite sure what could cause this since System.nanoTime() should generally be safe to use across threads. Any ideas where the garbage time values could be coming from?
>>
>> Thanks!
>>
>> Best,
>> Matthias
>> _______________________________________________
>> jetty-users mailing list
>> jetty-users@xxxxxxxxxxx
>> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
>>
>
> _______________________________________________
> jetty-users mailing list
> jetty-users@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
>
