DO NOT modify any of these parameters unless you have read this property description.
Incorrect settings can cause the Wrapper to fail to operate as expected.
File which will be monitored for commands to be executed.
This property is not set by default.
This property has no use for most applications,
but it can be useful to external applications which need to control the Wrapper in a cross platform manner.
If this property is 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.
The file will be deleted at the completion of the commands.
Example:
wrapper.commandfile=./myapp.command
Security Risk:
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.
Using the command file
The Wrapper will attempt to obtain a read/write lock on the file
when the command file is opened.
Once it is opened, all commands will be executed in order
and then the file will be deleted at the completion of the commands.
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 newly,
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 message 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 be paused.
Only supported when run as a Windows Service and the
wrapper.pausable
property is TRUE.
RESUME -
Requests that the Wrapper be resumed.
Only supported when run as a Windows Service and the
wrapper.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.
CLOSE_SOCKET (ver. 3.5.0 or later) -
Causes the backend socket with the JVM to be immediately closed.
This is useful for testing the JVM's ability to reconnect with the Wrapper.
This command is disabled unless
wrapper.command.enable_tests is TRUE.
wrapper.commandfile.enable_tests
Compatibility :
3.5.0
Editions :
Platforms :
Some of the commands related to testing are disabled by default for security reasons.
Setting this property to TRUE will make it possible to use test commands.
The default value is "FALSE".
Example:
wrapper.commandfile.enable_tests=FALSE
wrapper.commandfile.poll_interval
Compatibility :
3.2.0
Editions :
Platforms :
The interval at which the existence of the command file is tested can be controlled using the
wrapper.command.poll_interval property.
The default value is "5 seconds", with valid values in the range of "1-3600 seconds".
Example:
wrapper.commandfile.poll_interval=5
User Comments
If you notice something that is incorrect, missing, or simply feel that some part of this page could be explained better, feel free to log in and add a comment. You will need to register before you can log on.
by Leif Mortenson (2007/07/27 11:55:38 JST from 220.247.100.22)
Please note that there is currently a problem in current versions where the Wrapper can not invoke a thread dump unless a console window exists for the service. This has been fixed for the upcoming 3.2.0 release.
To work around this in the current version you must either add a console with the wrapper.ntservice.console=true property or tell the wrapper to execute thread dumps if a shutdown failure occurs: wrapper.request_thread_dump_on_failed_jvm_exit=true
by Gary Hirschhorn (2007/07/06 11:11:06 JST from 63.207.38.2)
You may want to mention that the wrapper.commandfile path is relative to wrapper.exe, not wrapper.conf. I was initially confused, but eventually figured it out through trial and error.
