-1

I have 2 java processes, Process1 is responsible for importing some external data to the database, Process2 is running the rest of the application using the same database, i.e. it hosts the web module the everything else. Process1 would normally import data once a day.

What I require is when Process1 has finished it's work it should notify the Process2 about it, so that it can perform some subsequent tasks. That is it, this will be their limit of interaction with each other. No other data has to be shared later.

No I know I can do this in one of the following ways:

  1. Have the Process1 write an entry in the database when it has finished its execution and have a demon thread in Process2 looking for that entry. Once this entry is read, complete the task in Process2. Even though this might be the easiest to implement in the existing ecosystem, I think having a thread loop the database just for one notification looks kind of ugly. However, it could be optimised by starting the thread only when the import job starts and killing it after the notification is received.

  2. Use a socket. I have never worked with sockets before, so this might be an interesting learning curve. But after my initial readings I am afraid it might be an overkill.

  3. Use RMI

I would like to hear from people who have worked on similar problems, and what approach they choose and why and also would like to know what will be an appropriate solution for my problem.

Edit. I went through this but found that for a starter in interprocess communication it lacks basic examples. That is what I am looking in this post.

Community
  • 1
  • 1
rd22
  • 1,032
  • 1
  • 18
  • 34
  • Possible duplicate of [How to have 2 JVMs talk to one another](http://stackoverflow.com/questions/10942427/how-to-have-2-jvms-talk-to-one-another) – AntonH Jan 05 '17 at 04:42
  • Or just do a Google search for "java inter-process communication". – AntonH Jan 05 '17 at 04:43
  • @AntonH I did the research, as you would have seen in the post. I would like to know what is more appropriate in a situation I face. And I already went through the link. – rd22 Jan 05 '17 at 04:53
  • I see little proof of research. You don't mention signals, semaphores, or message queues, which are very classical IPC techniques. Updating a field in a database would be a terrible idea, as that pretty much means that one process continually does database requests with very little result, until the field is changed at some unspecified time. At best, given that we have no knowledge of the environment these 2 processes are running on, we could give little true assistance, IMO. – AntonH Jan 05 '17 at 05:00
  • I read through them, but for reasons I did not consider them seriously. Now that I am, it looks something like JMS might be a solution. Thanks. – rd22 Jan 05 '17 at 05:24

1 Answers1

1

I would say take a look at Chronicle-Queue

It uses a memory mapped file and saves data off-heap (so no problem with GC). Also, Provides TCP replication for failover scenarios.

It scales pretty well and supports distributed processing when more than one machine is available.

Kishore Bandi
  • 5,537
  • 2
  • 31
  • 52