Hosted by:

wrapper.commandfile Property

wrapper.commandfile Property

Configuration Property Overview

- Configuration Property Overview
- Advanced Properties
- Property List by Name

wrapper.commandfile

File which will be monitored for commands to be executed. If set, the Wrapper will check at regular intervals for the existence of the specified file. When found, the file will be opened and all commands will be executed in order. Upon completion, the file will be deleted. This property is not set by default.

This property has no use for most applications. It can be useful to external applications which need to control the Wrapper in a cross platform manner.

Be aware that the use of this property can pose a security risk as the Wrapper can be controlled simply by creating a text file. For this reason, make sure that the permissions on the directory containing the command file are set appropriately.

Example:

    wrapper.commandfile=./myapp.command

The interval at which the existence of the command file is tested can be controlled using the `wrapper.command.poll_interval` property. It defaults to 5 seconds, with valid values in the range of 1 to 3600 seconds.

| Using the command file

The Wrapper will attempt to obtain a read/write lock on the file when it opens it. Once opened, all commands will be executed in order and then the file will be closed and deleted.

External processes which create command files should always open the command file in append mode. This way if the file does not exist it will be created, but if it already exists then any new commands will be appended.

The Wrapper will try several times for up to a second to open the command file once it has been determined that it exists. This is done to avoid problems while another process is in the process of writing the file. If the file remains locked for longer than a second, a warning will appear in the log file. This will not affect the operation of the Wrapper, but to avoid the warnings, it is important that the file be locked as briefly as possible.

The file is formatted as a text file with a single command on each line. Possible commands include:

- `STOP [exitCode]` - Requests that the Wrapper shut down cleanly. The optional exitCode can be used to specify the exitCode when the Wrapper actually shuts down.
- `RESTART` - Requests that the Wrapper restart its JVM. This can be used in combination with the wrapper.restart.reload_configuration property to cause the Wrapper to reload its configuration and then launch a new JVM reflecting the changes.
- `PAUSE` - Requests that the Wrapper by paused. Only supported when run as a Windows service and the wrapper.ntservice.pausable property is true.
- `RESUME` - Requests that the Wrapper by resumed. Only supported when run as a Windows service and the wrapper.ntservice.pausable property is true.
- `DUMP` - Requests that the Wrapper cause the JVM to produce a thread dump. The results can be viewed in the Wrapper log file.
- `CONSOLE_LOGLEVEL {LEVEL}` - Changes the console loglevel of the Wrapper.
- `LOGFILE_LOGLEVEL {LEVEL}` - Changes the log file loglevel of the Wrapper.
- `SYSLOG_LOGLEVEL {LEVEL}` - Changes the syslog or Event Log loglevel of the Wrapper.

NOTE MEG |  | Reloading the Wrapper configuration will have no effect on the value of this property. Changes will not take effect until the Wrapper has been restarted.

by Leif Mortenson

Copyright ©1999-2004 by Tanuki Software. All Rights Reserved. | last modified: