Clustering JVM.

Question

Hi Guys,

I have a situation where I need to induce asynchronous behavior in a synchronous application.

To elaborate, there is a monolithic c++ application which synchronously produces pricing for complex derivative products. This c++ app comes with a java wrapper which my app uses to interact with it.

Current Design

My APP <------> Java Wrapper <---> C++ application

Since the calls from the java wrapper to the c++ are synchronous, I want to create a asynchronous behavior by having a cluster of these java wrappers.

I would have a "Master Wrapper" that would decide (either in a round robin fashion or based on some real time info from the cluster) which individual wrapper gets the request.

Future Design

                                    <---> Java Wrapper <---> C++ application
My APP <------> Java Master Wrapper <---> Java Wrapper <---> C++ application
                                    <---> Java Wrapper <---> C++ application

Do any of you guys have experience building something of this sort? Any advises, links to tutorials, bits of code etc would be most helpful.

Cheers

FYI, I briefly looked at terracotta and it seems like it what I need however it is not an option (not an approved product at my firm).

Answer 1

If the 'Java Master Wrapper' and 'My App' are in the same JVM, you could have the Java Master Wrapper deposit the pricing results in a shared data structure that the My APP threads consumed. If the My APP are distinct processes / JVMs, you could use JMS to distribute the results. ActiveMQ is one JMS provider.

Answer 2

It seems you're looking not for cluster, but for a pool.

If the wrapper is executable within the same JVM with the main thread, the task is simply to re-use any of available thread pool/worker implementations. You can even decompile the wrapper to see what classes its main() method actually calls, and try and reproduce it in your application. Did that for a CORBA app, worked OK.

If every wrapper has to be in the different JVM, the simplest way would be to allocate the thread pool (again), where each thread watching it's own instance of Process object, writing requests to the stdin, reading responses from stdout.

Of course, thread-per-connection is not the most efficient design, so when you made it work you may actually move to a model when a small pool of threads (or even one thread) watches over a larger pool of wrapper Process instances, using a Selector.