Which options do I have for Java process communication?

We have a place in a code of such form:

void processParam(Object param)
{
   wrapperForComplexNativeObject result = jniCallWhichMayCrash(param);
   processResult(result);
}

processParam - method which is called with many different arguments.

jniCallWhichMayCrash - a native method which is intended to do some complex processing of it's parameter and to create some complex object. It can crash in some cases.

wrapperForComplexNativeObject - wrapper type generated by SWIG

processResult - a method written in pure Java which processes it's parameter by creation of several kinds (by the kinds I'm not meaning classes, maybe some like hierarchies) of objects:

1 - Some non-unique objects which are referencing each other (from the same hierarchy), these objects can have duplicates created from the invocations of processParam() method with different parameter values. Since it's costly to keep all the duplicates it's necessary to cache them.

2 - Some unique objects which are referencing each other (from the same hierarchy) and some of the objects of 1st kind.

After processParam is executed for each of the arguments from some set the data created in processResult will be processed together. The problem is in fact that jniCallWhichMayCrash method may crash the entire JVM and this will be very bad. The reason of crash may be such that it can happen for one argument value and not for the other. We've decided that it's better to ignore crashes inside of JVM and just skip some chunks of data when such crashes occur. In order to do this we should run processParam function inside of separate process and pass the result somehow (HOW? HOW?! This is a question) to the main process and in case of any crashes we will only lose some part of data (It's ok) without lose of everything else. So for now the main problem is implementation of transport between different processes. Which options do I have? I can think about serialization and transmitting of bina开发者_JS百科ry data by the streams, but serialization may be not very fast due to object complexity. Maybe I have some other options of implementing this?

Let us assume that the processes are on the same machine. Your options include:

• Use a Process.exec() to launch a new process for each request, passing the parameter object as a command line argument or via the processes standard input and reading the result from thr processes standard output. The process exits on completion of a single request.

• Use a Process.exec() to launch a long running process, using the Processes standard input / output for sending the requests and replies. The process instance handles multiple requests.

• Use a "named pipe" to send requests / replies to an existing local (or possibly remote) process.

• Use raw TCP/IP Sockets or Unix Domain Sockets to send requests / replies to an existing local (or possibly remote) process.

For each of the above, you will need to design your own request formats and deal with parameter / result encoding and decoding on both sides.

• Implement the process as a web service and use JSON or XML (or something else) to encode the parameters and results. Depending on your chosen encoding scheme, there will be existing libraries deal with encoding / decoding and (possibly) mapping to Java types.

• SOAP / WSDL - with these, you typically design the application protocol at a higher level of abstraction, and the framework libraries take care of encoding / decoding, dispatching requests and so on.

• CORBA or an equivalent like ICE. These options are like SOAP / WSDL, but using more efficient wire representations, etc.

• Message queuing systems like MQ-series.

Note that the last four are normally used in systems where the client and server are on separate machines, but they work just as well (and maybe faster) when client and server are colocated.

I should perhaps add that an alternative approach is to get rid of the problematic JNI code. Either replace it with pure Java code, or run it as an external command or service without a Java wrapper around it.

Have you though about using web-inspired methods ? in your case, typically, web-services could/would be a solution in all its diversity :

• REST invocation
• WSDL and all the heavy-weight mechanism
• Even XML-RPC over http, like the one used by Spring remoting or JSPF net export could inspire you

If you can isolate the responsibilities of the process, ie P1 is a producer of data and P2 is a consumer, the most robust answer is to use a file to communicate your data. There is overhead (read CPU cycles) involved in serailization/deserialization however your process(es) will not crash and it is very easy to debug/synchronize.