|
If you were logged in you would be able to see more operations.
|
|
|
|
Forking a service bean currently results in the creation of 4 processes:
1. Call to the rio script to start the service
2. The invocation of the jvm
3. Monitoring shell (generated) that polls the status of the forked service
4. Sleep command in the monitoring shell
With this approach, the number of processes required is an unnecessary drain on system resources. This needs to be optimized.
|
|
Description
|
Forking a service bean currently results in the creation of 4 processes:
1. Call to the rio script to start the service
2. The invocation of the jvm
3. Monitoring shell (generated) that polls the status of the forked service
4. Sleep command in the monitoring shell
With this approach, the number of processes required is an unnecessary drain on system resources. This needs to be optimized. |
Show » |
|
Improvement
Closed
Major
Optimize service bean fork approach, reduce resources required to activate and monitor forked services
Construct the command line for the invocation of the JVM, including setting the classpath and JVM options, generate a shell script containing that command line. The generated script uses exec, which replaces the script execution with that of the execution of the JVM. This is used instead of calling the rio script to start the JVM. While not a huge optimization it effectively reduces the process count by 1.
The JMXFaultDetectionHandler is used to monitor the availability of the forked service, instead of the generation and execution of a process monitoring script with sleep invocations. This approach utilizes the existing Rio framework and further reduces the process count by 2.
Other optimizations were added, and currently only available under Java 6. Part of the generation of script files involves making sure the generated files have execute permissions. If executing on Java 5, the chmod +x <script-file> is forked, spawninig another process. With Java 6, java.io.File has added methods providing the ability to invoke setExecutable() on the FIle object itself, instead of calling system commands to make that happen.