In my scenario, I have a server running which waits for a client to make a connection. It is necessary for a client to instantiate the connection because the computer I’m looking to communicate with has more restrictive network security than I do. The client will connect to me daily. So I have a jar file and process running that handles this. Server side on my end, and client side on the other end. Next, I have a web page running, and when a user clicks a specific button, I need to tell the Server app, “okay, now send data to the client”.
What is the best way to accomplish this? First of all, is there a problem with the client waiting around for data? Do I need anything special here like heartbeats etc? Is it possible to reverse the scenario and have a server connect to a client instead?
Next, how can I make it so that the application I launch when the user clicks a button actually talks to an already running jar which is handling the connection?
What you need is decide the transport layer. If you use RMI -which makes sense if you use Java in all the endpoints of comunication- you don’t need the heatbeat or something.
I should define, in web-app context (are you using Spring?) a unique instance that initializes an RMI object and publishes it at RMI registry, so clients can connect to it.
As this object is created inside webapp process (and webapp classloader), it has access to some queue object you use. Then your webapp can add items to that queue.
Your RMI object should have to execute in a separate thread (don’t create indiscriminate threads in Java EE, just one! or use some framework as Quartz) and consume from the blocking queue.
If a client can stay a lot without reading a new item, and there are a LOT of clients, maybe it’s worth to return null from the queue where there are no items (or it timeouts).