I'm creating a Java application that requires master-slave communication between JVMs, possibly residing on the same physical machine. There will be a "master" server running inside a JEE application server (i.e. JBoss) that will have "slave" clients connect to it and dynamically register itself for communication (that is the master will not know the IP addresses/ports of the slaves so cannot be configured in advance). The master server acts as a controller that will dole work out to the slaves and the slaves will periodically respond with notifications, so there would be bi-directional communication.

I was originally thinking of RPC-based systems where each side would be a server, but it could get complicated, so I'd prefer a mechanism where there's an open socket and they talk back and forth.

I'm looking for a communication mechanism that would be low-latency where the messages would be mostly primitive types, so no serious serialization is necessary. Here's what I've looked at:

• RMI
• JMS: Built-in to Java, the "slave" clients would connect to the existing ConnectionFactory in the application server.
• JAX-WS/RS: Both master and slave would be servers exposing an RPC interface for bi-directional communication.
• JGroups/Hazelcast: Use shared distributed data structures to facilitate communication.
• Memcached/MongoDB: Use these as "queues" to facilitate communication, though the clients would have to poll so there would be some latency.
• Thrift: This does seem to keep a persistent connection, but not sure how to integrate/embed a Thrift server into JBoss
• WebSocket/Raw Socket: This would work, but require a lot more custom code than I'd like.

Is there any technology I'm missing?

Edit: Also looked at:

• JMX: Have the client connect to JBoss' JMX server and receive JMX notifications for bidirectional comms.