Thank you for the answer Chris. You noted about confirmation of some
issues, and I'd been waiting for it until now.
You stated that "For a simple request, the timing will include any time
blocking on response buffers..." and it would be good enough for me, if
confirmed.
And I would like some clarification on "Depending on exactly where the
Valve falls within the Valve chain and how the RequestDispatcher works
with Valves, it may or may not include time to render the response at all."
On 2/22/2011 10:12 PM, Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Antonios,
On 2/21/2011 11:05 AM, Antonios Kogias wrote:
If we use tomcat 7.0.8, the "timing for the whole request processing
cycle" will incorporate transmit time?
e.g. if using HTTP/1.0, will it represent the total time until the
teardown of the connection? Or will it be the net processing time
/before/ transmission starts (i.e. time to prepare the http response and
push it to the network layer)?
(I'd like Konstantin to confirm the following, presuming it's true...)
The Valve terminates after the servlet (the code actually doing the
work) completed its work. For a simple request, the timing will include
any time blocking on response buffers but can't by definition include
any time waiting for the client to drain the buffer.
Depending on exactly where the Valve falls within the Valve chain and
how the RequestDispatcher works with Valves, it may or may not include
time to render the response at all. Let me explain:
Many servlets look like this:
public void doGet(...) {
try {
// do some stuff
getRequestDispatcher("/result.jsp").forward(request, response);
} catch (Exception e) {
// log the error, whatever
getRequestDispatcher("/error.jsp").forward(request, response);
}
}
If the Valve wraps around only the original request (to, say, servlet
"/foo") then you're only timing the execution of the code shown above:
the processing of result.jsp (or error.jsp for that matter) will be
shown in a separate log message.
I don't believe Apache httpd has a notion of an internal request forward
the way that Java does, so I'm not sure there's an analog, there.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk1kGKkACgkQ9CaO5/Lv0PA8WgCeP0uLrgXyT2sHkwRkbaVtsrkC
ZDsAoJQpc75Zl8iJYPzRPgKOhlOef/gw
=Ysn0
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
