RemoteApplications agent keeps the the jvm running until System.exit is called.

[fheineIDBS]

Steps to reproduce:

• Download remoteapplications-1.3.jar to a local directory (eg C:\RemoteServer_Test\lib)
• Set JAVA_TOOL_OPTIONS variable to point cause that jar to be loaded (eg SET JAVA_TOOL_OPTIONS=-javaagent:"C:\RemoteServer_Test\lib\remoteapplications-1.3.jar"="C:\RemoteServer_Test\lib")
• Execute Java in the same command window

Expected reult:

• Java prints command line help and exists

Actual result:

• Java prints expected command line help and hangs until terminated (Ctrl-c)

This is exactly how the remote applications library gets injected into Java applications, so the fact that it prevents Java processes from quitting as expected, causes applications to hang. This is particularly problematic if child Java processes get created by an application that don't have any GUI as they just sit there and never terminate.

Note: The way to work around this is to connect to the process using the Application Started keyword and then call Close Application. That will then free us the process.

[fheineIDBS]

Further investigation has revealed that this affects applications that rely on the fact that the JVM terminates when all threads terminate. Applications that explicitly call System.exit() terminate as expected. Presumably this is due to the fact that the SpringFramework creates another thread in the current application when it publishes the bean.

[fheineIDBS]

Closed in due to finger trouble...

[jussimalinen]

Hum, so probably the thread running the remote applications agent should be made a daemon thread... Perhaps fixing this could be as easy as calling setDaemon on correct thread.

[jussimalinen]

Okay, a quick try to fix this failed. As this is not an issue for our customers, I am not spending more time on this now.

As a workaround, you can call "close application" from your test material.

This will have to wait until I have more free time on my hands to debug this or someone provides a patch.

[fheineIDBS]

Thanks for that.

Close application is what I have been using. I will wait for you to wrap up the new version and maybe resume my efforts at finding a patch using that. Did you find the thread that keeps the application from shutting down?

Regards Florian

From: Jussi Malinen [mailto:notifications@github.com] Sent: 12 March 2013 13:49 To: robotframework/RemoteApplications Cc: Florian Heine Subject: Re: [RemoteApplications] RemoteApplications JAR makes JAVA hang on Windows (#8)

Okay, a quick try to fix this failed. As this is not an issue for our customers, I am not spending more time on this now.

As a workaround, you can call "close application" from your test material.

This will have to wait until I have more free time on my hands to debug this or someone provides a patch.

— Reply to this email directly or view it on GitHubhttps://github.com/robotframework/RemoteApplications/issues/8#issuecomment-14775790.

---

The information contained in this email may contain confidential or legally privileged information. If you are not the intended recipient any disclosure, copying, distribution or taking any action on the contents of this information may be unlawful. If you have received this email in error, please delete it from your system and notify us immediately. Any views expressed in this message are those of the individual sender, except where the message states otherwise. IDBS takes no responsibility for any computer virus which might be transferred by way of this email and recommends that you subject any incoming E-mail to your own virus checking procedures. We may monitor all E-mail communication through our networks. If you contact us by E-mail, we may store your name and address to facilitate communication.

[jussimalinen]

No, I did not isolate the thread, or if that indeed is the reason. (But I still think that is the most likely cause.)

[Tattoo]

We encountered this issue, so it is now affecting our customers.

[jussimalinen]

Okay, so the non daemonic thread is Rmi Reaper. This is a known issue it seems. When there are services still exported to RMI runtime, the Reaper will keep on running. http://blakboard.wordpress.com/2011/02/22/effects-of-java-rmi-on-jvm-shutdown/

It seems we would need to shutdown the RMI service, but how do we know when to shut it down? Another thread polling if other non daemonic threads besides Reaper and garbage collectors etc are dead?

I dont really know if we can solve this without going into very dirty hacks.

[jussimalinen]

Calling destroy() on the org.springframework.remoting.rmi.RmiServiceExporter that exports the robotrmiservice destroys the service and allows the jvm to exit.

To do that we would have to create a another thread to poll when other non deamonic threads besides RmiReaper have died. This ugly and nasty.

[fheineIDBS]

One of the ideas I had was to create an external rmi registry whose lifecycle can be managed by the library explicitly. I had a quick go at using the command line to launch the registry and get the remote library to connect to it, but I couldn't get it to work in the short timeframe that I had available to try it.

I don't know enough about Java RMI to be able to gauge if this seems like a good solution but it seems possible.

Another, possibly prohibitively expensive, solution might be to convert the interface from Java RMI to a robot framework remote server. In our environment, I have wrapped the remote library into a remote server anyway as I need to run the robot tests to run in CPython.

[jussimalinen]

I dont know enough about rmi to really say if external rmi registry would work. To be honest, I dont like the current setup, too many problems, too many layers of indirection, and too many components/frameworks I am not proficient enough with.

Converting RemoteApplications to use Remote server is a very tempting idea. I was already thinking of giving it a try. (As a separate project though.) That would simplify the code considerably and as a bonus would allow executing the tests from python.

[fheineIDBS]

Just had a quick go at implementing the jrobotremoteserver in a premain and that works but as Jetty is running as a non-daemon thread this has the same problem with not shutting down. A quick trawl of the web for an XML-RPC server that is capable of running in a daemon thread hasn't turned up anything so far.

[fheineIDBS]

Have done some more work on this. I tried implementing a library with a python front-end that uses PY4J to make calls to an injected gateway. This seems to work reasonably well, but I am having problems with some of our applications that seem to be caused by some of the things PY4J does to the classpath.

I am now getting to the point where the most sensible thing seems to be, to implement a simple remote server that can be injected directly. That way the impact on the Java environment of the running application can be tightly controlled. As all the XML-RPC server libraries I can find are built for significant loads with extensive dependencies and non-daemon threads, the only way I can see is by just implementing a basic XML-RPC server from scratch.

Let me know if you have any better ideas.