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&lt;notifications(a)github.com&gt;: > Stuart Douglas&lt;notifications(a)github.com&gt; > To: undertow-io/undertow&lt;undertow(a)noreply.github.com&gt; > Cc: Bernd&lt;bernd(a)eckenfels.net&gt; > 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&gt; > > 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... _______________________________________________ undertow-dev mailing list undertow-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/undertow-dev