Solution with RMI?

[nullstring]

Does anybody has experience with Remote Method Invocation?
Does it run stable??

If I understood what right, the tcp-connection beneath is holded the
whole time!
Is that right?

In this case I just make a RMI-Object when I need it, otherwise I
delete the rmi-object from the heap of the client!
But!! Whats about the Distributed Garbage Collector, I heard about
problem with it!
(If I just make a RMI-Object when I need it and destroy it after that I
have many object, which should be deleted)

The software runs on a high-availability-server, so I should make any
mistakes



Thanks in advance
Nullstring

 

[JavaEnquirer]

Hi. I've never had any problems with RMI. It's always been robust and
performant. You needn't worry about garbage collection, just program as
if there were no network, no remote connection! ( I'm being a little
over simplistic here as all severs can go down and you may want to
report this fact to a user. )

If I understood what right, the tcp-connection beneath is holded the
whole time!
Is that right?

You can set timeouts if you want to connection to go down after a set
period. Otherwise, I believe the connection will be released upon
garbage collection - either the client JVM terminates or the remote
reference is nulled on the client. I have left an RMI connection alive
for days without use, and magically, I call a remote method and
everything continues as expected. I'm not sure oi the connection is
closed after lack of useage and then transparently revived without you
noticing.

A lot of people advocate other remoting technologies such as EJB,
Hessian, Spring Remoting etc. But, I've always found RMI the simplest
approach.

 

[nullstring]

Ok, sounds great!

With RMI I only can make one way, from the client to the server and not
the other way around, is that right?

I have datas in a db with are displayed on the clients! But I want the
clients automatically beeing updated! I would implement a simple
socketstream which is used as an controll-channel (like: "hey, i got
new datas, call your getdata()-method" )!
Or does RMI has techniques to do stuff like that?

Is it ok, to use 2-dimensinal Strings (for table-datas) as
parameters/returnvalue?


Thank you very much

Nullstring

 

[Thomas Fritsch]

Ok, sounds great!

With RMI I only can make one way, from the client to the server and not
the other way around, is that right?

No, you can use it both ways.
The way you know is: The client gets a remote object (i.e. an Object
implementing an interface extended from java.rmi.Remote) from the server
and calls some methods of that object.
The other way is: A client-side object implements a Remote interface and
calls a method (e.g. serverObject.addDatabaseListener(this)) of a
server-side remote object. The server-side object later calls back into
a client-side method (e.g. listener.eventOccured(event)) when some event
has occured.

I have datas in a db with are displayed on the clients! But I want the
clients automatically beeing updated! I would implement a simple
socketstream which is used as an controll-channel (like: "hey, i got
new datas, call your getdata()-method" )!
Or does RMI has techniques to do stuff like that?

Is it ok, to use 2-dimensinal Strings (for table-datas) as
parameters/returnvalue?

Yes, you use any object implementing the Serializable interface.

 

[EJP]

Does anybody has experience with Remote Method Invocation?
Yes

Does it run stable??

Yes although not 100% perfect.

If I understood what right, the tcp-connection beneath is holded the
whole time!

No. It is used, then put into a connection pool, where it times out
after 15 seconds if it isn't used again. You can control the timeout.

In this case I just make a RMI-Object when I need it, otherwise I
delete the rmi-object from the heap of the client!

The RMI object is in the heap of the server. I don't understand the
question.

But!! Whats about the Distributed Garbage Collector, I heard about
problem with it!

It can misfire (trigger prematurely) if there are routers in between the
server and the client which go up and down for minutes at a time. But
you can prevent DGC happening at all by holding static references to
your remote objects in the server JVMs.

(If I just make a RMI-Object when I need it and destroy it after that I
have many object, which should be deleted)

I don't know what you mean by RMI-Object if you're talking about
something in the client heap. If you mean a server in a server JVM, yes
you can create and destroy them as often as you like. I have seen a
production system with 50,000 remote objects.

If you have high-availability requirements I believe you should look at
RMI/IIOP, which is much the same thing but using a CORBA ORB as the
runtime system instead of the RMI runtime system.