Dear Wiki user, You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change notification.
The "TomcatGridDiscussion" page has been changed by theimpaler: https://wiki.apache.org/tomcat/TomcatGridDiscussion?action=diff&rev1=6&rev2=7 1. The managing logic must be clearly separated from the Web interface logic, since later on, a Command-Line Grid Manager will be included, and will use the same managing logic. 1. The available commands for each instance are: - * '''status''': retrieves the status of a Tomcat instance throught the corresponding Grid Agent + * '''status''': retrieves the status of a Tomcat instance through the corresponding Grid Agent * '''trigger-start''': sends a start request to the Tomcat instance using the corresponding Grid Agent * '''trigger-stop''': sends a stop request to the Tomcat instance using the corresponding Grid Agent * '''trigger-kill''': sends a kill request to the Tomcat instance using the corresponding Grid Agent @@ -126, +126 @@ 1. The status command now adds more information for each service (Tomcat instances and Grid Agents): * CPU usage (if possible) * CPU load (if possible) - * Head usage (if possible) + * Heap usage (if possible) * Threads (if possible) * Started on (if possible) * Any other information deemed useful for managing purposes. @@ -142, +142 @@ Included features are: - 1. In addition to the Web Grid Manager interface, the Command-Line Grid Manager interface is suitable when the web interface cannot be used. Typical cases are, when no web port is available on the servers (probably fire-walled), when the security policies do not allow remote server operations, etc. This maybe the case on some secured/fire-walled production environments where only text sessions are accessible. + 1. In addition to the Web Grid Manager interface, the Command-Line Grid Manager interface is suitable when the web interface cannot be used. Typical cases are, when no web port is available on the servers (probably fire-walled), when the security policies do not allow remote server operations, etc. This maybe the case on some secured/fire-walled production environments where only text sessions are acceptable. 1. The Command-Line Grid Manager is also suitable for automation (e. g. the weekly full/partial site restart) when unattended operations are scheduled, using cron or equivalent utilities. @@ -156, +156 @@ 1. The trigger commands are only executed when necessary. If an instance is already running a trigger-start command will be ignored. Conversely trigger-stop and trigger-kill commands are ignored when the instance is stopped. - 1. Return codes must be strategically defined to allow automation. Well defined return codes can provide useful information to the caller program/process, so it can clearly identify the problem and act accordingly. + 1. Return codes must be strategically defined to allow automation. Well defined return codes can provide useful information to the caller program/process (especially for automation), so it can clearly identify the problem and act accordingly. == Phase 6 - Hooks == Extending the core operation of the grid services with custom logic. Included features are: - 1. Hooks are extra activities we want to be performed when some events occur on each instance. A hook is implemented as a shell scripts (or other) and is linked to one of the following events: + 1. Hooks are integration points to include extra activities we want to be performed when some events occur on each Tomcat Instance or Grid Agent. A hook program is linked to a hook and may be implemented as a shell script or any other kind of executable program. Hooks can be defined for the following events: * '''pre-trigger-start''' * '''post-trigger-start''' * '''pre-trigger-stop''' @@ -179, +179 @@ * Send emails or other notifications upon restarts. * Clear caches & temp dirs before starting an instance. * Delay the start of an instance to allow the OS to reclaim resources. - * Generate thread dump on specific events. + * Generate thread dumps on specific events. - 1. Hooks scripts run on the machine where the affected instance runs. Therefore, the hooks script are copied and are ready to be executed on all machines of the grid. + 1. Hooks programs run on the machine where the affected instance runs. Therefore, the hooks programs need to be copied and prepared (manually or automagically) to be executed on all machines of the grid. - 1. When hooks are registered (maybe uploaded) on the Grid they are automatically distributed behind the scenes to all instances/machines before they are ready to use. + 1. When hooks programs are registered (maybe uploaded) on the Grid they are automatically distributed behind the scenes to all instances/machines before they are ready to be used. == Phase 7 - Enhanced Grid Operation == - Beyond the basic trigger operations, there's usually need for more complex ones, that provide very common needs but are seldom formally implemented. + Beyond the basic trigger operations, there's usually need for more complex ones that provide very common needs. Included features are: - 1. Non-trigger commands are added to both the Command-Line and Web interfaces: + 1. Non-trigger commands are added to both the Command-Line and Web Grid Managers: - * '''start''': waits until the operation succeeds or fail + * '''start''': triggers a start and waits until the operation succeeds or fail - * '''stop''': waits until the operation succeeds or fail + * '''stop''': triggers a stop and waits until the operation succeeds or fail - * '''kill''': waits until the operation succeeds or fail + * '''kill''': triggers a kill and waits until the operation succeeds or fail - * '''restart''': waits until the operation succeeds or fail; with configurable restart delay - * '''killstart''': waits until the operation succeeds or fail; with configurable restart delay + * '''restart''': triggers a stop, waits until it stops, triggers a start, wait until it starts + * '''killstart''': triggers a kill, waits until it stops, triggers a start, wait until it starts 1. The new commands operate on both types of services (instances and agents). @@ -211, +211 @@ * '''pre-killstart''' * '''post-killstart''' - 1. All these new commands use the trigger commands behind the scenes. + 1. All these new commands use the "trigger" primitives behind the scenes. - 1. The hooks for the non-trigger events are never ignored, so they are executed even if the related trigger commands are ignored. + 1. The hooks for the non-trigger events are never ignored, so the hook programs are executed even if the related trigger commands are ignored. - 1. Automatic trigger-kill operations are now be automatically issued for stop and restart operations if configured, when a trigger-stop fails to succeed in the configured limit of time. The time limit is now optionally specified in the configuration file on a per-service basis. + 1. Automatic trigger-kill operations are now automatically issued for stop and restart operations if configured, when a trigger-stop fails to succeed in the pre-configured time limit. The time limit is now optionally specified in the configuration file on a per-service basis. - 1. A restart delay (now optionally specified on a per-service bases on the configuration file) is used when restarting services: it applied to the restart and killstart commands. + 1. A restart delay (now optionally specified on a per-service bases on the configuration file) is used when restarting services: it's applied to the restart and killstart commands. 1. The non-trigger commands show an update of the service state periodically (defaults to every 10s, and can be specified on the configuration file), and they keep working until the full operation completes. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
