I am working with a multithreaded homegrown multi-module app in my new job. We use the the Thrift protocol to communicate RPC calls between different stand-alone applications in a distributed system. One of them listens on multiple ports and I just noticed that it actually makes an RPC call to itself from one thread invoked from one socket it listens to (web service call) to another port within the same app. I verified that it could accomplish the same thing if it just went and directly called the method that the remote procedure ultimately invokes as it is all within the same application, same JVM. To make it even more mysterious, the call is completely synchronous, i.e. no callbacks involved. The first thread totally sits and waits until it makes a call across the wire to itself and comes back.

Now, I am perplexed why anybody would do it this way. It seems like calling somebody on the phone that sits in the same room as you do. Can anybody provide an explanation why the developer before me would come up with the above mentioned model? Maybe there is a reason and I am missing something.

  • so it avoid shared-memory related threading problem?
    – Bryan Chen
    Oct 25, 2013 at 3:56

2 Answers 2


At a guess they thought that perhaps, someday, they might like to put that server into another process. And so, they used the RPC mechanism in preparation for a future that never came.


It is possible that the program that runs on that process was designed to be deployed to multiple nodes; in that case you have the same process on two nodes, and the process from node 1 calls the process of node 2 even though they run the same program.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.