Best practice for Java IPC

Question

what is the best method for inter process communication in a multithreaded java app.

It should be performant (so no JMS please) easy to implement and reliable,so that objects & data can be bound to one thread only?

Any ideas welcome!

• WhyNotHugo: IPC is "Inter-process communication".
• rdalmeida: IPC usually means across different JVMs. This is usually done through shared memory and memory-mapped files. Check the open-source CoralRing project for the full details. This is not trivial to get it right as you need to step out of the JVM through sun.misc.Unsafe.

Answer 1

Could you clarify a bit? Do you mean IPC in a single JVM? (Multiple threads, yes, but at an OS-level only one process.) Or do you mean multiple JVMs? (And truly OS-level inter process communications.)

If it is the first, then maybe something out of java.util.concurrent, like ConcurrentLinkedQueue would do the trick. (I pass message around inbetween my threads with classes from java.util.concurrent with success.)

If the later, then I'm going to just guess and suggest taking a look at RMI , although I don' think it qualifies as fully reliable--you'd have to manage that a bit more 'hands on' like.

• trshiv: RMI is by far the best way for IPC between different JVMs.
• gpampara: That's not always true. RMI might be simple, but it does require that the interface from which stubs are generated remain static, without changes. The choice of IPC depends on the needs of the application. A message passing IPC mechanism might be better in some use cases.
• WhyNotHugo: IPC is "Inter-process communication", The classes in java.util.concurrent are designed for several threads of a single process, not different processes.
• Stu Thompson: @Hugo: Thanks for the -1. Don't get so hung up on labeling things threads or processes. Once you abstract it all a bit, threads and processes are the same logically; the same issues must be dealt with. In the end it is just an implementation question. Hence the dual nature of my answer.

Answer 2

Assuming the scenario 1 JVM, multiple threads then indeed java.util.concurrent is the place to look, specifically the various Queue implementations. However an abstraction on top of that may be nice and there Jetlang looks very interesting, lightweight Java message passing.

Answer 3

I've just added MappedBus on github (http://github.com/caplogic/mappedbus) which is an efficient IPC library that enable several Java processes/JVMs to communicate by exchaning messages and it uses a memory mapped file for the transport. The troughput has been measured to 40 million messages/s.

Answer 4

I recommend looking into the entire java.util.concurrent package, which have multiple classes for dealing with concurrency and different communication means between threads. All depends on what you want to achieve, as your question is pretty general.

Answer 5

You should use a producer/consumer queue. By doing that you avoid the pitfalls of multithreaded programming: race-conditions and deadlocks. Plus it is not just easier and cleaner, but also much faster if you use a lock-free queue like Disruptor or MentaQueue. I wrote a blog article where I talk about this in detail and show how to get < 100 nanoseconds latencies: Inter-thread communication with 2-digit nanosecond latency.

• Dmitry Shevkoplyas: your link require basic auth.