Hello Stuart,
yes I agree it is a good compromise. I do wonder however if you should
use an atomic to set the new value to make sure you schedule only one
timer. I could imagine that it creates an avalanch of timers if 2
requests at the same time race to set the next date (and start 2
timers) and then the next expire 2x2 timers, etc.
(And I would also move the calculations for mod+togo after setting the
new dateString to make the window smaller
Gruss
Bernd
Am Wed, 04 Jun 2014
09:52:18 -0700 schrieb Stuart Douglas <notifications(a)github.com>:
Stuart Douglas <notifications(a)github.com>
To: undertow-io/undertow <undertow(a)noreply.github.com>
Cc: Bernd <bernd(a)eckenfels.net>
Subject: Re: [undertow] Change to using a timer to invalidate the
date rather than calling nanoTime each request (07e3b93) Date: Wed,
04 Jun 2014 09:52:18 -0700 Reply-To: undertow-io/undertow
<reply+c-6555558-99b5c22664ba7984b00186177b011624000c5527-361432(a)reply.github.com>
The main issue I had with that is that it will run even if your
server is completely idle, and also that it adds additional lifecycle
complexity into the connectors, as they would need to have their
timers explicitly stopped on teardown. I think this is a good
compromise.
---
Reply to this email directly or view it on GitHub:
https://github.com/undertow-io/undertow/commit/07e3b9315c3d87205ef5ac8907...