Corrective Actions

Cache or Recycling actions are available in the Corrective Actions section.

Clear Cache

The Clear Cache button is now available to clear internal tools caches for the process that has been selected. This should reduce the memory footprint of the process and may cause some performance impact while the caches are being rebuilt.

Recycle Kernel

You can now recycle an individual kernel which prevents a single process from impacting or bringing down the entire system. It also prevents new users from being associated with the kernel and possibly being impacted if the kernel zombies. This allows the system to gracefully shut down the kernel and reclaim resources.

There is a new button called Recycle Kernel that is used to begin recycling CallObject kernel processes on demand. The purpose of the recycling button is to allow administrators to gracefully shut down a process that appears to have problems.

Previously, the only options for an administrator were to allow the process to continue running or to kill the process from the OS. If the process were allowed to continue, it could become attached to new user sessions, which may be detrimental to those sessions, and which may make the perceived problems within the kernel process even worse than what they might have been. On the other hand, if the process were killed manually, the applications that were currently running would be ungracefully stopped, which would prevent the applications from completing, and would force any open transactions to be rolled back.

The recycling option tries to avoid both of those issues. When a kernel process begins recycling, there will be no additional user sessions attached to it. But, the kernel is not stopped immediately, which allows the current users to complete their processing. When all users have completed their processing, then that kernel will be shut down. Before KRM, kernel recycling was only available based on JDE.INI settings. The CallObject kernels could be recycled at a scheduled time. With the new KRM "Recycle Kernel" button, a selected kernel process can begin recycling on demand. Because runbatch and subsystem processes cannot be recycled, the Recycle Kernel button is not available for these processes.

There are additional JDE.INI settings that can affect how the kernels are recycled. After the time to begin recycling has passed, the state of the kernel goes into a "pending recycling" state. While recycling is pending, the kernel accepts no new user sessions. When all existing user sessions have logged off the kernel will shut down. There is a JDE.INI setting that specifies the length of a period of inactivity, before each user session is considered inactive. When that is set, and there are only inactive user sessions, the kernel will also shut down. The default time for the inactivity period is six hours. Another JDE.INI setting is the length of time before a forced termination occurs. When that period expires, the kernel will shut down, even if there are active users at that time. The assumption is that those user sessions have some reason why they will never initiate their own session logoff. For instance, the user could be stuck in a deadlock, or the user could be stuck in a loop that it cannot exit. There could also be users that are intentionally never logged off (there are some use cases for this with Interop user sessions). The default time for the forced termination is twelve hours.

Within the context of the KRM Recycle Kernel button, those JDE.INI recycling parameters will apply, even if scheduled kernel recycling is not set. The beginning of the recycling period will be when the Recycle Kernel button is pressed.