Print

[dbwiddis]

I've had it on my personal to-do list for some time to set up the JPPF driver as a windows service, but hadn't gotten around to it, primarily because the documentation and existing config files are set up to support Tanuki Software's Java Service Wrapper.

The problem (for me) with this approach is that Tanuki does not offer a 64-bit "community" version of their Windows service wrapper.  I toyed around a bit with mixing java versions but gave up.

However, I'm happy to report that with less than 30 minutes of (mostly trivial) effort I easily got it running using Apache Commons Daemon (a.k.a. procrun).  The documentation is mostly useless on installation/setup, but a little bit of googling led me to the realization that"

• The easiest way to get 64-bit windows binaries is from an installation of Tomcat
• I already had Tomcat installed as part of my JIRA installation

I simply grabbed the "service.bat" file from my JIRA /bin directory, and tweaked a few things:

• I defined JRE_HOME to my jre8 installation
• I defined a JPPF_DRIVER_HOME to my driver's directory
• I changed SERVICE_NAME and DISPLAYNAME
• I set CLASSPATH referenced to %JPPF_DRIVER_HOME%\config and \lib\*
• I changed the //IS// arguments for Description, StartClass, StopClass and JvmOptions to org.jppf.server.DriverLauncher and the options from startDriver.bat

Then I just ran service.bat install ... and voila.  It's done.

My driver's running just fine as a service now, and even starts up on reboot, and I can start, stop, and restart it using the Windows "Services" program on the Start menu.

[lolo]

Thank you very much for this!

This is very interesting, not only because Tanuki doesn't provide an community edition of their x64 binaries for Windows, but also because JPPF has the same license as Apache commons-daemon. It will allows us to include the .exe(s) directly in the node and driver distros, instead of asking users to download them. This is something that I will include in the next JPPF version and I registered a feature request accordingly: JPPF-352 Alternative to drivers and nodes as Windows services using Apache commons daemon

For information, if it can still help, you can get the executables from there: http://www.apache.org/dist/commons/daemon/binaries/windows/

Sincerely,
-Laurent

[dbwiddis]

Thanks for that link.  Had I browsed the download pages enough to find them, they were accessible in the "other" page.  By the time I had read enough documentation to figure out what I was supposed to do with them, I realized they were already on my system (named tomcat7.exe and tomcat7w.exe, respectively).

While the above was a "quick hack" to get things working I want to eliminate any dependencies on my tomcat/JIRA install, so  I'll download the proper versions (possibly renaming the files so they are unique on the task manager), work on trimming down the script, and will upload my resulting script to that feature request for your information.

As a curiosity, the script currently sends arguments "start" and "stop" to the org.jppf.server.DriverLauncher.  I'm guessing these are completely ignored.  Would it be useful for that class to actually process those arguments in any way?

[lolo]

I'm guessing these are completely ignored.  Would it be useful for that class to actually process those arguments in any way?

Yes these arguments are ignored. The DriverLauncher class as the following puproses:
- launch the actual driver (JPPFDriver class) as a child process
- capture its exit code, then take action, i.e. exit or restart the driver, based on its value
- ensure that when the driver is killed then the launcher also terminates and vice-versa, to avoid lingering processes in the OS
- the DriverLauncher creates a ServerSocket on an arbitrary port which is provided to the JPPFDriver as a main() argument
- the JPPFDriver creates a socket connection to this ServerSocket, but none of them does anything with it. They simply capture the exception that is raised when the connection breaks, which happen whenever one of the two processes is terminated.

So basically, it's not designed as a Tomcat server, to answer a start or stop command this way. With JPPF, this is done with the JMX-based shutdown and restart features.

I hope this clarifies.

-Laurent

[dbwiddis]

Yep, all clear, and I've removed those arguments.

Can't figure out how to attach files to the feature request issue so I'll just post them here.

I renamed prunsrv.exe (the service runner) as JppfDriver.exe, and prunmgr.exe (the gui) as JppfDriverw.exe and placed them in a folder along with these two batch files:

• service.bat is what I use to initially install the service.  (Trimmed down and modified from the Tomcat/JIRA version.)  After install it's unneeded
• gui.bat starts up a gui allowing starting, stopping, pausing, and editing configuration of the service (basically changing most of the defaults from the service.bat install)

[lolo]

Thanks, I attached the file to the feature request.

Can't figure out how to attach files to the feature request issue so I'll just post them here.

Doesn't it work when you click on "More actions" then "Attach a file"?

[dbwiddis]

Doesn't it work when you click on "More actions" then "Attach a file"?

Tried that. Got the dialogue box and even added a comment.  But when I clicked "upload and attach" nothing happened. 

[dbwiddis]

Just as an update for anyone else searching for this later...

I also got nodes set up as services on a few machines using a similar approach as for my driver and installed with "service.bat install".  I also set up the Windows Task Scheduler to start up the gui using its batch file on user login.

The main obstacle for a node, compared to a driver, is controlling CPU usage.  My tasks tend to try to take all the available CPU, and while using "start /affinity" in the batch files was doing the trick when I manually started nodes, controlling affinity of a windows service is a bit more challenging.

While one can always use the Task Manager to set the affinity of a running process, I wanted an automated solution. After trying a few products, I found a great one called "Process Lasso".  The free version offers all the functionality I need, although it looks like it has some pretty powerful features for the paid version as well.

So at this point, my driver and nodes automatically start as services on reboot, and the taskbar icon for the gui to control them automatically appears.  And when I run taks on the node, they're constrained to the cores I've previously configured (and I can easily change that setup.) 

[lolo]

Hello,

Thanks again for sharing your findings.
I was thinking of another possible approach. I've been working for some time now on a .Net bridge for JPPF, which will be delivered in JPPF 5.0. It is based on the Jni4net project which, among many other capabilities, provides a .Net API to launch a JVM in the same process as the .Net executable. It just came to my mind that we could easily implement a service-friendly JVM launcher with built-in processor affinity capabilities, since programmatic setting of affintiy seems to be very easy with .Net.

What do you think? Would it be a viable alternative?

-Laurent

[dbwiddis]

I was thinking of another possible approach. I've been working for some time now on a .Net bridge for JPPF, which will be delivered in JPPF 5.0. It is based on the Jni4net project which, among many other capabilities, provides a .Net API to launch a JVM in the same process as the .Net executable.

Certainly!

When researching java and affinity I saw many references to JNI but didn't know how easy it would be and didn't dare file a feature request about it!

One small drawback of the approach I've used is that all processes using the same executable are now at the same affinity (so, e.g., my driver is on the same core(s) as my node).  I can workaround it with multiple copies of the jre in different directories, etc., but if I could simply change a setting in a config file, so much the better.

The bottom line is yes, I want the ability to control the affinity of a jppf node.  I'll leave the implementation to you!