Communication between local JVMs

Question

My question: What approach could/should I take to communicate between two or more JVM instances that are running locally?

Some description of the problem:
I am developing a system for a project that requires separate JVM instances to isolate certain tasks from each other entirely.

In it's running, the 'parent' JVM will create 'child' JVMs that it will expect to execute and then return results to it (in the format of relatively simple POJO classes, or perhaps structured XML data). These results should not be transferred using the SysErr/SysOut/SysIn pipes as the child may already use these as part of its running.

If a child JVM does not respond with results within a certain time, the parent JVM should be able to signal to the child to cease processing, or to kill the child process. Otherwise, the child JVM should exit normally at the end of completing its task.

Research so far:
I am aware there are a number of technologies that may be of use e.g....

• Using Java's RMI library
• Using sockets to transfer objects
• Using distribution libraries such as Cajo, Hessian

...but am interested in hearing what approaches others may consider before pursuing one of these options, or any others.

Thanks for any help or advice on this!

Edits:
Quantity of data to transfer- relatively small, it will mostly be just a handful of POJOs containing strings that will represent the result of the child executing. If any solution would be inefficient on larger amounts of information, this is unlikely to be a problem in my system. The amount being transferred should be pretty static and so this does not have to be scalable.

Latency of transfer- not a critical concern in this case, although if any 'polling' of results is needed this should be able to be fairly frequent without significant overheads, so I can maintain a responsive GUI on top of this at a later time (e.g. progress bar)

Answer 1

Not directly an answer to your question, but a suggestion of an alternative. Have you considered OSGI?

It lets you run java projects in complete isolation from each other, within the SAME jvm. The beauty of it is that communication between projects is very easy with services (see Core Specifications PDF page 123). This way there is not "serialization" of any sort being done as the data and calls are all in the same jvm.

Furthermore all your requirements of quality of service (response time etc...) go away - you only have to worry about whether the service is UP or DOWN at the time you want to use it. And for that you have a really nice specification that does that for you called Declarative Services (See Enterprise Spec PDF page 141)

Sorry for the off-topic answer, but I thought some other people might consider this as an alternative.

Update

To answer your question about security, I have never considered such a scenario. I don't believe there is a way to enforce "memory" usage within OSGI.

However there is a way of communicating outside of JVM between different OSGI runtimes. It is called Remote Services (see Enterprise Spec PDF, page 7). They also have nice discussion there of the factors to take into consideration when doing something like that (see 13.1 Fallacies).

Folks at Apache Felix (implementation of OSGI) I think have implementation of this with iPOJO, called Distributed Services with iPOJO (their wrapper to make using services easier). I've never used this - so ignore me if I am wrong.

Answer 2

I'd use KryoNet with local sockets since it specialises heavily in serialisation and is quite lightweight (you also get Remote Method Invocation! I'm using it right now), but disable the socket disconnection timeout.

RMI basically works on the principle that you have a remote type and that the remote type implements an interface. This interface is shared. On your local machine, you bind the interface via the RMI library to code 'injected' in-memory from the RMI library, the result being that you have something that satisfies the interface but is able to communicate with the remote object.

Answer 3

akka is another option, as well as other java actor frameworks, it provides communication and other goodies derived from the actor model.