During Portal shutdown, user many see numerous AlarmThread Monitor warnings and associated call stacks on the activity of the threads even though the shutdown completes normally
Usually during Portal shutdown, warnings and stack traces similar to the following are shown several times
AlarmThreadMo W UTLS0008W: The return of alarm thread "Non-deferrable Alarm : 1" (0000001f) to the alarm thread pool has been delayed for 40968 milliseconds. This may be preventing normal alarm function within the application server. The alarm listener stack trace is as follows:
WebSphere Application Server 188.8.131.52 introduced new serviceability feature to enhance the monitoring/configurability of Alarm threads. However the various settings introduced have default values that are rather low and too low for Portal operations . One of the parameters is
which determines how long an alarm thread runs before the warning is issued. So, for example, if the default settings value of com.ibm.websphere.alarmthreadmonitor.threshold.millis is used then the warning and possible stack traces are generated if the alarm threads runs for 40 seconds.
The default value of 40 seconds is too low for normal WebSphere Portal activity.
Websphere Portal 7.0.*
Websphere Application Server 184.108.40.206 or later
Diagnosing the problem
The warning messages will show the monitoring threshold in effect.
Here are the various configurable settings made available to users:
If com.ibm.websphere.alarmthreadmonitor.enabled is set to true, then com.ibm.websphere.alarmthreadmonitor.threshold.millis determines when the warning is issued
Resolving the problem
The appropriate changes will be implemented in next future release of WebSphere Portal to have a threshold of at least 5 minutes in a new install(er). However, even with that since startup and shutdown times vary with hardware and size of configuration (in particular, the number of installed portlets and themes/skins), it is hard to tell in advance what is, but a clue of 300000 (5mins) should suffice for
most cases, but at the end of the day the customer will have to find the "right" value for their environment.
Note also that basically adjust how soon the warning could be displayed. If not, customer can also well disable it completely with
The settings can be configured using this link