I think conceptually this is fine, but I would want to do some performance testing before
we included this, to make sure that recording the start time for every invocation does not
hurt performance (which I suspect it will).
If this is the case (as I suspect it will be) then we need to basically make it
configurable, which is not that hard to do.
Your statement "If PathHandler and ResourceHandler(or another process) take a long
time, my idea doesn't work." is not really correct, the access log handler just
registers a completion listener to actually record the values, so the time measurement is
not taken until the exchange is complete.
If you create a JIRA about this I will try and find the time to test out performance later
this week, and if it is an issue I will add a way to make recoding the request start time
----- Original Message -----
From: "lanabe" <lanabe.lanabe(a)gmail.com>
Sent: Monday, 9 December, 2013 3:13:05 PM
Subject: [undertow-dev] About response time in access log
Now Undertow AccessLogHandler is not supported Response time(%D/%T), right?
I simply implemented it, but I'm not sure..
My code is
1) Add startTime:long field in HttpServerExchange
2) Initialize startTime and assign System.currentTimeMillis to it in
3) Create ResponseTimeAttribute and its readAttribute return
(System.currentTimeMillis - exchage.getStartTime)
Is it too simple?
I checked handler chain stack trace on WildFly Beta1.
<Some Handlers> -> AccessLogHandler -> PathHandler -> ResourceHandler
If PathHandler and ResourceHandler(or another process) take a long time, my
idea doesn't work.
undertow-dev mailing list