I have a small patch that I think improves the session listing in the
manager webapp:
The doc says
============================
Session Statistics
Display the default session timeout for a web application, and the
number of currently active sessions that fall within ten-minute ranges
of their actual timeout times. For example, after restarting Tomcat and
then executing one of the JSP samples in the /examples web app, you
might get something like this:
============================
Actually that's not true and I have the impression the code does
something not very useful which we can very easily tranform to something
really useful:
At the moment the code calculates a histogramm of the different
maxInactiveInterval values for all sessions of a context. Now most
contexts I know, work with a fixed maxInactiveInterval for all sessions
in the context. As a result, all of the sessions are in the same
histogram class and instead of the possible up to 60 lines of result
histogram, the code always simply produces a single line showing again
the total number of sessions - which is already included on the same
page further down. So no real sense in that.
With a few lines of change we could easily list a histogram of how far
sessions are away from their idle timeout. That seems to be a much more
interesting information for monitoring, e.g. it enables to make a well
informed decision on shrinking or sizing up session timeouts. This would
also be in better alignment with the documntation of manger. This is
sugestion 1a.
What I would even like better is instead printing a hitogramm of the
actual idle time of the sessions. I think for most admins this is a more
easily understandable metric.
So suggestion 1b: change sessions-function in manager webapp to show a
histogram of session idle distribution instead of maxActiveTimeout
distribution.
Suggestion 2: another small fix would allow a manager user to
prematurely expire all sessions which are idle for a longer time than
the amount of minutes she types into a text field (before she presses
the new expire button.
I have a use case for this: some applications work with long running
sessions (employee applications) that might have relatively big
sessions. These applications typically have a timeout of several hours
to allow resumption of work after lunch breaks, meeting etc. Often such
apps depend on other external applications. When those have a bad day,
the users of the web app might experience very long response times. So
they decide to try a new login to the web app. From that point in time
their old sessions are no longer used, but still stay in memory for
several more hours. As soon as the external app has another hickup,
another round of sessions gets lost by the same user behaviour. A well
informed admin could now react to such a non-standard situation by
deciding to expire all sessions which are idle longer than the amount of
minutes she decides, e.g. one hour.
I did all that for TC5 and for 5.5 it's mostly the same. If their is
interest in it, I would provide patches, including doc patches. I still
would need spanish and japanese translations for "expire". :)
Feedback is highly welcome.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
