1

I'm trying to use Java RMI for remotely polling a queue. Is RMI a good method to do this? Overall, what are the advantages of using RMI over regular socket programming? Is it more efficient in terms of network bandwidth usage?

Tina J
  • 4,983
  • 13
  • 59
  • 125
  • RMI is a compromise between simplicity (of use) over complexity of implementation. Do you want to spend the time doing all the low level socket work yourself (complexity) or do you want the simplicity of a solution which is already available and has been tested? – MadProgrammer Feb 04 '16 at 22:43
  • 1
    While I don't think SO is a good fit for this kind of question, queues and messaging are a solved problem, there are plenty of implementations out there ([this](https://github.com/OpenHFT/Chronicle-Queue) for example) and there is very little sense in writing your own implementation, other than as an exercise. – biziclop Feb 04 '16 at 22:52
  • 1
    There is one disadvantage of RMI not mentioned: it is very difficult to use it via anything not written in Java.. – biziclop Feb 04 '16 at 23:54
  • This question should not have been closed. It's a perfectly valid question - is RMI a good method for doing remote stuff or not? The answer is, it's really not good for anything for a lot of reasons, some of which you can find here https://stackoverflow.com/questions/14326901/the-significance-of-java-rmi-please. Please use anything but not RMI in 2017 :) – Bastian Voigt Nov 08 '17 at 22:56

3 Answers3

4

Is RMI a good method to do this?

It could be. RMI is pretty simple and supported by many frameworks.

Overall, what are the advantages of using RMI over regular socket programming?

Simplicity for a variety of uses.

Is it more efficient in terms of network bandwidth usage?

RMI is built on top of regular socket programming so it can't be any more efficient. However in term of network bandwidth it is as much as 2-5x worse than what you can achieve with custom code, except of course you need to use custom coding. You are sending large byte[] or String it won't make much difference.

Note: This is not a good reason to not use RMI. Using a faster alternative is unlikely to be justified unless you know this will be a problem and generally it isn't.

Note: if you use RPC using another serialization, it is most likely to be more efficient. i.e. almost all alternatives are more efficient.

Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
  • 1
    I agree with most of this, but the 10x factor might be accurate if you are passing or returning single bytes, but otherwise it's just unsubstantiated FUD. You can get a 43x explosion by inappropriate use of SSL too, but that's not a reason to avoid SSL. – user207421 Feb 04 '16 at 23:30
  • @EJP I am not saying your should avoid RMI and if you send large simple data types like Strings or byte[] then it doesn't make much difference. You are right that 10x is an exaggeration. 2-5x is more likely. Added your note that it's not a good reason to not use it. – Peter Lawrey Feb 05 '16 at 01:30
1

I'd say the most convenient advantage RMI offers is how simple it is to call a method on another machine and returning objects over network, letting the stub take care of the marshalling/unmarshalling. It is however certainly not more efficient than building your own low level communication layer over sockets, assuming you do it well :)

Your case might fit though, having the pollQueue() method on one machine which simply can return the object you store in your queue to the calling Java application.

bdvll
  • 86
  • 6
0

As always, the answer depends on the needs of your application and the time/budget you have to code it up. That said, I offer this opinion.

If you need synchronous remote procedure calls, you can't beat RMI in terms of simplicity. You stub out an interface and use it to make direct calls on objects on remote machines. It doesn't come without overhead however, as every procedure call gets run in a new thread on the remote machine in addition to blocking of the calling thread on the local machine until the procedure completes or fails. It can also introduce synchronization issues that are difficult to troubleshoot (chained RMI calls can lead to deadlock across multiple machines if you're not careful with thread safety on the objects you plan to serve up). Bandwidth won't be an issue if you understand how to use Serializable or Externalizable effectively.

However, if you need outright speed/performance or fine control of the data that is sent over the network, you're better off using Sockets and implementing your own callbacks. RMI is synchronous by nature, but with Sockets, you can do things in an asynchronous, event-driven manner. However with this approach, there will be a lot more coding overhead and it can become quite tedious if the number of remote procedures you need to implement becomes large.

CodeBlind
  • 4,519
  • 1
  • 24
  • 36