[undertow-dev] [undertow] Change to using a timer to invalidate the date rather than calling nanoTime each request (07e3b93)

Bernd Eckenfels ecki at zusammenkunft.net
Sat Jun 7 16:54:59 EDT 2014


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 at github.com>:

>  Stuart Douglas <notifications at github.com>
> To: undertow-io/undertow <undertow at noreply.github.com>
> Cc: Bernd <bernd at 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 at 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/07e3b9315c3d87205ef5ac890767c277f29d9068#commitcomment-6555558



More information about the undertow-dev mailing list