[undertow-dev] Date Handler time (optimisation)

Hello, in Undertow 1.0.1 the DateHandler retrieves System.nanoTime() on each request and compares it against a deadline to decide if it should also query wallclock (via System.currentTimeMillis). I see two possible optimizations here: If the "Record request start time" option is set, the nanos value can be read from the exchange.getRequestStartTime and does not need another query. (Alternatively you can switch the record option off and make DateHandler write to exchange.setRequestStartTime() to make the syscall count: the additional time is available without specifying the RECORD option). The alternative optimization is about not using the nanos clock for determining if cached value is stale but directly requesting the wallclock millis. For one, I think the latency of nanoTime is not much better (on some systems worse) than System.currentTime (after all, it is an hotspot intrinsic) and every second both clocks would be asked (multiple times its a race). When having the current millis value, you could also check if actually the next second has started (and avoid the rouding problem with "nanos + 1000000000". (And again, if the wallclock time is determined this way, it would make sense to add it as a field on exchange?) The code+cache is BTW in two places: io.undertow.util.DateUtils.addDateHeaderIfRequired(HttpServerExchange) io.undertow.server.handlers.DateHandler.handleRequest(HttpServerExchange) BTW: I think the documentation should mention this. Here are some things which should be included (somewhere): "If you do not add the DateHandler Undertow might still add a Date: header if response does not have one and the ALWAYS_SET_DATE Header option is TRUE or missing. Using "ALWAYS_SET_DATE" is prefered, as it will use the latest possible time before the response entity is generated. The name of the option might be missleading, it does not ansure the header is always overwritten, it only ensures there is one set if there was not produced by the handlers." Once the above options are discussed and decided I can provide patches for the various doc locations. Bernd PS: I participated in an experiment* from Aleksey (of JMH fame) and had a few strange results where currentTime had high latency, on the other hand there are cases where nanoTime has high latency as well (see http://shipilev.net/blog/2014/nanotrusting-nanotime/). I think overall typical numbers show comparable latencies for both (<20ns). I asked him, if he can share his experiences. * https://github.com/shipilev/timers-bench