There are no JMX notifications that occur upon individual method
contexts (or servlet requests) taking longer than a threshold.
That said, there are extensive logging options for both method contexts
and servlet requests in R9 and higher. [There are fairly extensive
logging options for servlet requests in R8 M050 when JMX is enabled
there, but method context improvements are not present until R9.x.]
What options depends on the release and MOR level you're at, but some
things to note:
* The wt.method.server.timing logger output can be routed to a
separate file via normal log4j configuration approaches.
* The wt.method.MethodContextMonitor.contexts logger provides much
more capability than wt.method.server.timing.
o This logger can be dynamically configured through the
corresponding MBean (located at com.ptc -> Monitors ->
MethodContexts in the MBean tree).
o There is a similar logger for servlet requests,
wt.servlet.ServletRequestMonitor.request -- also configured
through a corresponding MBean (located at com.ptc ->
WebAppContexts -> /WindchillWebAppName /-> Monitors ->
ServletRequests).
o For both of these loggers:
+ Only ERRORs are logged out-of-the-box, but you can
increase the verbosity.
# INFO will log all requests/contexts.
# WARN will log only those which take longer than
a specified threshold.
* One could actually configure a
wt.log4j.jmx.JMXAppender on the logger in
such a case to produce a JMX notification
for each log message. One could then add
a NotificationHandler to the JMX
configuration to produce e-mails to the
administrator in such a case.
+ One can control which attributes are logged and how
the data is formatted through the corresponding MBean.
+ In recent R9.1 MORs, one can output this data to a
log4j Appender using a wt.log4j.jmx.TSVLayout, which
will produce a tab separated value file (for easy
reading by Excel or OpenOffice) or to the relational
database using a wt.log4j.jmx.AsyncJDBCAppender.
# In either case each attribute goes to a separate
column for easy data mining without ugly parsing.
# In recent R9.1 MORs there are similar loggers,
wt.method.MethodContext.contextMBean.finish and
wt.servlet.ServletRequestMonitor.requestMBean.finish,
that allow you to choose which attributes are
logged separately from the "normal" logging and
at what verbosity.
* This is specifically to facilitate logging
one set of attributes to normal log files
at one verbosity and a different set at a
different verbosity to a specialized log4j
layout or appender like TSVLayout or
AsyncJDBCAppender.
* The attribute selection is done by layout
or appender in this case.
o In recent releases/MORs, there are also FilteredLogger
MBeans associated with the MethodContexts and
ServletRequests MBeans that allow you do log specific to a
separate logger at a different log level for specific users,
request URIs, etc.
o In recent releases/MORs, there's also functionality to allow
addition of custom request and/or method context listeners
to these MBeans to allow you to do you own logging, etc,
upon the begin and end of any request or method context.
In short, use wt.method.MethodContextMonitor.contexts (and
wt.servlet.ServletRequestMonitor.request) rather than
wt.method.server.timing in most cases and use as much of the other
material noted above as you have time/energy/need for.
--
Jess Holle
