Professional Documents
Culture Documents
Location: http://www.jguru.com/faq/RMI
Ownership: http://www.jguru.com/misc/user-agree.jsp#ownership.
Why must the CLASSPATH environment variable not include the path of the
remote object's stub classes on the server host?
Location: http://www.jguru.com/faq/view.jsp?EID=959
Created: Nov 13, 1999
Author: Govind Seshadri (http://www.jguru.com/guru/viewbio.jsp?EID=14)
If the CLASSPATH environment variable on the server host includes the path of the
remote object's stub classes, it will cause rmiregistry to ignore the
java.rmi.server.codebase property setting for the server.
rmiregistry must contain the location of the stub files for the remote server object in
an HTTP URL-encoded format, so that when this information is sent to the client, the
classes can then be downloaded via an HTTP server.
If rmiregistry does not send the location of the stub classes in HTTP-encoded format,
the client having no way to download them, will simply throw a
ClassNotFoundException.
java.rmi.server.codebase, CLASSPATH
Author: Federica Ciotti (http://www.jguru.com/guru/viewbio.jsp?EID=1176012), Jun
3, 2004
How can I tell rmiregistry to contain the location of the stub class in the HTTP URL encoded format?
I try to do
In most real-life RMI deployment scenarios, the client retrieves all the classes
dynamically via the HTTP protocol, by interacting with an web server running on the
same host as the remote server objects.
You can also make use of a simple HTTP "class server" implementation provided free
by Sun, exclusively for use with RMI. The class-server can be downloaded at:
ftp://ftp.javasoft.com/pub/jdk1.1/rmi/class-server.zip
You can start rmiregistry or RMI servers from a DOS window under Win32 using the
start command. But this does not run your servers truly in the background, as a little
DOS window for the java interpreter remains in the foreground for each server that
is started. If you are starting numerous remote servers under Win32, all the DOS
windows could prove rather problematic.
A solution is to use the javaw command that is supplied as part of the Windows
JDK/SDK. This fires up the Java interpreter as a seperate process and runs your RMI
server in the background. This effectively eliminates the clutter of DOS windows in
the foreground for each of your RMI servers.
Do note that there are some downsides to using javaw. For instance, it is no longer
that simple to terminate a running Java process - you now have to do it via the task
manager. Also, if you are in debugging mode, you will not be able to see any of the
diagnostic messages sent to the console, as it is now in the background.
Java Rmi
Author: Amit jain (http://www.jguru.com/guru/viewbio.jsp?EID=425018), Apr 9,
2002
There is no nees to use the start service of windows to start Rmiregistry just write the
below code before rebind methord for ur remote object like as below :- Registry
registry =LocateRegistry.createRegistry(1099); SaveImageInterface server=new
SaveImageServer(); registry.rebind("//localhost/remoteserver",server);
Naming.rebind("//localhost/remoteserver); this code will register the object on the
host which is running the servre and for making the server as background user javaw
[name of the server ]
Re: Java Rmi
Author: kumar padhu (http://www.jguru.com/guru/viewbio.jsp?EID=1089663),
Jun 3, 2003
can you run only the rmiregistry in a seperate server and keep it alive
Can I run an RMI application that makes use of callbacks across firewalls?
Location: http://www.jguru.com/faq/view.jsp?EID=997
Created: Nov 14, 1999
Author: Govind Seshadri (http://www.jguru.com/guru/viewbio.jsp?EID=14)
No, you cannot use RMI applications that make use of callbacks across firewalls. The
RMI transport layer makes use of HTTP tunneling to get through firewalls. Since HTTP
is a stateless protocol, it does not offer a suitable transport layer for the callback
mechanism.
Comments and alternative answers
I'm facing the Same problem (CallBack Socket) and I'd like to check the solution
your proposed. The link does not seem to work. Can you please make it available
or just give instruction about how you made it?
I have an experimental solution if you would like to try it. It uses socket factories to
negotiate socket creation. Sockets are always initiated from the client. Let me know if
you find it useful or find bugs in it.
Re: You can try my free solution if you want to. It...
Author: Surendra Rathi (http://www.jguru.com/guru/viewbio.jsp?EID=587439),
Dec 17, 2001
can u post your free solution ??
Re[2]: You can try my free solution if you want to. It...
Author: Surendra Rathi
(http://www.jguru.com/guru/viewbio.jsp?EID=587439), Dec 17, 2001
I saw the solution. But can u post some documentation on how it works.
Re[3]: You can try my free solution if you want to. It...
Author: Tim Taylor (http://www.jguru.com/guru/viewbio.jsp?EID=238921),
Dec 18, 2001
When your client starts up, it creates a special socket connection to the
server. When the server needs to connect to the client, it sends a request
over the special socket, asking the client to make a connection to the server.
The server waits for the connection to come from the client and uses that
socket for the callback. I.e., all socket connections (call and callback both)
are made from the client to the server.
Generally, I think callbacks should be avoided, but if you need them and
know that you don't need HTTP tunnelling, my hack can help. There was
some speculation in the excellent book titled "java.rmi" that the callback
issue and HTTP tunnelling might be solved in Java 1.4 either for JRMP or
IIOP or both.
Re[4]: You can try my free solution if you want to. It...
Author: Surendra Rathi
(http://www.jguru.com/guru/viewbio.jsp?EID=587439), Dec 18, 2001
thanks for the response.
1) The server knows the VPN assigned ip address of the client and can
give it to the remote client ? Is there any way i can make the client
register its callback object with this 'vpn' address.
2) I have gone thru ur solution code (most of it). What i dont understand
is should i use it both at the client and the server side ? (eg the call to
RMISocketFactory.setSocketFactory()). Can i just use it only on client so
that it makes the callback register with the right address on the server. I
surely dont understand the rmisocket factory all that much.
I would have avoided the rmi callbacks if there was another way of
pushing updates to the client instead of client polling endlessly.
thanks in advance
suren
Re[5]: You can try my free solution if you want to. It...
Author: Tim Taylor
(http://www.jguru.com/guru/viewbio.jsp?EID=238921), Dec 19,
2001
If you are using a VPN, my solution should work transparently. I.e.,
you don't need to do anything except install the client and server
socket factories and establish the signalling socket as shown in the
example. After that, the socket factories on the client and server side
will negotiate the callback connections. Just code your callbacks as
normal, and they should just work.
Tim
Re: You can try my free solution if you want to. It...
Author: Paloma Ortega (http://www.jguru.com/guru/viewbio.jsp?EID=926756),
Jun 25, 2002
I have been trying to access your solution but I can´t get to it. Is there any other
way to download it? I have a server behind a firewall and a client accessing its
interface methods through RMI. There is also a callback interface for the server to
access the client once it has registered and there is no problem when the client is
connected to a LAN (we are using SocketFactory), but if the client is connected
through GPRS, we get the exception
Re[2]: You can try my free solution if you want to. It...
Author: Tim Taylor (http://www.jguru.com/guru/viewbio.jsp?EID=238921),
Jul 4, 2002
Anonymous FTP wasn't working at my site. It's back now. The solution should
work for you over GPRS if you can get a true socket connection to your server
from the client. You are getting the ConnectException on the server because it
is trying to connect back to the client. With my solution, the server will instead
send a request to the client and ask the client to create the socket back to the
server.
Re[3]: You can try my free solution if you want to. It...
Author: Paloma Ortega (http://www.jguru.com/guru/viewbio.jsp?EID=926756), Oct 15,
2002
Hello, We have successfully used this solution in order to get through a firewall for
callback requests. However, if the client application finishes, we obtain an exception in
the server side saying: java.net.SocketException: Connection reset by peer: JVM_recv in
socket input stream read at java.net.SocketInputStream.socketRead0(Native Method) at
java.net.SocketInputStream.read(SocketInputStream.java:116) at
java.io.BufferedInputStream.fill(BufferedInputStream.java:183) at
java.io.BufferedInputStream.read(BufferedInputStream.java:201) at
java.io.DataInputStream.readInt(DataInputStream.java:392) at
com.css.rmi.ServerTwoWaySocketFactory$1.run(ServerTwoWaySocketFactory.java:65)
When using only RMI and no socket factories at all, this exception is not thrown. We
have been thinking about closing the sockets used for the communication, is it possible
to use the solution for this? is there any other way we haven´t thought of? Thank you,
Paloma
Re: You can try my free solution if you want to. It...
Author: jia wei (http://www.jguru.com/guru/viewbio.jsp?EID=1042437), Jan 2,
2003
Hi Tim, I am encountering RMI callback through firewall problem in my java
application. I tried to access your solution, but it was not successful. Could you
post or show me your solution? Thanks in advance. Jenny
Re[2]: You can try my free solution if you want to. It...
Author: sudipta tripathy
(http://www.jguru.com/guru/viewbio.jsp?EID=1085174), May 15, 2003
I want download your rmi free solutions.Could send me the link ? Thanks
Sudipta
Re[3]: You can try my free solution if you want to. It...
Author: Jeff Shao (http://www.jguru.com/guru/viewbio.jsp?EID=1087400),
May 23, 2003
Tim, Can you share the link for your solution? I don't have a clue how other
folks were able to see your solution. Thanks, Jeff
How can I control the lease period associated with a client's reference for
my remote object?
Location: http://www.jguru.com/faq/view.jsp?EID=1001
Created: Nov 14, 1999
Author: Govind Seshadri (http://www.jguru.com/guru/viewbio.jsp?EID=14)
When a RMI client obtains a reference for the remote object, by default, the
reference is live for 10 minutes. If there is no client activity before the lease term
expires, the reference is considered to be invalid, and the remote object may be
subject to garbage collection, presuming there are no other clients holding a live
reference to it.
However, the lease term can be easily changed, and is controlled by the system
property java.rmi.dgc.leaseValue.
For example:
resets the lease term to 5 minutes. The lease period is indicated in milliseconds.
Note that for optimal performance, the lease term should not be set toa very small
value. An active RMI client automatically renews the lease when it is halfway expired,
and a very small lease term would cause the client to consume precious network
resources in repeatedly renewing the lease.
Can my remote object obtain notification when there are no live references
to it?
Location: http://www.jguru.com/faq/view.jsp?EID=1002
Created: Nov 14, 1999
Author: Govind Seshadri (http://www.jguru.com/guru/viewbio.jsp?EID=14)
Yes, you can enable remote objects to get notified as soon as there are no valid
references to it. Although the distributed garbage collection mechanism takes care of
memory management issues, explicit notification can help the remote server release
valuable resources like network and database connections immediately.
public RemoteServerImpl() {
super();
. . .
//allocate resources
}
. . .
public void unreferenced() {
//deallocate resources here
}
}
Comments and alternative answers
The RMI Specification document says: "As long as some client holds a remote
reference to the remote object, the RMI runtime keeps a local reference to the remote
object. When the "reference" set becomes empty, the Unreferenced.unreferenced
method is invoked (if the server implements the Unreferenced interface)."
But the following example shows that the meaning one would ordinarily give to these
statements in the RMI specification document is not valid.
import java.rmi.*;
import java.rmi.*;
import java.rmi.server.*;
import java.net.*;
import java.rmi.*;
import java.rmi.server.*;
import java.rmi.registry.*;
import java.rmi.*;
JJ
Re: There's got to be a better way
Author: Raul Guiu (http://www.jguru.com/guru/viewbio.jsp?EID=878594), May
14, 2002
You can try to add the system property:
-Dsun.rmi.dgc.checkInterval=1000
Basically, DGC works by having the remote server keep track of all external client
references to it at any given time. When a client obtains a remote reference, it is
addded to the remote object's referenced set. The DGC then marks the remote
object as dirty and increases its reference count by one. When a client drops a
reference, the DGC decreases its reference count by one, and marks the object as
clean. When the reference count reaches zero, the remote object is free of any live
client references. It is then placed on the weak reference list and subject to periodic
garbage collection.
Where can I find a detailed comparison between RMI, DCOM and CORBA?
Location: http://www.jguru.com/faq/view.jsp?EID=1006
Created: Nov 14, 1999 Modified: 2000-05-29 11:25:34.963
Author: Govind Seshadri (http://www.jguru.com/guru/viewbio.jsp?EID=14)
Suresh Gopalan Raj has written a detailed article comparing the three technologies.
The article can be found in his "Web Cornucopia" site, at:
http://www.execpc.com/~gopalan/misc/compare.html
Is there a way I can disable my RMI client from using HTTP tunneling to get
through firewalls?
Location: http://www.jguru.com/faq/view.jsp?EID=1011
Created: Nov 14, 1999
Author: Govind Seshadri (http://www.jguru.com/guru/viewbio.jsp?EID=14)
Yes. Although HTTP tunneling is automatically used by the RMI transport layer to get
across firewalls, you can choose to disable this feature by setting the following
property at the client:
java.rmi.server.disableHttp=true
What's the cleanest way to have a client terminate a RMI server that is no
longer needed?
Location: http://www.jguru.com/faq/view.jsp?EID=1013
Created: Nov 15, 1999
Author: Govind Seshadri (http://www.jguru.com/guru/viewbio.jsp?EID=14)
The cleanest way to exit is to convert your remote object into an activatable remote
object and then a client can invoke the Activatable.unexportObject() method to get
rid of it.
Things are a little more complicated if you do not have an activatable remote object.
It is very important that your server does not exit before the client's request has
been fully processed, as otherwise an UnmarshallException is thrown.
One approach is to define an "exit handler thread" as an inner class, and instantiate
it within the remote object's constructor. The exit handler can then loop in the
background, waiting for an "exit" flag to be set by the client via an RMI call. As soon
as the flag is set, the exit handler can then wait for a couple of seconds such that the
client call is completely processed, and then call System.exit() to terminate the
server.
Is it true that my RMI applet can make socket connections only to the host
from which the applet was downloaded from?
Location: http://www.jguru.com/faq/view.jsp?EID=1031
Created: Nov 15, 1999 Modified: 2001-07-07 20:58:56.171
Author: Govind Seshadri (http://www.jguru.com/guru/viewbio.jsp?EID=14)
Yes, the default behaviour for applets (including those that may be RMI clients) is to
communicate with an RMI server that is hosted on the same platform from which the
applet was served from.
It is one of the manifestations of the applet sandbox paradigm, and can be overcome
by deploying "signed applets" which can go beyond the sandbox.
Yes, Sun has a servlet implementation of the call forwarding script for performing
HTTP tunneling. You can download it from:
http://java.sun.com/products/jdk/1.2/docs/guide/rmi/faq.html#servlet
The exception means that there is already an rmiregistry process running on the
default port 1099 on that machine. You can either choose to kill it and restart
rmiregistry, or start it up on a different port , say port 9999, as:
rmiregistry 9999
Why is that my remote objects can bind themselves only with a rmiregistry
running on the same host?
Location: http://www.jguru.com/faq/view.jsp?EID=1035
Created: Nov 15, 1999
Author: Govind Seshadri (http://www.jguru.com/guru/viewbio.jsp?EID=14)
Although an RMI application can perform a lookup on any host, it can bind, rebind or
unbind remote object references only with a registry running on the same host.
This is mainly for security reasons, as this restriction prevents a remote client from
deleting or overwriting entries from a server's registry.
• Closed: All classes used by clients and the server must be located on the JRE
and referenced by the CLASSPATH environment variable. No dynamic class
loading is supported.
• Server based: A client applet is loaded from the server's CODEBASE along
with all supporting classes. This is similar to the way applets are loaded from
the same HTTP server that supports the applet's web page.
• Client dynamic: The primary classes are loaded by referencing the
CLASSPATH environment variable of the JRE for the client. Supporting classes
are loaded by java.rmi.server.RMIClassLoader from an HTTP or FTP server on
the network at a location specified by the server.
• Server dynamic: The primary classes are loaded by referencing the
CLASSPATH environment variable of the JRE for the server. Supporting classes
are loaded by the java.rmi.server.RMIClassLoader from an HTTP or FTP server
on the network at a location specified by the client.
• Bootstrap client: In this configuration, all of the client code is loaded from
an HTTP or FTP server across the network. The only code residing on the
client machine is a small bootstrap loader.
• Bootstrap server: In this configuration, all of the server code is loaded from
an HTTP or FTP server located on the network. The only code residing on the
server machine is a small bootstrap loader.
When RMI sends the object via serialization RMI embeds the URL specified by this
parameter into the stream, alongside of the actual object.
It is important to note that RMI does not send class files along with the serialized
objects.
If the remote JRE needs to load a class file for an object, it looks for the embedded
URL and contacts the server at that location for the file.
When the property java.rmi.server.useCodebaseOnly is set to true, then the JRE will
load classes only from either a location specified by the CLASSPATH environment
variable or the URL specified in the java.rmi.server.codebase property. This is an
easy way of imposing additional security to the behaviour of RMIClassLoader.
Comments and alternative answers
Java 2 SDK adds significant enhancements to the RMI implementation found within
JDK 1.1. The most important changes are:
• Under JDK 1.1, RMI servers have to be up and running all the time, and could
not be started 'on demand'. Java 2 adds Remote Object Activation framework
to RMI. It is now possible to instantiate server objects "on the fly," making it
possible to build even more scalable distributed object networks.
• Java 2 allows you to implement Custom Socket Types making it simpler to
incorporate SSL encryption, data compression and so forth at the transport
level. With JDK 1.1, the RMI socket factory could use only one custom socket
type per JVM. You also had to use a different rmiregistry for each custom
socket implemented by an RMI server. Now, all those limitations are removed.
• There have been numerous other API changes as well. For instance, you can
now unexport a remote object, as well as export a object on a specific port.
Also, the RMI transport protocol JRMP has been significantly streamlined, and
server-side skeletons are no longer necessary under Java 2. For an exhaustive
list of changes, consult the release notes at
http://java.sun.com/products/jdk/1.2/docs/guide/rmi/relnotes.html
New url
Author: Thomas Hartwig (http://www.jguru.com/guru/viewbio.jsp?EID=1108477),
Apr 6, 2005
SUN's RMI FAQ
listserv@java.sun.com
which contains the message:
subscribe RMI-USERS
Note that the archives of the mailing list are here. Please check them out before
sending questions to the mailing list.
Is "pass by value" enforced for calls within the same VM to objects that
implement java.rmi.Remote? In other words, if I'm writing an object that
implements java.rmi.Remote, can I assume that calls to it that originate
within the local VM will enjoy the same "copy by value" rules for serializable
parameters?
Location: http://www.jguru.com/faq/view.jsp?EID=10742
Created: Feb 1, 2000 Modified: 2000-02-01 14:10:06.078
Author: Tim Rohaly (http://www.jguru.com/guru/viewbio.jsp?EID=10) Question
originally posed by Ben Youngdahl
(http://www.jguru.com/guru/viewbio.jsp?EID=6973
If you obtain a reference by simply instantiating HelloImpl, then its semantics are
that of a normal Java object. i.e., if you do:
First of all, you focus on the return value, which is not as interesting here as argument
parameters. Second of all, you focus on an immutable type, String, which is also not
as interesting.
Also, I think you should talk about why this is DANGEROUS that different things
can happen depending on how the reference is obtained.
The two things you mention have no relevance to the problem: return parameters are
treated the same as method arguments, and references to immutable objects are
treated the same as references to mutable objects.
I disagree that this is dangerous. There are fundamental differences between remote
objects and local objects that you can't abstract away. Indeed, it is dangerous if you
don't treat them differently! This is why the compiler forces you to deal with
RemoteException, like I say above. Thus, it is always explicit in your code what the
object's semantics are.
You can learn more about the necessary differences between local and remote objects
from "A Note on Distributed Computing" by Jim Waldo et al.
http://www.sun.com/research/technical-reports/1994/abstract-29.html.
This issue has also been discussed ad nauseam on the RMI-USERS mailing list. See:
http://archives.java.sun.com/archives/rmi-users.html.
In the first case (new "local" instance), we will not need a stub for every instance? Eg.
a server has a dispatcher that sends down a new servant instance to each client.
In the second case (using remote references), the server application must already have
instantiated such a servant instance, bound it to an entry in rmiregistry. More work
coming up: the client has to actually know beforehand which "name" that instance is
bound to. True/False?
The danger as I see it is that if Y is within a seperate VM, M is not truly affected. If Y
is within the same VM as X, M is affected.
See Appendix D.7 (pp 511,512) of the EJB 2.0 public draft. Doesn't it acknowledge
this situation is dangerous?
I do agree with you that it is dangerous to ignore whether an object is local or remote,
like for example COM/DCOM. I guess that's my point here: don't assume that
because an object extends Remote that it actually IS remote and will honor RMI pass-
by-value.
A danger with the second method is that you are giving control over the life span of
the ResultSet to the client--as long as the client holds a reference to the remote
object your server must maintain the database connection. Because database
connections are vital system resources, you probably want to maintain control of
them entirely on the server side or in a middle tier.
If you start the server with the java.rmi.server.logCalls system property set to true
(java -Djava.rmi.server.logCalls=true Server), you'll be able to monitor server
activity.
The rmiregistry program uses port 1099 by default. You can have it listen to a
different port by specifying a different port from the command line:
rmiregistry 1234
Comments and alternative answers
For complete details, see my RMI tutorial at Sun's Java Developer Connection:
http://developer.java.sun.com/developer/onlineTraining/rmi/RMI.html#FirewallIssues
I have a servlet that is doing an RMI call to a single remote object. Since
any invocation of the servlet is created in a new thread, I'm observing a
new TCP/IP connection for every single servlet request. Creating and
tearing down a TCP/IP connection between the servlet engine and the
remote object's JVM for every request seems to be a lot of overhead. I have
read through the RMI spec. It seems that one could create an alternate
implementation of java.rmi.server.RMIClientSocketFactory that could
manage a pool of TCP/IP connections and assign them to threads on an as-
needed basis. Is this possible?
Location: http://www.jguru.com/faq/view.jsp?EID=20880
Created: Mar 6, 2000 Modified: 2000-03-08 09:14:11.159
Author: Sameer Tyagi (http://www.jguru.com/guru/viewbio.jsp?EID=4381) Question
originally posed by Phil Earnhardt
(http://www.jguru.com/guru/viewbio.jsp?EID=8332
A remote object MyObject is bound to the registry and it has a method called
mymethod().
Servlets obtain a reference and invoke this method in their service methods. Let us
assume that 500 concurrent calls are made to this method from the servlet instance.
Does this mean that the 500 calls will be queued up ?
Well, actually no. The RMI object can be called by several threads concurrently. It is
very easy to test: simply have a counter in the object which is ticked up one at the
beginning of the method, and decrease it at the end. This way you'll know how many
threads are working on it concurrently. Print it out and you'll know for sure what's
happening.
It is rather simple: RMI/JRMP maintains connections from the client to the server. If a
call is to be made and all connections is currently in use another one is created. This
will only hold to a certain point however since there is a finite number of server
threads.
In the scenario you describe, it would be simple to obtain a reference to the object in
the init of the servlet and invoke methods on the objects in the service method.
Since you will always deal with the same instance of the remote object at all points
in time.
You can find all the details you need within the following Sun documents:
The server would need to invoke a method like this before binding the object and
starting the registry and similarly on the client beore looking up the object
RMISocketFactory.setSocketFactory (some vendor provided factory);
Note : In other words the vendors provide a SSL implementation of the registry that
needs to be started instead of the rmiregisty in case you are not programmatically
statring the registry through a LocateRegistry.createRegistry().
For activation, how do I get my objects to run in multiple VMs and not the
VM of rmid.exe ??
Location: http://www.jguru.com/faq/view.jsp?EID=22886
Created: Mar 10, 2000 Modified: 2000-03-10 13:08:36.557
Author: Sameer Tyagi (http://www.jguru.com/guru/viewbio.jsp?EID=4381)
The deal with spawning multiple VMs is the following bottom line. Refer to page 56 of
the RMI specs ...
"All objects with the same groupID are activated in the same Java VM".
period.
I have written an example for you that registers 2 Activable objects with the registry.
The 2 objects have different ActivationGroupID's as you can see in the source.
Since the objects are lazily activated, you can see that 2 VMs are spawned when the
client is run.
I have enclosed with this the complete example. The example contains 1. The
remote interface
2. The remote interface implementation
3. The program to register the server.
4. The client program
5. The batch files to run both client and server.
package com.sameer;
import java.net.InetAddress;
import java.rmi.*;
import java.rmi.activation.*;
}
public String sayHello(){
String hostname=null;
try{
hostname=
InetAddress.getLocalHost().getHostName();
}catch (java.net.UnknownHostException who){}
return "Hello World from " + hostname;
}
package com.sameer;
package com.sameer;
import java.rmi.*;
import java.rmi.activation.*;
import java.util.Properties;
public class RegisterHelloServer {
/*
This creates in the current VM and the current identifier for
the ActivationGroupID. If the ActivationGroupID does not
exist a new one is created.
ActivationDesc desc = new
ActivationDesc("com.sameer.HelloServer",
"file:/export/home/whitney/java/classes/", null, true);
*/
ActivationDesc desc = new ActivationDesc(agi,
"com.sameer.HelloServer", "file:/export/home/whitney/java/classes/",
null, true);
System.out.println("Gourp ID =" +desc.getGroupID());
Hello stub = (Hello)Activatable.register(desc);
Naming.rebind("HelloServer", stub);
}
}
package com.sameer;
import java.rmi.*;
public class HelloClient {
try {
Hello obj = (Hello) Naming.lookup("/HelloServer");
System.out.println(obj.sayHello());
}
grant {
// Allow everything for now
permission java.security.AllPermission;
};
On top of TCP/IP, RMI uses a wire level protocol called Java Remote Method Protocol
(JRMP). JRMP is a proprietary, stream-based protocol that is only partially specified
and now consists of two versions. The first version was released with the JDK 1.1
version of RMI and required the use of Skeleton classes on the server. The second
version was released with the Java 2 SDK. It has been optimized for performance
and it does not require skeleton classes. (It is important to note that some alternate
implementations, such as BEA Weblogic and NinjaRMI do not use JRMP, but instead
use their own wire level protocol. ObjectSpace's Voyager does recognize JRMP and
will interoperate with RMI at the wire level.)
Sun and IBM have jointly worked on the next version of RMI, called RMI-IIOP, which
will be available with Java 2 SDK Version 1.3. The interesting thing about RMI-IIOP is
that instead of using JRMP, it will use the Object Management Group (OMG) Internet
Inter-ORB Protocol, IIOP, to communicate between clients and servers.
In most cases, developers do not need to know about the underlying protocol.
With JDK 1.2, what policies do I have to setup to grant the necessary
permissions for RMI?
Location: http://www.jguru.com/faq/view.jsp?EID=24539
Created: Mar 15, 2000 Modified: 2000-03-15 07:34:14.029
Author: John Zukowski (http://www.jguru.com/guru/viewbio.jsp?EID=7) Question
originally posed by sajith prasad k
(http://www.jguru.com/guru/viewbio.jsp?EID=15898
How do I setup a Servlet as an RMI client (and not get an RMI Security
exception in the process)?
Location: http://www.jguru.com/faq/view.jsp?EID=25918
Created: Mar 19, 2000 Modified: 2000-08-13 16:39:20.301
Author: Dieter Wimberger (http://www.jguru.com/guru/viewbio.jsp?EID=25708)
Question originally posed by John Collins
(http://www.jguru.com/guru/viewbio.jsp?EID=21866
I think this depends a lot on the JDK you are using to run your Servlet Engine.
• Platform 2 (JDK 1.2, 1.3): take a look at the security policy. Refer to the
documentation for setting correct java.net.SocketPermission entries, plus
maybe File Access Permissions and in some cases ClassLoader permissions.
• Platform 1 (JDK 1.1.x): The only real way I found to circumvent my problems
was to implement my own RMI SecurityManager. Therefore simply extend the
java.rmi.RMISecurityManager class and implement your own policy overriding
specific permission check methods. Most likely those will be: checkConnect,
checkRead, checkWrite. But I suggest to examine the API doc of the
RMISecurityManger to find out more.
To set that SecurityManager you have to add following line to your Servlet init()
method:
You have to make sure that the servlet engine and JVM you are using...
1) use a security manager
2) the security manager does something meaningful
3) the security policy is meaningful
Try these flags in the command that starts java -Djava.security.manager -Djava.
security.policy==.\foo.policy
try
{
System.out.println( h2o + "Information..." + h2c );
System.out.println( " Security Manager: " +
System.getSecurityManager().getClass().getName() + p );
System.out.println( " ClassLoader: " +
this.getClass().getClassLoader() + p );
// weblogic.utils.classloaders.GenericClassLoader gcl =
(weblogic.utils.classloaders.GenericClassLoader)this.getClass().getClassLoader();
// gcl.setDebug( true );
try
{
System.out.println( h2o + "Attempting file write to d:/Java..." + h2c
);
File f = new File( "d:/Java/blah.txt" );
FileWriter fw = new FileWriter( f );
fw.write( "test\n" );
fw.close();
System.out.println( " -- allowed -- " + p );
}
catch( Exception e ) { System.out.println( " -- rejected -- " +
e.getMessage() + p ); }
try
{
System.out.println( h2o + "Attempting file write to
d:/Java/TestServlet..." + h2c );
File f = new File( "d:/Java/TestServlet/blah.txt" );
FileWriter fw = new FileWriter( f );
fw.write( "test\n" );
fw.close();
System.out.println( " -- allowed -- " + p );
}
catch( Exception e ) { System.out.println( " -- rejected -- " +
e.getMessage() + p ); }
try
{
System.out.println( h2o + "Attempting file read to c:/Ntdetect..." +
h2c );
File f = new File( "c:/Ntdetect.com" );
FileReader fr = new FileReader( f );
int c = fr.read();
System.out.println( " -- allowed -- " + p );
}
catch( Exception e ) { System.out.println( " -- rejected -- " +
e.getMessage() + p ); }
try
{
System.out.println( h2o + "Attempting file read to
c:/weblogic/weblogic.properties..." + h2c );
File f = new File( "c:/weblogic/weblogic.properties" );
FileReader fr = new FileReader( f );
int c = fr.read();
System.out.println( " -- allowed -- " + p );
}
catch( Exception e ) { System.out.println( " -- rejected -- " +
e.getMessage() + p ); }
try
{
System.out.println( h2o + "Attempting to connect to yahoo.com..." +
h2c );
Socket s = new Socket( "yahoo.com", 8080 );
System.out.println( " -- allowed -- " + p );
}
catch( Exception e ) { System.out.println( " -- rejected -- " +
e.getMessage() + p ); }
try
{
System.out.println( h2o + "Attempting to connect to hacker.com..." +
h2c );
Socket s = new Socket( "hacker.com", 8080 );
System.out.println( " -- allowed -- " + p );
}
catch( Exception e ) { System.out.println( " -- rejected -- " +
e.getMessage() + p ); }
try
{
System.out.println( h2o + "Attempting to listen on port 37337..." +
h2c );
ServerSocket s = new ServerSocket( 37337 );
Socket c = s.accept();
System.out.println( " -- allowed -- " + p );
}
catch( Exception e ) { System.out.println( " -- rejected -- " +
e.getMessage() + p ); }
try
{
System.out.println( h2o + "Attempting to listen on port 7001..." +
h2c );
ServerSocket s = new ServerSocket( 7001 );
Socket c = s.accept();
System.out.println( " -- allowed -- " + p );
}
catch( Exception e ) { System.out.println( " -- rejected -- " +
e.getMessage() + p ); }
/*
try
{
System.out.println( h2o + "Attempting native call..." + h2c );
native0( 1 );
System.out.println( " -- allowed -- " + p );
}
catch( Exception e ) { System.out.println( " -- rejected -- " +
e.getMessage() + p ); }
*/
try
{
System.out.println( h2o + "Attempting exec..." + h2c );
Runtime.getRuntime().exec( "dir" );
System.out.println( " -- allowed -- " + p );
}
catch( Exception e ) { System.out.println( " -- rejected -- " +
e.getMessage() + p ); }
try
{
System.out.println( h2o + "Attempting system exit..." + h2c );
System.exit( 3 );
System.out.println( " -- allowed -- " + p );
}
catch( Exception e ) { System.out.println( " -- rejected -- " +
e.getMessage() + p ); }
System.out.println("</BODY></HTML>");
The Sun RMI implementation does not offer a standardized method to control the
number of clients biding to a remote object.
Comments and alternative answers
Does a stub possess a server-side role also? Practically all the literature on
RMI, including the RMI Specification document, talks only about the role of
a stub on the client side. For instance, once I generate a stub class and copy
it over to the client side, can it now be safely deleted from the server side?
Location: http://www.jguru.com/faq/view.jsp?EID=33986
Created: Apr 9, 2000 Modified: 2000-04-09 16:52:27.293
Author: Avi Kak (http://www.jguru.com/guru/viewbio.jsp?EID=26410)
Referring to its client-side role, this is what the RMI Specification document has to
say about stubs:
A stub for a remote object acts as a client's local representative or proxy for the
remote object. The caller invokes a method on the local stub which is responsible for
carrying out the method call on the remote object. In RMI, a stub for a remote object
implements the same set of remote interfaces that a remote object implements.
When a stub's method is invoked, it does the following: (i) initiates a connection with
the remote VM containing the remote object; (ii) marshals (writes and transmits) the
parameters to the remote VM; (iii) waits for the result of the method invocation; (iv)
unmarshals (reads) the return value or exception returned; (v) returns the value to
the caller.
The Specification document says practically nothing about the role of a stub class on
the server side. The fact is that the stub of an implementation class has a server side
role also. This is immediately apparent if after copying over the stub to the client
side you try to delete it from the server side. The Java runtime would then throw an
exception with the error message: "Stub class not found."
On the server side, the stub class is needed to construct stub objects corresponding
to the remote objects. It is the stub objects that get transmitted over to the client
side over the TCP link. When a client invokes a method on a remote server object,
the method is actually invoked on the locally available version of the stub object
corresponding to the remote server object.
How can I load the stub and interface files dynamically at the client, instead
of copying manually, with RMI applications?
Location: http://www.jguru.com/faq/view.jsp?EID=35031
Created: Apr 11, 2000 Modified: 2000-04-11 20:19:16.83
Author: Damian Fernandez Perez
(http://www.jguru.com/guru/viewbio.jsp?EID=1958) Question originally posed by
Puneet Sachdeva (http://www.jguru.com/guru/viewbio.jsp?EID=28785
http://java.sun.com/products/jdk/1.2/docs/guide/rmi/codebase.html
RMI uses serialization as its basic and only mechanism for sending objects across a
network.
Well, to tell you exactly how to do it would take up too much space, but to give you
an idea, you would basically create a server which listens for connections on a port
and accept these connections and get each clients names. Then you would develop a
client program which connects to this server. When one "client" types a message and
presses 'Send', the message is routed through the server and out to all "client's"
connected. This can be done by Input/Output streams, or (the easier way) RMI.
RMI will allow you to pass any object that is serializable according to the serialization
specification. This includes objects that implement Externalizable as well as
objects that implement Serializable.
Note that Externalizable extends Serializable, so anywhere you see the use of
the generic term "serializable" you can assume it refers to objects that implement
either of these interfaces.
SUN provides a good trail in the Java tutorial that covers RMI at
http://java.sun.com/docs/books/tutorial/rmi/overview.html.
Comments and alternative answers
You can also try the jGuru tutorial at the JDC: ht...
Author: John Zukowski (http://www.jguru.com/guru/viewbio.jsp?EID=7), May 18,
2000
You can also try the jGuru tutorial at the JDC:
http://developer.java.sun.com/developer/onlineTraining/rmi/.
Remote Method Invocation (RMI) over Internet Inter-Orb Protocol (IIOP) delivers
Common Object Request Broker Architecture (CORBA) compliant distributed
computing capabilities to the JavaTM 2 platform and to the Java Development Kit
(JDKTM) 1.1. RMI over IIOP was developed by Sun and IBM. The joint work by Sun
and IBM to implement Object Management Group (OMG) standards demonstrates
the spirit of collaboration that continually moves the Java platform forward.
RMI over IIOP combines the best features of RMI with the best features of CORBA.
Like RMI, RMI over IIOP speeds distributed application development by allowing
developers to work completely in the Java programming language. When using RMI
over IIOP to produce Java technology-based distributed applications, there is no
separate Interface Definition Language (IDL) or mapping to learn. Like RMI, RMI over
IIOP provides flexibility by allowing developers to pass any serializable Java object
(Objects By Value) between application components. Like CORBA, RMI over IIOP is
based on open standards defined with the participation of hundreds of vendors and
users in the Object Management Group. Like CORBA, RMI over IIOP uses IIOP as its
communication protocol. IIOP eases legacy application and platform integration by
allowing application components written in C++, Smalltalk, and other CORBA
supported languages to communicate with components running on the Java platform.
Some Java books show RMI code in which the security manager is set to
RMISecurityManager on the server side of an RMI application. Is there any
reason to invoke RMISecurityManager on the server side of an RMI
application?
Location: http://www.jguru.com/faq/view.jsp?EID=41015
Created: Apr 26, 2000 Modified: 2000-04-30 23:54:44.373
Author: Avi Kak (http://www.jguru.com/guru/viewbio.jsp?EID=26410)
}
Good luck!
Comments and alternative answers
Yes.
Just make sure your remote client is implemented as an RMI service, implementing a
Remote interface and beeing exported as a UnicastRemoteObject (either by
subclassing UnicastRemoteObject or by using the static exportObject() method of
that class).
If this is done, a reference to the client can be sent to the server as a parameter of a
server method, and the object will not be serialized as other parameters, but a
remote reference is established.
The server can now call methods of the clients remote interface via this reference!
Is there any way I can send a remote object through RMI to the server that
the server can then use to trigger a callback at the client?
Location: http://www.jguru.com/faq/view.jsp?EID=41807
Created: Apr 28, 2000 Modified: 2000-05-05 08:38:07.704
Author: Mikael Jakobsson (http://www.jguru.com/guru/viewbio.jsp?EID=41777)
Question originally posed by Allan Wax
(http://www.jguru.com/guru/viewbio.jsp?EID=26731
Now, the server will receive a remote reference in the registerClient() method, that
can be used for callbacks to the client.
Of course, you'll also have to generate the stub and skeleton files for the client as
well as the server using rmic.
The ugly part about this is the stub. The server must...
Author: Will Cardwell (http://www.jguru.com/guru/viewbio.jsp?EID=60369), Nov
17, 2000
The ugly part about this is the stub. The server must have a stub for the client in order
to do the callback. Since the client may be unknown when the server is built, this may
not always be possible. And you may not want to give all clients the authority to place
files on your server.
Re: The ugly part about this is the stub. The server must...
Author: Sharon Lu (http://www.jguru.com/guru/viewbio.jsp?EID=459034), Jul
20, 2001
Do you have any suggestions on how to work around this problem? Basically,
how do you pass an instance across RMI, like passing "this" pointer in C++ which
represents the "AppData", and later server can pass back to client, then the client
can resolve it into correct instance?
Re: Re: The ugly part about this is the stub. The server must...
Author: Will Cardwell (http://www.jguru.com/guru/viewbio.jsp?EID=60369),
Jul 20, 2001
In my case I was creating APIs for our application. I wanted outside developers
to be able to connect via RMI to our application and register to listen for
callbacks as well as making calls to the application. To do the callback, the
server needs a remote object stub for the outside application. Since the server is
built by us and the outside application by someone else, the server does not
have the stub. You could require the outside developer to place his stub in the
server's classpath, but that requires the server administrator to keep up with
foreign code. What I did was write a wrapper class that encapsulates the RMI
functions on the client side. This wrapper is distributed to the outside developer
with the stub and interface to our application. The outside user then uses the
wrapper class in his application as a proxy to get to the server. It is the wrapper
that actually exports itself as a remote object for callbacks. The server only
needs a stub for this wrapper class, which is always the same no matter who the
outside developer is. The using application class registers as a listener for
callbacks by calling the wrapper class. But this is now only a local object
reference and not a remote. This works nicely and also frees the outside
developer from having to deal with the RMI code at all.
Re: Re: Re: The ugly part about this is the stub. The server must...
Author: Randy Pond
(http://www.jguru.com/guru/viewbio.jsp?EID=487474), Nov 13, 2001
We have a similar situation in our development. We have clients making
RMI calls to the server, and the server making RMI callbacks to the client.
Our server needs the stubs of any new clients that are created. Distributing a
class file to the clients that act as a callback proxy is the right solution. We
should have done that. We distributed an interface. Heh.
RMI Callbacks
Author: Jim Teaff (http://www.jguru.com/guru/viewbio.jsp?EID=438114), Jun 25,
2001
A code example would be very useful!
http://java.sun.com/products/jdk/1.2/docs/guide/rmi/getstart.doc.html
"A security manager is required in any JVM that needs to download code, and RMI
clients need to download RMI stubs (as well as custom classes or interfaces needed
to communicate with the RMI server)."
The quoted statement from the cited document is misleading. If the downloaded
code on the client side consists of RMI stubs only, a security manager is not needed
at all. In most RMI applications, the only reason for installing a security manager on
the client side is to enable dynamic loading of classes by a client (and to then subject
these classes to certain security restrictions).
On the other hand, dynamic loading of classes and interfaces by a client takes place
over another link, typically through the http service provided by a server. It is the
code that is transported over the latter link that is subject to the security restrictions
of the installed security manager.
The following example illustrates the fact that no security manager need be installed
in an RMI application anywhere if there is no dynamic loading of code by a client. The
sayHello() method of the remote object on the server returns two different kinds of
greetings, depending on whether the client invokes the sayHello() method with a
Male argument or a Female argument.
import java.rmi.*;
import java.io.*;
import java.io.*;
import java.rmi.*;
import java.rmi.server.*;
import java.net.*;
try {
m = (Male) obj;
} catch( Exception e ) {}
if ( m != null )
returnString = "Good Day, Sir! Hello from Avi Kak at " + hostname;
else {
try {
f = (Female) obj;
} catch( Exception e ) {}
if ( f != null )
returnString = "Good Day, Madam! Hello from Avi Kak at " +
hostname;
}
return returnString;
}
}
import java.rmi.*;
import java.rmi.server.*;
import java.rmi.registry.*;
import java.rmi.*;
java HelloClient
Yes, RMI can be used for this purpose. You can achieve it by two ways:
• By invoking one server object in the client application. The server object in
turn can call other remote objects on the same machine or on different
machines.
• By invoking more than one server objects directly from the same client.
You can use servlet as the client for the RMI server objects, and later format the data
into HTML before sending the response to the client.
What gives?
Location: http://www.jguru.com/faq/view.jsp?EID=43169
Created: May 1, 2000 Modified: 2000-09-10 23:44:58.988
Author: Avi Kak (http://www.jguru.com/guru/viewbio.jsp?EID=26410)
The code supplied with the tutorial is contained in a number of different files, some
containing classes and others containing command line statements. Use the following
for the runclient.bat file on the client side:
java -Djava.security.policy=/RMI5.d/policy
-Djava.rmi.server.codebase=http://rvl4.ecn.purdue.edu:2002/
RMIClientLoader
where you must replace the string rvl4.ecn.purdue.edu by the name of your
computer that is providing the HTTP service for downloading the classes needed by
your client program. You'd also need to replace the string RMI5.d by the pathname of
the client-side directory containing the policy file. The policy file contains:
where you'd need to replace the string RMI5.d by the pathname to the directory
containing the RMI code on the client side. You'd also need to replace
rvl4.ecn.purdue.edu as before.
An alternative solution consists of incorporating on the client side the following null
override definition for the checkPermission() method in the
RMIClientBootstrapSecurityManager class:
Although this works, it is not a good option since it violates the spirit of the
RMIClientBootstrapSecurityManager class. The idea behind the
RMIClientBootstrapSecurityManager class is to have a minimally relaxed version
of RMISecurityManager for the RMIClassLoader to bootstrap load the stubs and the
other support classes and interfaces on the client side. A null override for
checkPermission() throws the security control wide open.
While you are modifying the code, you might as well comment out the following line
on the server side:
System.setSecurityManager( new RMIServerSecurityManager() );
from the main() of the RMIServer class. Setting a security manager on the server
side serves no useful function in this example.
Sure, well not exactly simultaneously, but within the same client:
//imports here
public class MyClient {
public static void main(String[] args){
try {
ThisServer server1 =
(ThisServer)Naming.lookup("rmi://this.server.host/ThisServer");
ThatServer server2 =
(ThatServer)Naming.lookup("rmi://that.server.host/ThatServer");
//now call some methods with each server
catch(Exception e) {}
}
}
Mostly you will need to dynamically load and instanciate a class (using
Class.forName()), and then register it within the RMI registry.
To instruct your RMI server to register new objects, you could use a server socket
that accepts connections with which you send directions for registering classes.
Another idea would be to use another RemoteObject which only service would be to
load/create and register other Remote Objects through a register(String name,
String classname) method.
You could also have a property file which contain <object name>=<object
classname> and that will be parsed when starting your RMI server.
How do I debug RMI programs, where different pieces are running all over
the place? Can I do remote debugging?
Location: http://www.jguru.com/faq/view.jsp?EID=46184
Created: May 8, 2000 Modified: 2000-05-13 20:30:23.834
Author: Steven Newton (http://www.jguru.com/guru/viewbio.jsp?EID=44606)
Question originally posed by John Zukowski PREMIUM
(http://www.jguru.com/guru/viewbio.jsp?EID=7
One useful way to do this is to create a remote tracing facility. A simple class that
communicates with a central server logging facility using a static method (somewhat
like the Unix syslog protocol) can be included on both the client and remote side.
Along with this you may wish to define an unchecked subclass of RuntimeException
TraceableException which your code can throw, and in the constructor for the
exception contact the log server and log the error. Something like:
public class TraceFacility {
public static trace(Exception e, String message) {
// send stacktrace and message to central log server here
}
}
In the event one wants to use a wide open security policy on the client side
of an RMI program, it is recommended that the policy be made specific to
the directory containing RMI code. Is it always possible to do so?
Location: http://www.jguru.com/faq/view.jsp?EID=46389
Created: May 8, 2000 Modified: 2000-05-13 20:40:05.158
Author: Avi Kak (http://www.jguru.com/guru/viewbio.jsp?EID=26410)
During the initial phases of RMI code development, it is not uncommon for
programmers to use the can-do-anything-it-wants policy on the client side, as given
by
grant {
permission java.security.Allpermissions;
};
where the directory RMI5.d contains the client side RMI code. But a problem with
this policy declaration is that the can-do-anything-it-wants applies only to the code in
the RMI5.d directory. It does not apply to any classes the client might download
from a remote site. So if your client is engaged in dynamic loading of classes, the
above directory-specific wide-open policy will not work because the downloaded code
would still get sandboxed.
If you must use a wide open policy for convenience and your RMI application is doing
dynamic loading of classes, you'd need to add another declaration to your client-side
policy file, the additional declaration would mention the source of the downloaded
code. For example, if for the sake of demonstration I wanted to use a wide-open
policy for running the the bootstrap loading example of the jGuru RMI tutorial, I'd
change the following statement from main() of the RMIClientLoader.java file
System.setSecurityManager(
new RMIClientBootstrapSecurityManager());
to
System.setSecurityManager(
new RMISecurityManager());
and then use the following policy file on the client side
where the first "grant" gives the can-do-anything-it-wants privileges to the client-
side RMI code in the directory "RMI5.d" and where the second "grant" gives the
same privileges to the code downloaded from the HTTP service provided by
rvl4.ecn.purdue.edu. You can put this policy file into effect by using the following
runclient.bat:
where you'd need to make obvious substitutions for the strings "RMI5.d" and
"rvl4.ecn.purdue.edu".
How can I check that the connection between the server and the client is
valid at all times?
Location: http://www.jguru.com/faq/view.jsp?EID=47532
Created: May 10, 2000 Modified: 2000-05-13 20:50:22.472
Author: Avi Kak (http://www.jguru.com/guru/viewbio.jsp?EID=26410) Question
originally posed by Shahram Khorsand
(http://www.jguru.com/guru/viewbio.jsp?EID=3357
Our server sends pings to the client, and vice versa, allowing us to verify the
connection.
If this "ping" throws an RMI exception, that indicates a connection is down. Now,
getting it to reconnect, that's a different story.. and my task for the day...
What's with the Unreferenced interface? It would seem that a server should
be able to use the unreferenced() method of this interface to obtain
notification if a client crashes or otherwise becomes disconnected from the
server. But it does not seem to work that way? Why?
Location: http://www.jguru.com/faq/view.jsp?EID=48518
Created: May 12, 2000 Modified: 2000-05-13 21:00:20.894
Author: Avi Kak (http://www.jguru.com/guru/viewbio.jsp?EID=26410)
The RMI Specification document says:
The java.rmi.server.Unreferenced interface allows a server object to receive
notification that there are no clients holding references to it. .... When the
"reference" set becomes empty, the Unreferenced.unreferenced() method is
invoked...
The reference set in this quote refers to the set of client VM's, each holding a
reference to the remote object.
Reading this, one could draw the conclusion that if all the clients got disconnected
from a server that has implemented the Unreferenced interface, the server would be
notified of such disconnection by automatic invocation of the
Unreferenced.unreferenced() method of this interface. But in reality that does not
happen. See, for example, the code in the "Feedback and Comments" section of
jGuru RMI FAQ Entry 1002. On the other side of the coin, one can see easily from the
jGuru Distributed Garbage Collection Exercise that when there are no client
references to a remote object that has implemented the Unreferenced interface, the
server does indeed receive notification via the automatic invocation of the
Unreferenced.unreferenced() method. So why does the RMI system work
differently in the two cases?
This apparent anomaly can be explained by the fact that there is a distinction
between remote objects that are registered with the RMI registry and remote objects
that are not registered. The registry acts like a client with regard to the server
objects that are registered. A registry holds a lease on a registered server object in
much the same manner as a regular client. So even if all the genuine clients were to
get disconnected from a server, the method Unreferenced.unreferenced() will not
be invoked on a server object as long as it stays registered.
How come the server-side skeleton class is not required under JDK 1.2?
Location: http://www.jguru.com/faq/view.jsp?EID=48933
Created: May 14, 2000 Modified: 2000-05-14 21:08:38.081
Author: Avi Kak (http://www.jguru.com/guru/viewbio.jsp?EID=26410) Question
originally posed by alok kumar
(http://www.jguru.com/guru/viewbio.jsp?EID=47873
How do servlets differ from RMI? What are the advantages and
disadvantages of each technology?
Location: http://www.jguru.com/faq/view.jsp?EID=49828
Created: May 16, 2000 Modified: 2000-06-21 16:29:19.035
Author: Shaun Childers (http://www.jguru.com/guru/viewbio.jsp?EID=30243)
Question originally posed by mehdi lababidi
(http://www.jguru.com/guru/viewbio.jsp?EID=48184
RMI (Remote Method Invocation) is just that - a way to invoke methods on remote
machines. It is way for an application to talk to another remote machine and execute
different methods, all the while appearing as if the action was being performed on
the local machine.
Servlets (or JSP) are mainly used for any web-related activity such as online
banking, online grocery stores, stock trading, etc. With servlets, you need only to
know the web address and the pages displayed to you take care of calling the
different servlets (or actions within a servlet) for you. Using RMI, you must bind the
RMI server to an IP and port, and the client who wishes to talk to the remote server
must know this IP and port, unless of course you used some kind of in-between
lookup utility, which you could do with (of all things) servlets.
For more detailed information regarding servlets and RMI refer to following sun sites:
http://www.java.sun.com/products/servlet/index.html and
http://developer.java.sun.com/developer/onlineTraining/rmi/ [(the last link is a
tutorial by JGuru!)].
RMI
Author: Chittaranjan Muthumalai
(http://www.jguru.com/guru/viewbio.jsp?EID=420228), May 16, 2001
I used the LocateRegistry as shown in the example. But the subsequent call to
Naming.rebind throws an exception Connection refused. But If I give the host name
with the port as //host:portnum/somename It works. I use this in Sun ultra!
Does there exist a minimal "Hello" kind of an example for getting started
with the Remote Object Activation feature of RMI?
Location: http://www.jguru.com/faq/view.jsp?EID=50357
Created: May 16, 2000 Modified: 2000-06-08 02:11:31.51
Author: Avi Kak (http://www.jguru.com/guru/viewbio.jsp?EID=26410)
The minimal "Hello" programs have played an important role in helping people get
started with the various programming languages and paradigms. Here is a "Hello"
program for Remote Object Activation in Java. This program does basically the same
thing as what is achieved by an RMI implementation of a typical "HelloServer"
program. The main difference here is that we no longer have a continuously running
"Hello" server. Instead, the HelloImpl server object is activated only when it is
needed by a client. (Note that this simple example here does not illustrate how
Java's remote object activation deals with data persistence. But it does illustrate how
to set up the activation framework for an activatable server object.)
For a detailed discussion of the classes and methods used in the code shown below,
the reader is referred to the RMI Specification document and to the remote object
activation tutorials.
import java.rmi.*;
import java.rmi.*;
import java.rmi.activation.*;
import java.rmi.*;
import java.rmi.activation.*;
import java.rmi.*;
java HelloClient
How do I set a timeout for an RMI client such that it doesn't wait
indefinitely in establishing a connection to an RMI server ?
Location: http://www.jguru.com/faq/view.jsp?EID=50500
Created: May 17, 2000 Modified: 2000-05-20 03:11:41.292
Author: Sarit Bose (http://www.jguru.com/guru/viewbio.jsp?EID=44426) Question
originally posed by Aleksander Grzebyta
(http://www.jguru.com/guru/viewbio.jsp?EID=26174
where the socket is created by the factory (default/custom) you are using.
What should you do such that an RMI server program can accept multiple
clients and actually parallelize their execution?
Location: http://www.jguru.com/faq/view.jsp?EID=55767
Created: May 24, 2000 Modified: 2000-05-26 16:26:38.772
Author: Sameer Tyagi (http://www.jguru.com/guru/viewbio.jsp?EID=4381) Question
originally posed by Massimiliano Bigatti
(http://www.jguru.com/guru/viewbio.jsp?EID=39645
Well first theres nothing you can do explicitly for this. This IS the way it works.
Multiple client calls to the same object are NOT queued up but concurrent method
invocations on an RMI object are automatically executed in separate threads as
necessary. Serial invocations from the same client are processed in the same thread
as an optimization.
What this means is that if you are maintaining state in the object between method
calls or need syncronization, then the remote method must be synchronized in the
interface, or it should use synchronizing in its implementation with
synchronize(object){code...}
It also means that that this method will be executed with the lock acquired for the
implementation object (not the stub or skeleton). In this case, even though the
invocations from the two clients are executed in separate threads, the execution of
the method will indeed be mutually exclusive because of the lock on the
implementation object.
I think that if RMI calls from the same JVM are packed...
Author: jerry chin (http://www.jguru.com/guru/viewbio.jsp?EID=60541), Jun 7, 2000
I think that if RMI calls from the same JVM are packed into one thread, it can not be
thread-safe. Because client may have multiple threads in one JVM, and in each thread
it can call remote methods. In such a condition, the call sequence from different
thread is not determined when they are put to one thread. If these calls change some
status of server, then the result returned to each thread is not determined too.
In the above 2 cases, the client makes method invocations on the server serially, but at
different intervals aof time. Does the RMI runtime still use the same thread for both
cases?
http://java.sun.com/products/jdk/1.2/docs/guide/rmi/spec/rmiTOC.doc.html
"A method dispatched by the RMI runtime to a remote object implementation may or
may not execute in a separate thread. The RMI runtime makes no guarantees with
respect to mapping remote object invocations to threads. Since remote method
invocation on the same remote object may execute concurrently, a remote object
implementation needs to make sure its implementation is thread-safe."
What I understand from this is - even different client requests could be on same thread
.. serializing all the requests in effect .. correct me if I am wrong..
http://java.sun.com/products/jdk/1.1/docs/guide/rmi/spec/rmiTOC.doc.html
Can some one verify or confirm what exactly happens in the latest RMI for clients on
different VMs????
Thanks,
-Rahul
P.S. If possible send a cc of reply to me at rahul@matta.net
How can multiple VM's be spawned from within the same activation setup
program?
Location: http://www.jguru.com/faq/view.jsp?EID=60096
Created: Jun 7, 2000 Modified: 2001-03-21 22:07:19.528
Author: Avi Kak (http://www.jguru.com/guru/viewbio.jsp?EID=26410)
Sameer Tyagi has a wonderful example showing how multiple VM's can be spawned
within the same activation setup program. Here is a minimalist version of that
program, along the same lines as the minimalist "Hello" program for remote object
activation.
The minimalist version shown below is instructive in the sense that it does not invoke
security managers anywhere explicitly. That is, the RMISecurityManager is not set
either in the server programs or in the client programs. Also, there is no specifying of
the security policy system property for launching either the activation daemon rmid
on the server side or the program HelloClient on the client side. Although they
would be necessary for more general programs involving dynamic loading of classes,
the essence of Sameer's example code can be illustrated without their invocation.
However, note that you still need a policy file for the VM's you'd be launching in the
activation setup program on the server. The security policy for the activated VM is
needed only for the reason that the sayHello() method tries to find the name of the
local host.
To make this code work on your machine, you'd need to make appropriate
substitutions for the name rvl4.ecn.purdue.edu of my server machine and the
name RMI13.d of my RMI directory on the server side.
import java.net.InetAddress;
import java.rmi.*;
import java.rmi.activation.*;
import java.rmi.*;
import java.rmi.activation.*;
import java.util.Properties;
#! /bin/sh
rmiregistry&
rmid&
sleep 1
java RegisterHelloServer
import java.rmi.*;
java HelloClient
Practically all examples of the setup programs for remote object activation
start out by specifying a security policy file to be used by the activation
daemon when launching a new VM for an activatable object. Assuming that
an activatable object needs access to a system resource, is it always
necessary to do so?
Location: http://www.jguru.com/faq/view.jsp?EID=61540
Created: Jun 7, 2000 Modified: 2000-06-07 11:40:46.632
Author: Avi Kak (http://www.jguru.com/guru/viewbio.jsp?EID=26410)
No. The alternative consists of directly informing the activation daemon about the
security policy to use for the activatable objects. Before showing how that is done,
let's look at how a typical activation setup program begins.
It is common for the setup programs for remote object activation to specify a
security policy file explicitly to be used for the VM's that are activated by the rmid
daemon when a request to that effect is received from a client. For illustration, all
the on-line remote object activation tutorials have their activation setup programs
begin with statements like
The first statement creates an empty properties list with no default values. The
second statement adds to this list and tells the system about the location of the
security policy file. The third statement then creates an identifier for an activation
group using the augmented Properties object props for the first argument to the
ActivationGroupDesc constructor. Recall that the activation daemon will be able to
launch a new VM for each separate activation group identifier in a setup program.
Assuming that the activatable objects need access to system resources, this raises
the question of whether it is always necessary to specify a security policy file for the
spawned VM's in the activation setup program. Instead, could one directly inform the
activation daemon rmid about a security policy to use and then have the daemon
apply that security to all the activatable objects?
Yes, it is possible to inform the activation daemon directly about the security policy
to use for all the activatable objects. To use this alternative approach, in your
activation setup program you could delete entirely the first two statements shown
above, and replace the third statement with
rmid -C-Djava.security.policy=/home/rvl4/a/kak/RMI13.d/policy
The security policy thus specified is passed on to each VM spawned by the activation
daemon. While simplifying the code a little bit, this approach implies that all the
spawned VM's will be governed by the same security policy. If an application
demands that the different VM's spawned by the activation daemon be governed by
different security policies, one has no choice but to take recourse to the first
approach.
So, by object deactivation one could conceivably mean different things depending on
how exactly the server side is disabled with regard to incoming client requests,
ranging presumably from the shutdown of the entire activation system, to the
deactivation of the entire group in which the object resides, to the deactivation of
just one object. Of course, when you shut down a VM, you would deactivate all the
activated objects in the activation group corresponding to that VM.
How does a client deactivate a server object immediately after a remote call
to the object has been executed successfully?
Location: http://www.jguru.com/faq/view.jsp?EID=76184
Created: Jun 15, 2000 Modified: 2000-06-15 13:16:10.543
Author: Avi Kak (http://www.jguru.com/guru/viewbio.jsp?EID=26410)
The community literature is somewhat confusing about how a client should go about
deactivating a remote server object and, to the extent I know, there are no on-line
tutorials dealing with this issue. My goal here is to clarify the confusion and to
present sample code that works for deactivating an object that was activated
previously.
But first let me cite two of the more important postings regarding object deactivation
I found in the on-line community literature. In a posting dealing with object
deactivation in the Sun's RMI-USERS mailing list archive, Adrian Colley says:
"An easier way is to first unexport the object in question, thus guaranteeing that you
will get no future remote calls. Then deactivate, in a background thread if
necessary."
But then in a subsequent posting dealing with object deactivation, William Grosso
says
" .... there seems to be no reason to call unexportObject ...."
In the same posting, William Grosso presents a deactivating thread in which he has
intentionally commented out the unexportObject() statement since, according to
him, it adds nothing to the code. Evidently, William Grosso's observation runs
counter to Adrian Colley's recommendation.
In the rest of this note, I'll first mention what I mean by object deactivation. I'll then
present sample code that implements this definition.
i) it should shut down the VM that was spawned by the activation system to activate
the object; and ii) a client's request for service from the object should automatically
spawn the VM again if it was shut down by a previous deactivation request.
then the following must hold true for an implementation of object deactivation:
For those starting out with object deactivation, the following observations about the
code that follows might prove useful:
1. The policy file on the server side is needed for i) starting a deactivation thread
in the deactivate() method; and for ii) finding out the name of the local
host in the sayHello() method.
2. Since I used a Solaris machine as a server and an NT machine as a client, for
command line invocations I have a shell file on the server side and a bat file
on the client side.
3. To run this code on your system, you'd obviously have to change the strings
"rvl4.ecn.purdue.edu" and "/home/rvl4/a/kak/RMI16.d/" to the name of your
server machine and the name of your server-side directory, respectively.
4. The stub file generated on the server side by running the rmic compiler on
the HelloServer class would need to be copied over to the client side.
5. Since the invocation of Activatable.unexportObject() followed by the
invocation of Activatable.inactive() effectively shuts down the VM that
was spawned for activating the object, if you insert any Java code
immediately after the lines marked (A) or (B), how many of those inserted
statements get executed depends on how the operating system handles the
shutdown. I found it interesting to insert print statements at these locations
to see how many of them would get executed before the activated VM was
actually shut down.
import java.net.InetAddress;
import java.rmi.*;
import java.rmi.activation.*;
ActivationID aid;
Remote server;
import java.rmi.*;
import java.rmi.activation.*;
#! /bin/sh
rmiregistry &
rmid -C-Djava.security.policy=/home/rvl4/a/kak/RMI16.d/policy &
sleep 1
java RegisterHelloServer
import java.rmi.*;
HTTP tunneling is a method that RMI uses to make calls through a local firewall.
To get across firewalls, which disallow regular outbound TCP connections but permit
HTTP through a proxy server, RMI makes use of HTTP tunneling by encapsulating the
RMI calls within an HTTP POST request. The reply too is sent back as HTTP-
encapsulated data.
I would like to see a "minimalist" version of the official Sun Java tutorial on
how to use a MarshalledObject for data persistence in remote object
activation.
Location: http://www.jguru.com/faq/view.jsp?EID=80957
Created: Jun 23, 2000 Modified: 2000-06-23 07:16:10.336
Author: Avi Kak (http://www.jguru.com/guru/viewbio.jsp?EID=26410)
I believe that the educational essence of the otherwise very instructive Sun tutorial
on how to use a MarshalledObject for data persistence can be demonstrated with a
program that is somewhat easier to comprehend by a beginner than the one shown
in the tutorial. My own position is that since remote object activation is fairly
convoluted as it is, to the extent possible one should make an attempt to illustrate
each of its central ideas in isolation from the other ideas.
If you are just beginning with the ideas of data persistence in remote object
activation, the following remarks about the enclosed code should prove helpful:
8. The server object returns to the client the latest contents of the
transactions vector and the client prints out all of the strings thus received
from the server. Therefore, after N client calls to the server, you should see
the client print out N repetitions of the above five strings.
9. You can verify data persistence by entirely shutting down the activation
system on the server side (by killing all its processes) and starting all over. If
the next client call is the Nth call, you will see N repetitions of the above five
strings -- as long as you do not delete the file persistentObjectStore.ser
file in which the latest state of the object is stored.
10. A call from a client will invoke MyPersistentClass's constructor only if it was
not already invoked by a previous call from a client. The constructor will also
be invoked if you shut down the entire activation system by killing all its
processes and starting over (or if the server computer crashes and you start
over). If the MyPersistentClass's constructor is invoked, it will restore the
server object from the file persistentObjectStore.ser file if such a file
exists at all (see statement marked (A) in the code). The file in which the
state of the server object is stored is specified in the statement marked (C) in
the Setup.java program.
11. As shown in the statement marked (B), each time a client invokes the server
object method callServer(), the server object with its changed state is
saved to the disk file persistentObjectStore.ser.
12. Since I used a Solaris machine as a server and an NT machine as a client, for
command line invocations I have a shell file on the server side and a bat file
on the client side.
13. To run this code on your system, you'd obviously have to change the strings
"rvl4.ecn.purdue.edu" and "/home/rvl4/a/kak/RMI18.d/" to the name of your
server machine and the name of your server-side directory, respectively.
14. The stub file generated on the server side by running the rmic compiler on
the MyPersistentClass class would need to be copied over to the client side.
import java.rmi.*;
import java.util.Vector;
import java.io.*;
import java.rmi.*;
import java.rmi.activation.*;
import java.util.Vector;
if ( holder.exists() ) // (A)
this.restoreState();
else {
transactions = new Vector( 1, 1 );
transactions.addElement( "Initializing transaction vector" );
}
}
import java.io.File;
import java.rmi.*;
import java.rmi.activation.*;
import java.util.Properties;
#! /bin/sh
rmiregistry &
rmid -C-Djava.security.policy=/home/rvl4/a/kak/RMI18.d/policy &
sleep 1
java Setup
import java.rmi.*;
import java.util.Vector;
java Client
I don't think it's possible with the RMI classes provided with the JDK (if it is,
someone will correct me), but you could design your system to control this. (I'm sure
we could all come up with multiple ways for solving this design issue.) The first
solution off the top of my head would be the following:
* Create an RMI server manager object whose job it is to keep up with how many
concurrent connections are executing on the object. This could be done in such a
way: (Assume we have the RMIServerManager running and it's a Singleton (one
instance) class.)
...
}
I know this is bare bones, but you get the idea, just build it into the design of your
system.
Why do I always get an "Invalid port Range: 21" exception when running
RMI with a file:// codebase and the security manager properly configured
on WIN32?
Location: http://www.jguru.com/faq/view.jsp?EID=93250
Created: Jul 1, 2000 Modified: 2000-07-06 20:58:07.814
Author: John Zukowski (http://www.jguru.com/guru/viewbio.jsp?EID=7) Question
originally posed by Bernhard Anzeletti
(http://www.jguru.com/guru/viewbio.jsp?EID=10956
The default configuration of the Java policy file does not permit usage of ports under
1024. These are considered privileged ports under UNIX. While you are using a
Windows OS which doesn't have that restriction, the Java limitation is for all
operating systems.
Comments and alternative answers
[Note: My HttpSessions are persistent (disk swap), so if the handle is not serializable
I will have troubles when the HttpSession is restored. ]
Test result:
I have used the handle for locating local and remote EJB. I have no problem about
storing the handle inside the HttpSession and swapping the HttpSession. However if
some problem arise about the swap of the HttpSession, you may could keep the
HttpSession in memory.
Test conditions:
BEA Weblogic 4.5.1 (uses EJB 1.0 and allow keep HttpSessions in memory). Windows
NT 4.0
Observations:
I'm a little surprised about the test since I keep in mind that handles could only be
used for locating local EJB's not remote ones (wrong?).
You can refer to the url below for more info and a...
Author: kishore_k_v k (http://www.jguru.com/guru/viewbio.jsp?EID=202022), Sep
11, 2000
You can refer to the url below for more info and a clear picture on this topic although
i think you know the answers.
http://www.weblogic.com/docs51/classdocs/API_ejb/EJB_design.html#1022000
[Alex: the article isn't available at all, but it can still be found here. Big thanks to
Peter Alzheimer]
Which, if any, of the automatically generated stub & skeleton class files
does one need to include in a JAR file to be used when creating stand-alone
clients? (I would like to create a client-side jar file which contains only the
class files actually needed by the client.)
Location: http://www.jguru.com/faq/view.jsp?EID=105016
Created: Jul 18, 2000 Modified: 2000-08-11 12:14:09.972
Author: Siva Visveswaran (http://www.jguru.com/guru/viewbio.jsp?EID=46210)
Question originally posed by keith hawkins
(http://www.jguru.com/guru/viewbio.jsp?EID=83055
The answer is really not that generic as one may like to believe! Basically what a
client needs to invoke the services of an EJB layer are:
• locate the home interface (using a JNDI SPI) & invoke methods of the bean
instances (over IIOP). Depending on the vendor (e.g. IONA builds JNDI over
CORBA) the actual files will vary. You have to check with your vendor.
• definitions of serializable objects that are returned to client due to network
considerations (instead of object references).
[Can someone please provide examples, for a specific EJB server if need be?]
See also:
• What classes does a client application need to access EJB? (hmm, kind of
redundant, oops :-)
For RMI clients (standalone) all you require is to copy your stub (generated using
rmic) and the remote interface (wherein you define the remotely invokable methods)
to your client directory, or jar it along with the client implementation of your
program. Thus you require 3 things only.. 1)stub 2)remote Interface 3)client
implementation Hope this solves your problem.. Sharad
I am not sure if its possible to post the code, so I suggest you organize yourself this
book or its sample sourcecode (i.e. library, colleagues).
You have to grant the permission via the policy file. This looks like:
java.util.PropertyPermission "*", "read,write"
for using
java.lang.System
public static Properties
getProperties()
public static void
setProperties(Properties props)
or:
for using
java.lang.System
public static String
getProperty(String key)
public static String
getProperty(String key, String def)
You can also override following methods:
checkPropertiesAccess
checkPropertyAccess
Sure, just design it into your system. When the client request comes in, look up the
incoming IP address and check your list of accepted IP's. A similar topic using
discussing limiting the number of connections to an RMI server can be found here:
http://www.jguru.com/jguru/faq/view.jsp?EID=79317.
How can I get to know the number of clients that are connected to a RMI
server at any given time?
Location: http://www.jguru.com/faq/view.jsp?EID=115219
Created: Jul 31, 2000 Modified: 2000-07-31 20:18:49.373
Author: Shaun Childers (http://www.jguru.com/guru/viewbio.jsp?EID=30243)
Question originally posed by karuppanan rameshkumar
(http://www.jguru.com/guru/viewbio.jsp?EID=102591
Design it into your system. When the client request comes in, just keep a tally of the
number of clients you have in your system. When a client leaves, subtract one from
this number. A similar topic using discussing limiting the number of connections to an
RMI server can be found here: http://www.jguru.com/jguru/faq/view.jsp?EID=79317
So the result is that if you synchronized on a remote stub, the synchronization takes
place in the client JVM only. Conversely, if you declare a remote method as
synchronized in the remote object implementation, the synchronization takes place in
the server JVM, which has the effect of synchronizing all client and server access to
the remote object.
Yes, there is some sort of 'hook'. The general strategy is to write your own subclass
of java.net.Socket and java.net.ServerSocket. Next, modify the constructor of your
remote object (the one that extends UnicastRemoteObject) to set a client and a
server socket factory. These factories will be used by the remote object for RMI
communication and thus using the input/output behaviour that was specified in the
socket subclasses.
"Many applications may require that data exchanged between client and server be
encrypted, compressed, or handled in some other fashion. Doing this with RMI is
simple enough, requiring only that you implement your own socket classes and an
RMI socket factory that creates your special sockets. However, overriding the
default socket factory disables RMI's ability to do HTTP tunneling, thereby
preventing access by proxy server users."
Subclassing a Socket allows you to return your wanted stream when calling the
Socket's getInputStream() and getOutputStream() methods:
public class MySocket extends java.net.Socket
{
public MySocket()
{ super();
}
I couldn't think of any way, how to "detect the speed of an rmi socket connection".
Definitely not by provided means. Furthermor, you never know if the current
connection is slow or if the net is simply blocked/slow at the moment.
How can the RMI client do a lookup if it communicates with the outside
world via a proxy server?
Location: http://www.jguru.com/faq/view.jsp?EID=117768
Created: Aug 3, 2000 Modified: 2000-08-03 08:21:44.162
Author: Doug Bell (http://www.jguru.com/guru/viewbio.jsp?EID=113602) Question
originally posed by Sarit Bose (http://www.jguru.com/guru/viewbio.jsp?EID=44426
RMI supports both direct socket connections and connections through a proxy via
HTTP tunneling. Assuming the firewall has an HTTP proxy, a client can connect to an
RMI server outside the firewall. The logic necessary to detect and select the
transmission protocol is contained within the Socket produced by the default
RMISocketFactory.
There are some limitations and configuration issues. See the RMI spec for details.
In general, remote objects are not replaced by their stubs. The remote object
remains on the server and the stub is delivered to the client to act as a proxy for
accessing the remote object. The common bond between the stub and the remote
object is the remote interface that they both implement which allows a stub on a
client machine to operate as if it was the remote object on the client.
There is one place where a remote object is actually replaced by a stub. If a remote
object that has been exported is passed as a parameter to, or returned as the result
from, a remote method call, then the remote object is replaced by its stub. So for
instance, if a remote object returns itself (i.e. this) from a remote method, then
instead of marshalling the remote object and passing it to the caller a stub for the
remote object is returned.
You can add either of the following properties (assuming that you're using a Sun-
based RMI JRE): "-Dsun.rmi.server.exceptionTrace=true" and "-Djava.
rmi.server.logCalls=true".
A client (C) calls a method on a server (S1) that returns a remote reference
to an object running on a second server (S2). If the client makes a call to
this object, does this still generate network traffic involving S1, or is the
connection between C and S2 completely direct?
Location: http://www.jguru.com/faq/view.jsp?EID=121620
Created: Aug 8, 2000 Modified: 2000-08-09 21:03:27.602
Author: Doug Bell (http://www.jguru.com/guru/viewbio.jsp?EID=113602) Question
originally posed by Michael Prescott
(http://www.jguru.com/guru/viewbio.jsp?EID=25013
A remote reference is tied only to the remote server containing the referenced
remote object. Therefore, the connection between C and S2 is completely direct and
S1 is no longer involved in the connection.
Where can I find the official documentation of the Sun Java SDK tools?
Location: http://www.jguru.com/faq/view.jsp?EID=138528
Created: Aug 30, 2000 Modified: 2000-08-30 11:20:52.803
Author: John Mitchell (http://www.jguru.com/guru/viewbio.jsp?EID=4)
You can find the official Sun documentation for all of the tools in the Java 2 SDK
including javac, java, javadoc, appletviewer, jar, jdb, javah, javap, extcheck, rmic,
rmiregistry, rmid, serialver, native2ascii, keytool, jarsigner, policytool, tnameserv,
idlj, and unregbean on the Java 2 SDK Tools and Utilities page.
then run rmid -stop, and restart it. Rinse. Lather. Repeat.
You can make use of the Windows JDK utility javaw to fire-up the Java interpreter as
a separate process and run rmiregistry and your server in the background.
javaw rmiregistry
However, do note that this will preclude you from seeing any of the diagnostic or
error messages that would be printed to the console by default.
Answer is incorrect
Author: David Ben-Yaacov (http://www.jguru.com/guru/viewbio.jsp?EID=18017),
Jun 13, 2001
That answer does not work.
javaw's parameters are the full class name, not the name of an executable program.
For example,
javaw com.mycompany.mypackage.myprogram
not
javaw dir
or
javaw ls
If the RMI client & server are located on the same machine, what is the
overhead of invoking remote method in this situation compared to a local
method call? Will the call go through the entire TCP/IP stack, stub and
skeleton or will it will be treated as a local invocation?
Location: http://www.jguru.com/faq/view.jsp?EID=205093
Created: Sep 13, 2000 Modified: 2000-09-14 15:55:02.848
Author: swarraj kulkarni (http://www.jguru.com/guru/viewbio.jsp?EID=121306)
Question originally posed by Serge Nekoval
(http://www.jguru.com/guru/viewbio.jsp?EID=141561
Even if you have RMI server and Client on your local machine, to work with them in
RMI style, you will have to invoke them as different processes (i.e. with each running
within a separate JVM instance).
This scenario is comparable to running the RMI client and server processes in a
distributed mode (with each running on a separate machine), where the
communication takes place by going through the entire TCP/IP stack, stub and
skeleton. Thus, RMI calls between the client and server running on the same
machine will not be treated as a local invocation. The overhead here is obvious, and
the performance will be relatively poor compared to socket-based communication.
Why is rmic invoked on the implementation class and not on the remote
interface?
Location: http://www.jguru.com/faq/view.jsp?EID=205984
Created: Sep 14, 2000 Modified: 2000-09-14 15:46:53.017
Author: RamaChandra Murthy (http://www.jguru.com/guru/viewbio.jsp?EID=74971)
Question originally posed by Thomas Auinger
(http://www.jguru.com/guru/viewbio.jsp?EID=94950
more details...
Author: Moises Lejter (http://www.jguru.com/guru/viewbio.jsp?EID=775519), Feb
27, 2002
The answer given is accurate, but it could be a little more complete...
The following article has samples for a CORBA/C++ Server, CORBA/C++ Client,
Java-RMI based Server and a Java-RMI based client. With this you can test
interoperability between the Java-RMI and C++/CORBA implementations.
http://www.dur.ac.uk/~dcs0www/ug/DISTSYS/ds1_p3.htm
How can I create and register a custom RMI stub generated dynamically
using the new JDK 1.3 dynamic proxy classes?
Location: http://www.jguru.com/faq/view.jsp?EID=208904
Created: Sep 18, 2000 Modified: 2000-09-21 20:51:19.277
Author: Davanum Srinivas (http://www.jguru.com/guru/viewbio.jsp?EID=2011)
Question originally posed by Stephen Buck
(http://www.jguru.com/guru/viewbio.jsp?EID=2595
There is an excellent package from Rickard Öberg which uses dynamic proxy classes
to eliminate the need for RMIC itself. The package can be downloaded from:
http://www.dreambean.com/download/rickard/SmartWorld-1.2.zip
http://archives.java.sun.com/archives/rmi-users.html
Is there any way to catch the situation where the server side of the RMI
program fails to return to the client (i.e. client calls a method on the server
and while the server is processing, the client machine dies...I want to be
able to catch this on the server side)
Location: http://www.jguru.com/faq/view.jsp?EID=210288
Created: Sep 19, 2000 Modified: 2000-09-21 21:00:07.917
Author: swarraj kulkarni (http://www.jguru.com/guru/viewbio.jsp?EID=121306)
Question originally posed by Jack Handy
(http://www.jguru.com/guru/viewbio.jsp?EID=55924
This can be implemented by using the CallBack mechanism, where the server holds
the reference of the client object. For every call on the remote server using the
object, pass on the client ID (which has information corresponding to the client
machine) as one more parameter to the method. The server executes the method
and before returning the result, can test that the client corresponding to passed
client ID is alive (by using reverse call to the client for example).
A replicated RMI object is one that offers transparent failover or load balancing.
There is nothing that stops an RMI server from making native method calls. The
client doesn't know it is making a request that will eventually be carried out with
native code.
How I can set the maximum number of requests that can be handled by a
multithreaded RMI server(an object which extends UnicastRemoteObject)?
Location: http://www.jguru.com/faq/view.jsp?EID=216377
Created: Sep 26, 2000 Modified: 2000-09-28 22:17:55.087
Author: Benjamin McCartney (http://www.jguru.com/guru/viewbio.jsp?EID=109357)
Question originally posed by Anoop Kumar A
(http://www.jguru.com/guru/viewbio.jsp?EID=12385
My understanding is that the standard RMI does not permit any way for you to limit
this. If you wish to limit the number of requests that your server will handle then you
will have to implement this at the application level.
You could look at other implementations of RMI like Voyager. Some of these offer
advanced features like thread pooling to enhance performance but such features
need to be configure externally.
It is the choice of developer rather than any set design pattern. If the remote server
wants to provide summary information about the cause of failure, then it's better to
have the exception caught at the server side and a concise version passed to the
client. Further in debugging mode, the stack trace does not get passed on to the
stub since it does not implement the Serializable interface. In this case, it is better to
catch the exception at the server and wrap the stack trace within your own exception
class before passing it to the client.
On the other hand, if the developer wants a simple design and does not worry about
the exact details of the exception cause (stack trace), the server can just throw the
exception and the client can catch it.
Is there any limit on the time duration of an RMI call? Does RMI support
timeouts?
Location: http://www.jguru.com/faq/view.jsp?EID=240365
Created: Oct 30, 2000 Modified: 2000-11-03 17:29:35.632
Author: Edward Harned (http://www.jguru.com/guru/viewbio.jsp?EID=240325)
Question originally posed by Nader Said
(http://www.jguru.com/guru/viewbio.jsp?EID=233358
We know of no time limit for an RMI Call. However, consider the following:
When timing a request, the RMI Connection thread cannot time itself. If it gets
caught in a long or never ending loop then it may not be able to break out of the
code when the time expires. Therefore, it is necessary for the RMI Connection thread
to start a new application thread. The RMI Connection thread may time the new
thread and if the time expires the RMI Connection thread informs the calling client
that the request cannot complete.
This seems simple enough. However, there are serious problems with this approach.
For every request there is a new application thread. The VM must create and destroy
every thread. This overhead puts a severe strain on resources. There may come a
time when the VM cannot sustain any more threads and the entire VM becomes
unusable.
[Some developers may put the timing code in the client. Rather than have a
standard timing mechanism on the server, each client application must add
proprietary timing code.]
What happens to the threads that time-out? If there is problem with a resource that
the threads require before completing, then, once again, there may come a time
when the VM cannot sustain any more threads and the entire VM becomes unusable.
[Even with the timing code in the client, the RMI Connection threads still hang.] We
have a commercial product that solves this problem.
Are there any tips or rules for increasing performance of RMI calls?
Location: http://www.jguru.com/faq/view.jsp?EID=241638
Created: Oct 31, 2000 Modified: 2000-11-06 21:44:57.859
Author: Maxim Senin (http://www.jguru.com/guru/viewbio.jsp?EID=21992)
So far I discovered only one rule of thumb: avoid passing objects as parameters or
return values - primitive types serialize much faster than objects because Java
objects are so flat. The only object I was unable to avoid passing as a parameter in
most applications is String.
I'd define an API that uses object IDs, so that clients operate with IDs only, and the
server performs all the work of finding reference to object by ID.
ChatRoom remoteChatRoom;
// ... somehow get reference to chat room
remoteChatRoom.postMessage (message);
I'd use
// when connecting to chat room, get room ID
int CHAT_ROOM_ID = chatServer.getRoomID();
// chat server will take care
// about finding local reference to room
// by object id and somehow post message in it
chatServer.postMessage (CHAT_ROOM_ID, message);
Any better ideas?
Comments and alternative answers
Re: Are there any tips or rules for increasing performance of RMI calls?
Author: Alexander Derazhne (http://www.jguru.com/guru/viewbio.jsp?EID=434414),
Jun 6, 2001
Unfortunatelly, sometimes we have to pass objects. But don't pass _big_ objects -
required time increase mach faster than object size! In one project we have to pass
vector of 16000 complex items (also vectors). It take more than 50m. After splitting it
into 16 slices of 1000 items transfering take only 2m40s.
RE: Are there any tips or rules for increasing performance of RMI calls
Author: James Haiar (http://www.jguru.com/guru/viewbio.jsp?EID=442241), Jun 20,
2001
Using externilizable instead of serializable makes marshalling faster
RMI Servers start a thread that never ends. This is so that the Server is persistent
until manually shut down.
However, you can provide a remote method, shutDown(), for the Remote Server.
This method starts a shutdown thread. The shutdown thread remains waiting for a
notify().
When the Server finishes all clean-up processing it wakes up the shutdown thread.
The shutdown thread, after a two (2) second delay, calls System.exit(0) to end the
Java Virtual Machine. The delay is so that messages from the Server to the initiating
Client complete the journey.
In the RMI CallBack Mechanism the reference of the client is sent to the
server along with the request. Firstly is there any way to store the reference
of the client in the database which can be retrived later to send the
response to that specific client. Secondly, how can the server restrict the
request coming from a specific client, i.e how to get the ip address of the
client from the reference?
Location: http://www.jguru.com/faq/view.jsp?EID=254143
Created: Nov 15, 2000 Modified: 2000-11-18 17:19:42.65
Author: Edward Harned (http://www.jguru.com/guru/viewbio.jsp?EID=240325)
Question originally posed by Makkapati Ramanjaneyulu
(http://www.jguru.com/guru/viewbio.jsp?EID=46923
Firstly:
java.rmi.server.RemoteObject implements Serializable so you can serialize the
reference and save it to a byte array or use toString(), etc. We took the below quote
rrom the RMI-IIOP Programmer's Guide:
"If you are not using the RMI registry for naming services, you have some other way
of bootstrapping your initial remote object reference. For example, your server code
may be using Java serialization to write an RMI object reference to an
ObjectOutputStream and passing this to your client code for deserializing into an RMI
stub."
Secondly:
One way is to have each client pass an identifier. This way if ip addresses change you
would not have to change you Server side.
You can use toString(), as above, and look at the characters. The ip address is in
there, TODAY. However, this does not mean that the ip address will be in there
tomorrow. It also does not mean the ip address is in there for every platform in
every way.
The RMI and JNDI Registries are not the only places one may keep the reference to a
remote object. You can serialize the reference and store it in your own, private
"registry." How you get access to this private registry may involve native code for
each operating system, (this is how the RMI and JNDI Registries work.)
Load balancing has been the subject of many books and articles since
multiprogramming first appeared.
How can I run a single JVM for different classes that are activated by
different activation classes? For example, by default, if I create activatable
two class ActClass1 and ActClass2 and run them I get two JVMs. Is it
possible to run both classes in one JVM?
Location: http://www.jguru.com/faq/view.jsp?EID=260449
Created: Nov 22, 2000 Modified: 2000-11-22 16:56:19.341
Author: Greg Granato (http://www.jguru.com/guru/viewbio.jsp?EID=260445)
Question originally posed by Daniel Lee
(http://www.jguru.com/guru/viewbio.jsp?EID=43238
I believe this is controlled by the ActivationGroup. When you register the class you
are probably doing something like:
You are probably doing this once for each of your classes. The createGroup translates
into a JVM instance. If you were to register both of your classes under the same
ActivationGroupID then they would be served from the same JVM.
How can I increase the maximum number of requests that an RMI server
can handle simultaneously. I am getting connection refused error after 25
request are made simultaneously from 25 threads in a client.
Location: http://www.jguru.com/faq/view.jsp?EID=263554
Created: Nov 27, 2000 Modified: 2000-11-28 10:09:39.221
Author: Edward Harned (http://www.jguru.com/guru/viewbio.jsp?EID=240325)
Question originally posed by Sunil Bansal
(http://www.jguru.com/guru/viewbio.jsp?EID=253824
Without knowing more of the details, you may be running into a temporary condition,
(like a packet storm), where the receiver is overloaded. We use a retry loop for
connection errors.
catch(ConnectException e) {
count--;
}
catch(Exception e) {
// add your code here
break;
}
}
How can I scale an RMI server? For example, how can I spread workload of
RMI server between several server hosts?
Location: http://www.jguru.com/faq/view.jsp?EID=266326
Created: Nov 30, 2000 Modified: 2000-11-30 12:03:58.664
Author: Edward Harned (http://www.jguru.com/guru/viewbio.jsp?EID=240325)
Question originally posed by Maxim Senin
(http://www.jguru.com/guru/viewbio.jsp?EID=21992
What you are looking for is called Load Balancing. Most developers use an
intermediate RMI Server, a Router.
The Router contains the logic to determine which Server should process the request
from a client. There are two basic scenarios:
1. The client contacts the Router and the Router returns the RemoteObject for
the Server,(pass back).
2. The client contacts the Router and the Router passes the request to the
Server, (pass through).
Pass Back:
This resembles the Internet where every "www" request must go to a common
service that passes back the IP address.
Clients may only use the Server RemoteObject one time since it may not be best
able to handle the next request.
Pass Through:
The object the clients pass to the Server must go through the Router. This involves
deserializing the object in the Router and re-serializing the object in the Router to
pass on to the Server.
The object the Server returns to the client must go through the Router. This involves
deserializing the object in the Router and re-serializing the object in the Router to
return to the client
Both these scenarios require extensive analysis and design way, way beyond what
we can provide here.
If the RMI server broadcasts some data to all clients via callbacks, and one
of the clients is in deadlock, how can I timeout the method invocation? Is
there a way to "post-and-forget" method invocation from server to the
client?
Location: http://www.jguru.com/faq/view.jsp?EID=266329
Created: Nov 30, 2000 Modified: 2000-11-30 12:03:10.797
Author: Edward Harned (http://www.jguru.com/guru/viewbio.jsp?EID=240325)
Question originally posed by Maxim Senin
(http://www.jguru.com/guru/viewbio.jsp?EID=21992
You can start a new thread for each Client call back. If the thread does not finish in
the "time you desire", then you know that Client is stalled and should not receive any
more messages.
How to get rid of the hanging thread is another issue involving queue and thread
management.
Is there a simple way to find out if the activation system (i.e. rmid) is
currently running?
Location: http://www.jguru.com/faq/view.jsp?EID=276947
Created: Dec 13, 2000 Modified: 2000-12-18 17:59:38.35
Author: vincent eggen (http://www.jguru.com/guru/viewbio.jsp?EID=111308)
Question originally posed by Steve Kennedy
(http://www.jguru.com/guru/viewbio.jsp?EID=245713
First -- there is always CallBack. By passing the Server the Client "RemoteObject",
the Server knows the ID of the Client.
• The method only returns the TCP address of the host on which the client
resides, not the actual client identification and this method is only available to
pure Java, (not RMI-IIOP or other plug-in), implementations.
• Using a physical address to identify a client is usually not a good idea. The
network may change, machines come and go. This is "hard wiring". When
the location changes, then an administrator must alter all tables. Using a
"soft wiring" method means the client can take its identification with it when it
moves.
Thirdly, the RMI Runtime keeps track of the identification of Clients that have
unmarshalled this Server's RemoteObject. (This has to do with the Distributed
Garbage Collector.) However, API access to this data is not available.
How do I read/write a file from the implementation class of the RMI Server
so that it does not give the AccessControlException?
Location: http://www.jguru.com/faq/view.jsp?EID=282033
Created: Dec 19, 2000 Modified: 2001-01-10 22:37:27.957
Author: Edward Harned (http://www.jguru.com/guru/viewbio.jsp?EID=240325)
Question originally posed by Sameer Bhardwaj
(http://www.jguru.com/guru/viewbio.jsp?EID=216688
This is the security feature of Java. Use a policy file and specify the location on the
command line for the Server: -Djava.security.policy=file:/path_to_policy_file
How can I better handle threading in RMI? How could I have a thread pool
that RMI uses to service clients rather than create a new thread each time?
Is this within the power of the developer, or does it need to be part of the
underlying RMI implementation?
Location: http://www.jguru.com/faq/view.jsp?EID=282035
Created: Dec 19, 2000 Modified: 2000-12-19 19:32:43.709
Author: Edward Harned (http://www.jguru.com/guru/viewbio.jsp?EID=240325)
Question originally posed by Benjamin McCartney
(http://www.jguru.com/guru/viewbio.jsp?EID=109357
Technically, you already have a pool of threads. If your Server handles ten
concurrent requests, then there are ten RMI Connection Threads processing these
requests. As each request finishes, the RMI Connection Threads waits for the next
request "n" seconds. If the next request comes in within this window, then a waiting
RMI Connection Thread handles the request. Otherwise, the RMI Run Time destroys
the RMI Connection Thread and must create a new RMI Connection Thread for the
next request.
As far as we know the wait time, ( "n" seconds), is part of the RMI implementation
and is not alterable by developers. During heavy usage the waiting pool should
suffice.
1. The unrferenced() method is only called when ALL clients no longer hold a
reference to the remote object or when the lease time expires,
(java.rmi.dgc.leaseValue.)
2. The Registries, (RMI/JNDI) are clients. If you register your remote object with
one of these, then your unreferenced() method will never be called.
3. Since this is the purview of the Distributed Garbage Collector, each operating
system may implement this differently.
We keep track of the idle period, that is - the time when no Client has called the
Server. When this idle period reaches a threshold, the application may take some
action, (such as deactivating, etc.) In this way, we are not dependent on any
implementations of DGC and we have much more flexibility.
Where can I find a detailed instructions for the steps to be followed while
using RMI with applets?
Location: http://www.jguru.com/faq/view.jsp?EID=297399
Created: Jan 9, 2001 Modified: 2001-01-15 21:57:07.347
Author: Deepa Lakshminarayanan
(http://www.jguru.com/guru/viewbio.jsp?EID=297130) Question originally posed by
Ann George (http://www.jguru.com/guru/viewbio.jsp?EID=100886
You can find complete details for getting RMI to work with applets, along with
example code at:
http://java.sun.com/j2se/1.3/docs/guide/rmi/getstart.doc.html
For untrusted applets, the registry must be running on the web server from which it
came. The necessary code follows:
String url getCodeBase().getHost();
url = "rmi://" + url + "/service";
Object obj = Naming.lookup(url);
You can then cast the returned object to whatever type you want.
What is rmic?
Location: http://www.jguru.com/faq/view.jsp?EID=302866
Created: Jan 15, 2001 Modified: 2001-01-15 22:05:09.042
Author: Sujatha Sundaram (http://www.jguru.com/guru/viewbio.jsp?EID=253363)
Question originally posed by Sarvotham pai
(http://www.jguru.com/guru/viewbio.jsp?EID=295412
rmic is the Java RMI Stub Compiler. The rmic compiler generates stub and skeleton
class files for remote objects from the names of compiled Java classes that contain
remote object implementations.
A skeleton for a remote object is a server-side entity con- taining a method that
dispatches calls to the remote object implementation.
A stub is a proxy for a remote object that is responsible for forwarding method
invocations on remote objects to the server where the actual remote object
implementation resides. Therefore, a client's reference to a remote object is actually
a reference to a local stub.
An interesting article that talks about Servlets, Applets, and RMI can be found at:
http://developer.java.sun.com/developer/technicalArticles/RMI/rmi/
The activatable object is activated on demand by default. You can have it activated
when the activation daemon starts by setting the restart boolean to true in the
Activation Description. (see the javadoc for the full details)
If the existing CORBA object has its remote interfaces defined originally in CORBA
IDL, then interoperability is not possible. RMI-IIOP applications can interoperate with
other CORBA objects only when their remote interfaces are originally defined as Java
RMI interfaces.
For example, to interoperate between an RMI-IIOP client and a C++ object you
would need to:
What is the cleanest way to design methods of remote objects that may
return null? Normally, I let the method return null, and the code that calls
the method checks for null before using the object that was returned.
Unfortunately, this doesn't work with RMI, as if (obj == null) returns false,
because the obj references a valid stub which references null.
Location: http://www.jguru.com/faq/view.jsp?EID=329179
Created: Feb 14, 2001 Modified: 2001-02-14 14:37:17.383
Author: Edward Harned (http://www.jguru.com/guru/viewbio.jsp?EID=240325)
Question originally posed by Ted B
(http://www.jguru.com/guru/viewbio.jsp?EID=319546
RemoteServer rs ...
String back = null;
back = rs.getName();
// here, when the remote method getName returns null, back is still null
if (back == null)
You would not test "rs" since this is the reference to the Remote Object,
"RemoteServer". Therefore, the "cleanest" way is the most direct way.
If skeleton classes are not required in Java 2, how does the communication
& invocation of remote methods actually take place?
Location: http://www.jguru.com/faq/view.jsp?EID=330333
Created: Feb 15, 2001 Modified: 2001-02-15 16:49:24.58
Author: Suresh Rangan (http://www.jguru.com/guru/viewbio.jsp?EID=308330)
Question originally posed by Ruby India
(http://www.jguru.com/guru/viewbio.jsp?EID=327237
A skeleton is a helper class that is generated for RMI to use. The skeleton
understands how to communicate with the stub across the RMI link. The skeleton
carries on a conversation with the stub; it reads the parameters for the method call
from the link, makes the call to the remote service implementation object, accepts
the return value, and then writes the return value back to the stub.
In the Java 2 SDK implementation of RMI, the new wire protocol has made skeleton
classes obsolete. RMI uses reflection to make the connection to the remote service
object.
On top of TCP/IP, RMI uses a wire level protocol called Java Remote Method Protocol
(JRMP). JRMP is a proprietary, stream-based protocol that is only partially specified is
now in two versions. The first version was released with the JDK 1.1 version of RMI
and required the use of Skeleton classes on the server. The second version was
released with the Java 2 SDK. It has been optimized for performance and does not
require skeleton classes.
Non-remote objects which are passed as parameters must be Serializable and are
passed by copy.
Does RMI have a timeout period within which a remote invocation must
return? Can I change this timeout period programatically for a specific
remote method invocation?
Location: http://www.jguru.com/faq/view.jsp?EID=332524
Created: Feb 18, 2001 Modified: 2001-02-18 21:29:45.207
Author: Edward Harned (http://www.jguru.com/guru/viewbio.jsp?EID=240325)
Question originally posed by Sridhar J
(http://www.jguru.com/guru/viewbio.jsp?EID=322685
Good question. We do not have "the" answer. This question has been here for several
days so we submit the following:
The Java specification leaves implementation details to those who write the JVM.
However, this is dependent on two factors:
As you well know, communication between a remote object and its client is done over
TCP sockets.
The socket is created and bound when you export the object. This is done
automaically if your remote class extends UnicastRemoteObject or you may explicitly
call UnicastRemoteObject.exportObject(...);
The key here is to set the socket timeout value of the client-side socket. Since you can
specify a RMIClientSocketFactory as an argument to the UnicastRemoteObject class,
then you can write a simple wrapper for the java.rmi.server.RMISocketFactory class
that maintains a reference to the sockets created and allows you to change the socket
timeout value programmatically.
socket.setSoTimeout(timeoutMillis);
socket.setSoLinger(false, 0);
return socket;
}
public ServerSocket
createServerSocket(int port) throws IOException {
return new ServerSocket(port);
}
});
Can I pass an Image object from a remote server to the client using RMI?
Location: http://www.jguru.com/faq/view.jsp?EID=332525
Created: Feb 18, 2001 Modified: 2001-02-18 21:31:23.483
Author: Edward Harned (http://www.jguru.com/guru/viewbio.jsp?EID=240325)
Question originally posed by Dnyanesh Bendre
(http://www.jguru.com/guru/viewbio.jsp?EID=274207
For what class? The basic rule for passing objects by RMI is that the class must
implement the java.io.Serializable Interface.
java.awt.image.BufferedImage, no.
javax.swing.ImageIcon, yes.
The Javadoc, (too long to put here), for this interface explains what it is and how to
use it.
RE: Can I pass an Image object from a remote server to the client using RMI?
Author: Vitaliy Rabotnik (http://www.jguru.com/guru/viewbio.jsp?EID=424640),
May 18, 2001
What if, for example you open a DataInputStream on an image file,
read the bytes into a buffer ...
get/set methods
}
What are the legal RMI types refered to by the J2EE Developer's Guide? As
one of the method requirements, it often says, "The arguments and return
type must be legal types for Java RMI."
Location: http://www.jguru.com/faq/view.jsp?EID=349856
Created: Mar 12, 2001 Modified: 2001-03-13 11:38:35.457
Author: Ashley Tate (http://www.jguru.com/guru/viewbio.jsp?EID=349855) Question
originally posed by Randall Minter
(http://www.jguru.com/guru/viewbio.jsp?EID=116341
A legal value type for RMI is an object that implements the java.io.Serializable
interface and is, in fact, serializable (An object that implements the Serializable
interface will not actually be serializable if the classes of one or more of its member
variables are non-serializable).
For a more detailed explanation of legal RMI types, read section 2.6 of the RMI
specification at: http://java.sun.com/j2se/1.3/docs/guide/rmi/spec/rmiTOC.html
Is there a way to reuse threads that are used to handle... Is there a way to
reuse threads that are used to handle incoming requests in RMI? I have
read that there are application servers that will do this, but do not know of
any. Are there any that do this, and is it possible to use standard RMI
classes that come with the JDK 1.x to set up RMI to resuse incoming
requests.
Location: http://www.jguru.com/faq/view.jsp?EID=386346
Created: Mar 24, 2001
Author: Edward Harned (http://www.jguru.com/guru/viewbio.jsp?EID=240325)
Question originally posed by Mark Webb
(http://www.jguru.com/guru/viewbio.jsp?EID=80178
Re: Is there a way to reuse threads that are used to handle... Since JDK1.1, RMI
reuses the RMI-Connection thread that processes the incoming request. There is a
timeout value for this thread, (we do not know whether this value is adjustable). If a
new request does comes in within this value, than the thread processes the request.
If no new request comes in within this value, then the thread is distroyed.
How can I start an RMI server on demand? How can I start an RMI server
on demand?
Location: http://www.jguru.com/faq/view.jsp?EID=386349
Created: Mar 24, 2001
Author: Mikael Jakobsson (http://www.jguru.com/guru/viewbio.jsp?EID=41777)
Question originally posed by Jawahar Pandian
(http://www.jguru.com/guru/viewbio.jsp?EID=47746
Re: How can I start an RMI server on demand? The Java RMI activation API
(java.rmi.activation) enables you to make your RMI objects to activate on demand. It
is IMHO not the most pleasant API to work with, and you will need to run the rmid
daemon on the server that will handle the activation for you.
What you can pass are the data fields, (String, int, etc.), within the database after a
Select.
So, in a GUI Client you can pass the parameters for a Select to the RMI Server. The
Server can issue the SQL statements saving the fields in an object. The Server
returns that object to the Client that displays the data.
look at rmijdbc
Author: Gabriel Artaud (http://www.jguru.com/guru/viewbio.jsp?EID=9114), May
22, 2001
What you could do is create a RemoteConnection (which extends
UnicastRemoteObject)
http://www.objectweb.org/RmiJdbc/RmiJdbcHomePage.htm
The only problem of rmijdbc is the performance. You may want to create a way to
retrieve a serializable equivalent of a ResultSet in bulk instead of looping remotely
Can I use the RMI registry for the commercial purpose without having to
pay Sun royalties or licensing fees for the same? My guess is I don't since it
is a part of the JRE, but what is the definitive answer on this?
Location: http://www.jguru.com/faq/view.jsp?EID=396595
Created: Apr 5, 2001
Author: Luigi Viggiano (http://www.jguru.com/guru/viewbio.jsp?EID=101985)
Question originally posed by Shalini Aggarwal
(http://www.jguru.com/guru/viewbio.jsp?EID=385559
RMI is a part of Java Core APIs, and it is subject to the same license as JRE/JSDK.
i.e. you have not to pay any royalty, it's free.
When you download the JRE or JSDK you are presented a license that is applicable to
all the downloaded software, including RMI since it is a part of the JSDK/JRE
archives.
All the core APIs and standard extensions (javax.* packages) are free for use within
your products.
RE:
Author: Vitaliy Rabotnik (http://www.jguru.com/guru/viewbio.jsp?EID=424640),
May 18, 2001
My application works fine as it is, but I need to store my client source code in a
signed jar so that I could grant permissions (such as io) for the applet on the client
side. Problem is that I have to jar and sign the code on the server side. If I do so, I get
exactly same above mentioned exception ... and your solution did not help a bit, it still
gives me the same exception ...
Simple solution
Author: Jan Rovner (http://www.jguru.com/guru/viewbio.jsp?EID=740379), Jan 30,
2002
For Win users:
If you have CLASSPATH set to .;xxx;yyy;zzz just start rmiregistry from the directory
where you have server object (to make . work for both rmiregistry and your server
object)
Similar
Author: Nefarious Burrito (http://www.jguru.com/guru/viewbio.jsp?EID=1197988),
Sep 8, 2004
I had the exact same problem. In my case, I was attempting to run the server class
within a jar file: java -jar /path/to/jar/rmiserver.jar With the manifest specifying which
class to run. After much searching, I finally decided to explode the jar and call the
class file directly. That solved my problem. Also, I made sure to run the rmiregistry
contained in sun's jdk and not the one which appears to ship with RedHat linux.
Answer by Edward Harned Re: about rmi callback See the jGuru example at Sun's
JDC:
http://developer.java.sun.com/developer/onlineTraining/rmi/exercises/RMICallback/in
dex.html
How can I start rmid in the background under win32? I found that javaw
sun.rmi.registry.RegistryImpl does it for rmiregistry. Is there something
like this for rmid? If I use "start rmid", I get a dos console all the time.
Location: http://www.jguru.com/faq/view.jsp?EID=407579
Created: Apr 21, 2001
Author: Govind Seshadri (http://www.jguru.com/guru/viewbio.jsp?EID=14) Question
originally posed by Victor Gomez
(http://www.jguru.com/guru/viewbio.jsp?EID=349972
RMI doesn't work in Internet Explorer because Microsoft decided not to support it in
its attempt to ruin Java. They did put a patch file somewhere on their site that you
can download and install, after which your Internet Explorer will support RMI, but
that doesn't help much if you have an applet and you want all your visitors to use it
(since they'd all have to download that patch, which is buried somewhere deep in a
hard to find place on Microsoft's site. This was done on purpose [which became clear
after the Sun vs. Microsoft trial], in a further attempt to ruin Java).
I'm not sure as to why RMI wouldn't work on Netscape though.. i think it should work
on there, but there might be some other reason for it. It might be that you have to
change the security settings in there. Actually, i think if you load the applet locally
(instead of over the network), it does work.
Probably the best solution for you would be to use Sun's Java plug-in. That way, you
don't have to deal with Microsoft anymore, and you can even use Swing and other
Java2 stuff in your applets. It's quite a big download for the average user (about
5MB if i'm not mistaken), but still a lot easier for end-users to install than the
Microsoft RMI patch. Obviously, you can also change your applet so it doesn't need
RMI anymore.
how do you configure so that applet dont need RMI anymore ????
Author: sam pitroda (http://www.jguru.com/guru/viewbio.jsp?EID=476938), Aug 21,
2001
how do you configure so that applet dont need RMI anymore ???? If possible, also let
me know how to configure IE to use Sun's plug-in
What is RMI?
Location: http://www.jguru.com/faq/view.jsp?EID=411942
Created: Apr 28, 2001
Author: Luigi Viggiano (http://www.jguru.com/guru/viewbio.jsp?EID=101985)
Question originally posed by John Zukowski PREMIUM
(http://www.jguru.com/guru/viewbio.jsp?EID=7
RMI stands for Remote Method Invocation and is a Network Layer to let a client
application to invoke methods of objects located on a remote server.
The word "RMI" is not specific to the Java language: the RMI concept is not recent
and has been implemented in many other languages. RMI can be considered the
object orientation counterpart of Remote Procedure Call (RPC).
Speaking in a Java context we should specify Java RMI is a protocol that enables a
remote object to be used just as it would on a local machine.
I'm afraid the answer to your question is no. rmiregistry must be running on the
same computer than the RMI server
Then pass this file to the rmiregistry upon startup like this:
rmiregistry -J-Djava.security.policy=<filename>
Then try to bind the remote object again. If this works, the next step is to find
out the exact permissions needed to allow binding of remote objects because
it's not very secure to have your rmiregistry running with all permissions.
Hope this helps!
Re: Re: ***URGENT *** Re: rmiregistry can be on any local server!
Author: Ramesh Vudatala
(http://www.jguru.com/guru/viewbio.jsp?EID=446443), Nov 6, 2001
Hi Pual, thanks for the response. I was tried that, and even then it seemed to
give me the same problem. I tried it out on my Win 2000(Professional) as
the Rmi Registry Server with the same command given by you and was
trying to bind from another system, it did not work. Tried the same on the
linux box, it did not work. Am i missing something here or how do we do
about from here. Please see if you can help me on this. or is it the file name
and its path which has the problem.
Re: Re: Re: ***URGENT *** Re: rmiregistry can be on any local
server!
Author: Paul Gier
(http://www.jguru.com/guru/viewbio.jsp?EID=349687), Nov 7, 2001
I tried it out too, and got the same error message you did. Unfortunately,
I think that my original statement was wrong. Maybe they did allow this
functionality in an earlier version of the rmiregistry. But now there does
not seem to be a way to do a remote bind() to the rmiregistry.
Check out the RMI example which is part of the Sun JSSE sample code.
I need to generate a GUID and have seen suggestions about using an RMI
server but nothing about how to actually generate the GUID itself.
Location: http://www.jguru.com/faq/view.jsp?EID=429779
Created: May 28, 2001
Author: JIA Java Italian Association
(http://www.jguru.com/guru/viewbio.jsp?EID=414973) Question originally posed by
ewan harrow (http://www.jguru.com/guru/viewbio.jsp?EID=316131
I'm not sure you can generate a GUID without writing native code to get the network
card number or ethernet address.
Say I take some class file: how can I know if it is a stub or a plain class file?
Do not tell me by file name. I need a technical answer that is made on the
basis of the content of the binary file.
Location: http://www.jguru.com/faq/view.jsp?EID=429781
Created: May 28, 2001
Author: Luigi Viggiano (http://www.jguru.com/guru/viewbio.jsp?EID=101985)
Question originally posed by Mahjoub Langar
(http://www.jguru.com/guru/viewbio.jsp?EID=421987
Is it possible for a client to send an event to an RMI object, and vice versa?
Location: http://www.jguru.com/faq/view.jsp?EID=429822
Created: May 28, 2001
Author: Gabriel Artaud (http://www.jguru.com/guru/viewbio.jsp?EID=9114)
Question originally posed by John Kavanagh
(http://www.jguru.com/guru/viewbio.jsp?EID=246505
You can also include remote references in your event (ie references to
UnicastRemoteObjects)
Where can I learn (more) about CORBA (Common Object Request Broker
Architecture)?
Location: http://www.jguru.com/faq/view.jsp?EID=431188
Created: May 30, 2001
Author: John Mitchell (http://www.jguru.com/guru/viewbio.jsp?EID=4)
Where can I learn (more) about Java's support for developing multi-
threaded programs?
Location: http://www.jguru.com/faq/view.jsp?EID=431248
Created: May 30, 2001
Author: John Mitchell (http://www.jguru.com/guru/viewbio.jsp?EID=4)
Where can I learn (more) about Java's support for transaction processing?
Location: http://www.jguru.com/faq/view.jsp?EID=431948
Created: May 31, 2001
Author: John Mitchell (http://www.jguru.com/guru/viewbio.jsp?EID=4)
Check out the jGuru Transactions FAQ.
Where can I learn (more) about Sun's peer to peer, "Project JXTA"?
Location: http://www.jguru.com/faq/view.jsp?EID=431963
Created: May 31, 2001
Author: John Mitchell (http://www.jguru.com/guru/viewbio.jsp?EID=4)
Will multiple Lan cards cause problems using rmi? If a host has two or more
network cards (only one of which is Internet-enabled), how does RMI know
which IP address to use? There seems to be a problem when such a client
registers with an RMI service, and has a client-side callback method invoked
by the server.
Location: http://www.jguru.com/faq/view.jsp?EID=447248
Created: Jun 28, 2001
Author: Chris Arrowood (http://www.jguru.com/guru/viewbio.jsp?EID=443590)
Question originally posed by Andy Ho
(http://www.jguru.com/guru/viewbio.jsp?EID=419443
Possibly.
Even if the RMI Registry is started running on the fully qualified domain name that
you have chosen, the RMI objects may have the local unqualified name embedded in
them.
Location: http://www.jguru.com/faq/view.jsp?EID=463464
Created: Jul 27, 2001
Author: srinath mandalapu (http://www.jguru.com/guru/viewbio.jsp?EID=430437)
Question originally posed by Sri Kundurs
(http://www.jguru.com/guru/viewbio.jsp?EID=451232
Just declare this method (changes the static variable of RMI server) like any other
remote method in the remote interface supported by RMI server and implement this
method in RMI Server implementation (Remote object implementation). This method
must be synchronized. (RMI runtime may service remote client requests on a remote
object concurrently in multiple threads)
What is the meaning of marshalling and unmarshalling? Why is it done?
Location: http://www.jguru.com/faq/view.jsp?EID=463929
Created: Jul 28, 2001
Author: Dermot Hennessy (http://www.jguru.com/guru/viewbio.jsp?EID=390903)
Question originally posed by viswabharathy kunapuli
(http://www.jguru.com/guru/viewbio.jsp?EID=440534
is marshaling/unmarshaling secured ?
Author: sam pitroda (http://www.jguru.com/guru/viewbio.jsp?EID=476938), Aug 21,
2001
do I need to do something else to make object over RMI secured ? ( like encryption ?)
Do RMI clients always work on one single object instance of RMI server
class? Suppose I have a rmi server class:
class S {
...
public void changeDatabase(){
change a database
}
...
}
Than I get a instance of class S and bind it to rmiregistry:
S ss=new S();
Naming.rebind("//S/S", ss); .
Now I have two rmi client A and B. Both get a reference by:
Naming.lookup("//S/S"); and then call method changeDatabase().
Therefore, both Clients A and B run in separate threads. If you have private fields
within your Server Class, S, then you must ensure thread synchronization.
Is there a way to control the ports opened by an RMI server while accepting
connections from a client. I see that I can control the port that an RMI
server listens on while exporting the server object using
UnicastRemoteObject.exportObject. However, when the client connects to
the server, I see different ports being used between the server and the
client when the server accepts a connection from the client.
I am wondering if I can give a range of ports that the RMI server can use
while accepting connections from a client.
Location: http://www.jguru.com/faq/view.jsp?EID=463939
Created: Jul 28, 2001
Author: srinath mandalapu (http://www.jguru.com/guru/viewbio.jsp?EID=430437)
Question originally posed by Ganesh Vaideeswaran
(http://www.jguru.com/guru/viewbio.jsp?EID=450195
I don't think you can control the value of the port returned by the accept call on
server side runtime. This port is determined by the OS at runtime depending upon
the availbility of the port. Atleaset on the client side, you can bind the socket to a
particular local port before making a connection to the remote server in normal
socket programming. But in RMI, RMI reference layer manages connection
management.
Comments and alternative answers
Oracle 8.1.7, Windows and Linux clients running JRE 1.2.2_008, RMI server
running on Linux or Windows NT with JRE 1.2.2_008.
The RMI server uses thin JDBC to communicate with the DB. The RMI server
creates a new impl-object for each client request.
Question three: When we changed the JRE on the server to 1.3.1 we haven't
been able to reproduce the error. Is there a significant difference between
1.2.2 and 1.3.1 in this case?
Location: http://www.jguru.com/faq/view.jsp?EID=463940
Created: Jul 28, 2001
Author: Pontus Strand (http://www.jguru.com/guru/viewbio.jsp?EID=249440)
Question originally posed by Fredrik Duprez
(http://www.jguru.com/guru/viewbio.jsp?EID=449614
The problem has now been solved. It was caused by a bug in Oracle's thin JDBC
client version 8.1.6. So the answers are as follows:
Q2: This bug seems to be fixed in version 8.1.7, at least we haven't been able to
reproduce the problem.
Q3: We still don't know why it worked using JRE 1.3.1 but we think it is because it is
faster and we therefore got some extra time before the EmptyStackException occurs
and we didn't use enough clients to have any problems.
We probably would have found the reason for this much earlier if we had caught the
exception on the server instead of on the client. Oh well, you learn by your mistakes
:-)
I have a Java app which uses RMI calls on bound interfaces to create
remoteable objects. This works fine. I call my create object method on an
interface in the RMIRegistry created with Naming.Rebind, and the created
object is also derived from UnicastRemoteObject so it's interface can be
used directly by the client.
Now, I want to use SSL, so I created server and client socket factories and
in the constructors for all objects derived from UnicastRemoteObject, I call:
Is there an easy way for me to exchange XML objects between the RMI
client and server?
Location: http://www.jguru.com/faq/view.jsp?EID=477578
Created: Aug 15, 2001
Author: Bozidar Dangubic (http://www.jguru.com/guru/viewbio.jsp?EID=433955)
Question originally posed by sayeed sami
(http://www.jguru.com/guru/viewbio.jsp?EID=466799
Are there any guidelines as to when I should use RMI and when I should
prefer plain old socket connections?
What are the advantages/disadvantages of each of these technologies ?
Location: http://www.jguru.com/faq/view.jsp?EID=479169
Created: Aug 18, 2001
Author: Govind Seshadri (http://www.jguru.com/guru/viewbio.jsp?EID=14) Question
originally posed by Matthias Suter
(http://www.jguru.com/guru/viewbio.jsp?EID=477124
RMI elevates network programming to a much higher plane. With RMI, Java objects
can easily invoke the methods of remote objects as if they were locally available. The
amazing part is that the remote objects may be under the jurisdiction of an entirely
different JVM, running on a different host halfway around the world! Also, since you
interact with an RMI object much like a local object, remote methods can send and
receive just about any valid Java object without having to worry about flattening it
out to a serial data stream. RMI automatically provides you that feature by utilizing
the underlying Object Serialization mechanism. The communication between the RMI
client and server itself is facilitated by the Java Remote Method Protocol (JRMP) or
Internet Inter-Orb Protocol (IIOP).
RMI is especially useful for deployment as a multi-tier bridging mechanism, and can
serve as an effective "glue" for integrating other enterprise Java technologies like
JDBC and JNI. RMI remote objects serving as wrappers to database and legacy
system integration code are also highly scalable due to the inherently distributed
nature of the technology itself.
Soap (Simple Object Access Protocol) and RMI are entirely different technologies.
RMI is Java-centric, whereas SOAP, which uses XML, is language independent.
However there are some similarities. SOAP, like RMI, allows you to make an RPC on
another machine over HTTP or SMTP. Soap works on the request/response model of
making remote procedure calls. The client program forms a request which consists of
a valid SOAP XML document and sends it over HTTP or SMTP to a server. The server
picks up the SOAP request, parses and validates it, invokes the requested method
with any supplied parameters, forms a valid SOAP XML response and sends it back
over HTTP or SMTP. For a good paper comparing SOAP with RMI, see: A closer look
at SOAP, RPC, and RMI
A smart proxy is a class, instantiated in the client VM, that holds onto a remote
object reference. It implements the object's remote interface and typically forwards
most of the calls on the interface to the remote object, just like an RMI stub.
However, a smart proxy is more useful than the RMI stub in that you can change the
behavior of the remote interface to do more than forward calls to the remote object.
For instance, a smart proxy can locally cache state from the remote object to avoid
the network overhead on every method call.
For more details, see the excellent Javaworld article by Jeff Wilson, Get smart with
proxies and RMI
I am using RMI, where the client is in Windows 2000 and the server is in
Linux. I have an object database at the RMI server for storing objects. The
RMI client is available to any application that needs to store objects in the
object database. When I store a class it gives a
ClassNotFoundException:ClassName(no security manager: RMI class loader
disabled) at the client. The ClassName is the object that has to be stored.
The ClassName is in the CLASSPATH of the client. The RMI client developed
by me is supplied in a jar file.
But when I put the ClassName at the server end, i.e. explicity store the
ClassName.class file in the server, it works. The hitch is that my RMI client
will be used by many application to store objects in the object database and
I can't put each object what they store in the server side, physically. Is
there any way to overcome this?
Location: http://www.jguru.com/faq/view.jsp?EID=502971
Created: Sep 24, 2001
Author: Christopher Schultz (http://www.jguru.com/guru/viewbio.jsp?EID=138382)
Question originally posed by Brijesh Kumar
(http://www.jguru.com/guru/viewbio.jsp?EID=320017
When you push/pull objects over RMI, the RMI mechanish doesn't send then class file
with the object - it just serializes it, which includes nothing but the data.
When the server tries to de-serialize the object, it must have the class definition.
That's the reason for the ClassNotFoundException that you're getting, and why it
clears up when the server has that class file.
• Try to use built-in types for all the objects that you are sending over RMI (like
Vector, Hashtable, etc.). Then, you don't have to worry about the clases being
there.
• Have a central repository where all the class files can be found, regardless of
the client. Clients will have to send their class files to that central repository
before using your RMI server.
• Have each client bind itself to a local socket, turning the client into a class file
server. Have the server turn around and connect to the client to download the
class file.
• Ditch RMI altogether. This is usually hard to do, and still requires you to figure
out how to represent your objects without using their original class
definitions.
dynamic class dl
Author: Alex Field (http://www.jguru.com/guru/viewbio.jsp?EID=818963), Mar 31,
2002
one easy way to solve this problem is to have the client set the
java.rmi.server.codebase system property. then the server can download client class
files from the codebase if it cant find them locally because the client will annotate the
codebase to all objects it sends. this is what i did for a program i am working on
which will serve any client which extends the remote interface provided. hope that is
helpful (and correct!) Alex
Is there any difference between JRMP (Java Remote Method Protocol) and
RMI?
Location: http://www.jguru.com/faq/view.jsp?EID=502975
Created: Sep 24, 2001
Author: Alessandro A. Garbagnati
(http://www.jguru.com/guru/viewbio.jsp?EID=32727) Question originally posed by
Luigi Viggiano PREMIUM (http://www.jguru.com/guru/viewbio.jsp?EID=101985
I hope this will clarify the concepts and it will answer your question:
Java RMI is just a set of APIs and a model for remote objects for building distributed
applications. The original version of RMI uses a combination of Java serialization and
the Java Remote Method Protocol (JRMP) to turn local method invocations into
remote method invocations.
JRMP is one transport protocol that is used by RMI to transfer data across the
network. Another example of a transport protocol used by RMI is IIOP (Internet
Inter-ORB Protocol).
Is RMI protocol and JRMP protocol two different names for the same protocol or
these are two different protcols ?
ie in other words one of the way to invoke remote object is rmi://host/object and the
questions is that is there any thing like jrmp://host/object ?
On the server side the key pairs can be loaded from disk, so no sweat. The
JSSE example would work. But is there a way to later access the public-key
that was used by the client to set up the secure communication. I want to
use it for further authentication, e.g. compare it to a presented X.509
certificate.
Location: http://www.jguru.com/faq/view.jsp?EID=503552
Created: Sep 25, 2001
Author: Sandy McPherson (http://www.jguru.com/guru/viewbio.jsp?EID=455365)
Question originally posed by Markus Lorch
(http://www.jguru.com/guru/viewbio.jsp?EID=488125
I am not exactly sure of why you would want to pass the key pair to the client, but I
guess your situation must be similar to my own. I have a client callback object which
is using SSL, so to create the server socket for this object I need a KeyStore. As the
client is loaded via Java Web Start I don't want to interfere with the plug and play by
requiring the client's user to configure keystores and truststores.
Currently I am requesting a KeyStore from the client using an https URL connection
to the server which opens a keystore file in my webstart server and loads it into the
client.
The reason for this clunky inelegant solution is the current server interface expects
the client object as a parameter of the login/authorization method.
What I need to do is to make this a four phase operation: first authorize the client
via a login; then request a Keystore object from the server (storing this as a
transient object in the client); create the callback object using this Keystore as the
source of the server certificate; and finally register the callback object with the
server.
Using this method I believe you could use randomly generated certificates to send to
your clients and add these on the fly to the servers (transient)truststore, which
means that you don't have to hand out any sensitive data, but as I haven't
implemented this yet I will reserve judgement.....
I reckon this approach is as secure as I can make it, but I would be interested to
receive any commments.
Yes, with J2SE 1.4, you can now log client-side remote calls and exceptions of an
RMI client by setting the system property sun.rmi.client.logCalls=true when starting
up your client. You can also now control the granularity of the logging mechanism
through additional properties. For details, see
http://java.sun.com/j2se/1.4/docs/guide/rmi/logging.html
Is it true that I cannot send data greater than 64K between an RMI client
and server?
Location: http://www.jguru.com/faq/view.jsp?EID=505569
Created: Sep 27, 2001
Author: Govind Seshadri (http://www.jguru.com/guru/viewbio.jsp?EID=14)
Yes, that's true only with RMI systems prior to JDK 1.3, where you cannot serialize a
string greater than 64k. You would have a java.io.UTFDataFormatException thrown if
you tried. However, since the serialization protocol has been enhanced with JDK 1.3,
you should now be able to serialize strings greater than 64K.
However, do keep mind that for this to work, both the client and server JVMs need to
be JDK 1.3 compliant. Otherwise, if your, say, JDK 1.2-compliant RMI server tried to
read serialized data greater than 64K sent by a JDK 1.3-compliant RMI client, the
server would throw a java.io.StreamCorruptedException.
Is it true that I cannot send data greater than 64K between an RMI client and
server?
Author: Amit Kushwaha (http://www.jguru.com/guru/viewbio.jsp?EID=738215), Jan
30, 2002
Hi,
Is there any maximum upper limit for String datatypes ? Can we send data > 64KB
that are not String datatypes. For example: in a Vector. Is there any size limitation
when you use RMI for transferring files.
Regards,
Amit
Re: Is it true that I cannot send data greater than 64K between an RMI client
and server?
Author: Ashwath Krishnamurthy
(http://www.jguru.com/guru/viewbio.jsp?EID=742974), Feb 1, 2002
I am using JDK 1.1.8 and it is found that it can send data which is larger than 64K.
I am using String datatypes here. But the the performance of the system is very
slow. Is there anyway I can improve the performance ?
For some Swing & AWT related classes, there are workarounds such as
[implementations of] ListModel which can be "disconnected" from any reference to a
JList and then passed to Remote objects.
Is there any way by which I can force RMI invocations to always tunnel via
HTTP?
Location: http://www.jguru.com/faq/view.jsp?EID=525738
Created: Oct 20, 2001
Author: Christoph Dittberner (http://www.jguru.com/guru/viewbio.jsp?EID=507902)
Question originally posed by Neeliagari Sreedhar
(http://www.jguru.com/guru/viewbio.jsp?EID=507745
Firstly, you need to configure the call forwarder program running at a specific url
(i.e./cgi-bin/java-rmi.cgi). To force http-tunneling you have to create a
sun.rmi.transport.proxy.RMIHttpToCGISocketFactory as your default
ClientSocketFactory and set it as
RMISocketFactory.setSocketFactory(new
sun.rmi.transport.proxy.RMIHttpToCGISocketFactory());
After that all RMI calls are encapuslated via a HTTP POST request and forwarded to
the CGI program java-rmi.cgi which in turn "unwraps" the RMI call and forwards it to
the appropriate remote object making the remote invocation.
Comments and alternative answers
Where is java-rmi.cgi
Author: David Gradwell (http://www.jguru.com/guru/viewbio.jsp?EID=1093723),
Jun 13, 2003
After installing j2sdk 1.4.1_01 and jwsdp-1.2 with Tomcat and using both
successfully (j2sdk for years !) I wanted to implement RMI tunnelling over http.
However, the java-rmi.cgi does not seem to be installed anywhere. Where should I
find it ? Where can I get a copy ?
java.lang.ClassCastException: MyServerImpl_Stub
Here's how I finally solved this. I took the compiled RMI STUB and SKEL files from
the server and replaced the corresponding files on the client machine with them.
Then I re-ran the client, and the problem vanished!
Interesing, this. Same code, same java version, the only thing that's different is that
the server is Solaris 8, and the client is Win 2000.
on ClassCastException
Author: vaidehi saheba (http://www.jguru.com/guru/viewbio.jsp?EID=1241829), Apr
30, 2005
I have the same problem but only when i am trying to invoke two rmi methods from
the same machine. That means i am trying to invoke remote method on server side by
object of interface object. but when i am running with inly one method invocation
then program is runnung successfully but it gives me Exception ClassCastException
when i am trying two remote method invocation simulteneously from the same
machine. i want that porblem's solution.
The most likely reason is that some of the of the classes may have been modified
and recompiled while the RMI application was still running. You might want to restart
the client, server and rmiregistry and see if it clears things.
It is not mandatory to set a security manager for the use of Java/RMI. The reason to
do this is so that the Java/RMI client can handle serialized objects for which the client
does not have a corresponding class file in its local CLASSPATH. If the security
manager is set to the RMISecurityManager, the client can download and instantiate
class files from the Java/RMI server. This mechanism is actually fairly important to
Java/RMI, as it allows the server to generate subclasses for any Serializable object
and provide the code to handle these subclasses to the client.
It is entirely possible to use Java/RMI without setting the security manager, as long
as the client has access to definitions for all objects that might be returned.
Java/RMI's ability to handle the passing of any object at any time using Serialization
and class file download is possible only because the JVM provides a portable and
secure environment for passing around Java byte codes that form the Java
executable from which Java objects can be reconstructed at run-time, if required.
See http://www.execpc.com/~gopalan/misc/compare.html for more details.
Omar,
In few words, "marshalling" refers to the process of converting the data or the
objects inbto a byte-stream, and "unmarshalling" is the reverse process of
converting the byte-stream beack to their original data or object. The conversion is
achieved through "serialization".
What is the case for RMI? I used to do RMI before the EJB era. Can we not
do everything we want to with RMI probably with a stateless session bean?
Why would one use RMI instead of a stateless session bean? Can someone
tell me the advantages, disadvantages etc of both approaches ? Is there any
difference as far as performance is concerned?
Location: http://www.jguru.com/faq/view.jsp?EID=568006
Created: Nov 30, 2001
Author: Mikael Jakobsson (http://www.jguru.com/guru/viewbio.jsp?EID=41777)
Question originally posed by Sashi Reddy
(http://www.jguru.com/guru/viewbio.jsp?EID=395494
EJBs are (as I am sure you are aware) a framework for distributed components,
handling transactions and object pooling and more.
RMI is used in this framework as the mechanism for object distribution.
An EJB application server adds more to distributed components than RMI does. The
application server will handle transactions, object pooling, database connection
pooling and more. This extra functionality comes at a price, performance-wise, since
there are simply more things to check and handle compared to plain RMI where no
such functionality exists.
Therefore, when it comes to comparing performance, EJBs can only be slower than a
similar construction using RMI directly, due to the overhead introduced by the
application server.
A: That depends on what your priorities are. There are at least two ways to look at
this:
I think that there is no "correct answer" to this issue, but I hope the above has
added some input in the debate on where and when to use what technology.
EJB vs RMI
Author: Santosh Kumar (http://www.jguru.com/guru/viewbio.jsp?EID=1080478), Apr
30, 2003
EJB makes the work for programmer easy as application servers gives some services
to the components such as Pooling , Security & Transaction. As Application server
comes into picture its adds up the Cost and Overhead. The decision to go for
EJB/RMI Frame Work/Socket Programming should be based on requirement and
accordingly programmer/architect takes the decision.
Background Servers
Author: Rajarshi Mukherjee (http://www.jguru.com/guru/viewbio.jsp?EID=1160292),
Apr 5, 2004
When you need a Server which will run in background doing some task as
periodically apart from serving clients (like Scheduler), then you have to go for RMI
Solution. I am not aware of any situation, where any Bean (Stateless,Stateful) bean
can run forever in the background regardless of Client connecting.
I made some changes to my remote interface and recompiled the server.
Now, I am getting an :
"java.rmi.UnmarshalException: error unmarshalling arguments; " Why?
Location: http://www.jguru.com/faq/view.jsp?EID=568019
Created: Nov 30, 2001
Author: ryan wexler (http://www.jguru.com/guru/viewbio.jsp?EID=433624)
Question originally posed by Asif Akhtar
(http://www.jguru.com/guru/viewbio.jsp?EID=546111
You need to run rmic and recompile those stubs and skeletons every time you
add/delete/modify a method within your remote interface.
Comments and alternative answers
Each RMI method increments a counter of times used in persistent storage. That is --
not a field within the _impl Class.
We have a daemon thread that runs every n-minutes. It looks at each RMI method
counter to see whether each counter is greater than the last time the thread ran. If
the time is one minute and method X counter is 1000 greater than when last the
thread ran, then method X is being used 1000 times per minute. Is this heavy or
light? It depends on the application.
When no method counters are greater than the last time the thread ran, then we call
inactivate().
If you pointers on using persistent storage, hop on over to developerWorks and read
the RMI Server Framework article:
http://www-106.ibm.com/developerworks/java/library/j-rmiframe/
I tried to use System.gc() after setting some objects to null, but with no
luck. Is there any way to close the present server and create a new instance
before the method returns?
Location: http://www.jguru.com/faq/view.jsp?EID=568091
Created: Nov 30, 2001
Author: Edward Harned (http://www.jguru.com/guru/viewbio.jsp?EID=240325)
Question originally posed by Panos Koup
(http://www.jguru.com/guru/viewbio.jsp?EID=388091
If the threads you created have a reference to the objects used to save data, then
those object will never be garbage collected.
If the threads you created explicitly set their reference to the objects to null and the
RMI-Connection thread sets its references to the objects to null, then there are no
more references to the object and it is subject to garbage collection.
If the threads you created do not end, that is -- return in the run() method, then you
will keep creating more and more threads until you finally run out of resources.
As far as close the present server and open a new one -- NO.
You must solve the storage problem. You have a design flaw somewhere and this is
where Java tools come in handy. There are products on the market to display
memory and object usage (like JProbe). Look here on JGuru or go over to JavaWorld
for a list of tools.
I Have a server that access a database via JDBC, and want to return
ResultSets VIA RMI back to the Client. I have read that this can't be done
(But it can be got you could go through your ResultSet and Return a
Vector). I would be grateful if somebody could give me an example of this.
Better yet if there is some way of passing the ResultSet Back. I tried making
the ResultSet serializable but that didn't work.
Location: http://www.jguru.com/faq/view.jsp?EID=592454
Created: Dec 20, 2001
Author: Benoit Quintin (http://www.jguru.com/guru/viewbio.jsp?EID=394478)
Question originally posed by JavaDB OOP
(http://www.jguru.com/guru/viewbio.jsp?EID=336747
Look, as far as I understand it, a resultset really doesn't make ANY sense once
serialized out of the JVM it was created in.
You are right, going through your resultset and adding it to a Vector is a decent way
of doing it. As in
Connection con;
Statement st;
ResultSet rs = st.executeQuery("query here");
Vector v = new Vector();
while(rs.next) {
v.add(rs.getXXXXX);
}
then close your resultset and serialize the vector.
Comments and alternative answers
JDBC RowSet
Author: V S N Murthy Boggavarapu
(http://www.jguru.com/guru/viewbio.jsp?EID=63013), Dec 21, 2001
Use RowSet instead of ResultSet. Which is serializable . so u can send RowSet object
over network ..u need not convert it into Vector. RowSet is in package javax.sql.
I started working on RMI recently and this particular concept is not clear to
me: 1.When the client invokes a remote method,which is void ,will the Client
know this from the stub it gets from Registry that its not getting anything in
return? 2.If so then will the Client thread still wait for some kind of Ack
from Server before it could do something else 3.Or the Client thread will
finish sending what it has to send to Server and free that thread to do
something else. It does not seem necessary for the Client Thread to be
blocked even when there is no return data from Server.
Location: http://www.jguru.com/faq/view.jsp?EID=592455
Created: Dec 20, 2001
Author: Dave Bucci (http://www.jguru.com/guru/viewbio.jsp?EID=580534) Question
originally posed by Sandhya Nagamangala
(http://www.jguru.com/guru/viewbio.jsp?EID=553775
I believe that the call is synchronous because the client must be prepared to receive
exceptions back, which may be thrown at any time throughout the server object's
processing.
I'm fairly certain (though I haven't tried it) that if you truly want asynchronous
communication, your server object can cause that to happen by creating a thread to
perform the processing, and returning immediately.
Generics and Method Objects is an excellent source for information on how to use
"Generics" with Java RMI. More information on "Generics" can be found at Generics
and Java.
so use
NOT
Note that passing 0 in for the port number is the same as calling the no-
arg. constructor. It will just use an anonymous port.
In other words, this problem doesn't seem like it's been solved yet :)
WebLogic implementation
Author: David Toyer (http://www.jguru.com/guru/viewbio.jsp?EID=1129062), Nov
18, 2003
Any idea how I would do this in WebLogic. It's implementation
UnicastRemoteObject does not support the constructor being used in the example
article
Sun has come up with a fairly good cookbook approach for converting existing RMI
programs to use IIOP. See http://java.sun.com/j2se/1.4/docs/guide/rmi-
iiop/rmi_iiop_pg.html#Convert. Also, note the Restrictions When Running RMI
Programs Over IIOP section.
Hi,
When you execute a lookup to get the home interface of your bean, you normally use
the lookup() method of the javax.naming.Context interface.
This method will return you an Object that needs to be casted to the home interface
you've asked for. Unfortunately, this cannot be done using the normal/explicit casting
[MyHome myHome = (MyHome)returnedObject].
As you have already found out, the reason is connected to CORBA. Why?
For EJB, the communication between the server and the client is based on RMI (both
remote and local interfaces, in fact, do implements the java.rmi.Remote interface).
The underlying protocol that it is used for the communication is IIOP (I think 1.2),
that is part of CORBA standards. It is normally used to describe this communication
system using the Java RMI over IIOP.
IIOP has not been designed for Java, but for generic languages, and this means that
there are some limitations. Some languages, in fact, do not have the concept of
casting.
Java RMI-IIOP provides a mechanism to narrow the the Object you have received
from from your lookup, to the appropriate type. This is done through the
javax.rmi.PortableRemoteObject class and, more specifically, using the narrow()
method.
Just a note: when you are using the new EJB 2.0 Local Client API, you should be able
to do a direct/explicit cast from the looked up Object, to the interface you need.
RMI-IIOP
Author: Deepak Kalra (http://www.jguru.com/guru/viewbio.jsp?EID=1152019), Mar
10, 2004
Since Remote and Home interface implements java.rmi.Remote interface. ThE calls
to these interface will be remote calls and Most of the conatiner use IIOP as
communication network protocol and IIOP is CORBA standard. So we have to use
narrow method of PortableRemoteObject as Its define as the standard of IIOP.Normal
cast operator will not work as Application server use IIOP protocol
Re: RMI-IIOP
Author: Kacel Kacel (http://www.jguru.com/guru/viewbio.jsp?EID=1161993), Apr
11, 2004
The spec says to always narrow. If your ejb server (container) doesnt serv IIOP on
wire , then the usual cast should work BUT your client code wont be vendor
independent. Deploying, again, your ejb on an IIOP server, yhis time, will break
your clients (without narrow). Think narrow instructions as portable condition for
your bean, and think that your client is not always written in Java.
Re[2]: RMI-IIOP
Author: Suresh Subramanian
(http://www.jguru.com/guru/viewbio.jsp?EID=1226627), Feb 11, 2005
I have seen a single application using both normal java casting and narrowed
objects. In this application all servlets use normal casting to lookup ejbs and ejbs
use narrow to lookup other ejbs like client java command line applications. Is
there a specific reason to have this difference in approach? I want to know the
difference. Please explain Thanks Suresh
In Java, a File Object simply represents a possibly existing file on the file system.
If you want to work with a file's content, you'll ask an InputStream for it, and only
then you'll really access the file.
What you can do to solve your problem, is to read the file on the server side, store
it's content (in a String, byte array, or whatever ...) and pass the content to the
client.
This has to be done, because the remote machine can't access the local machine's
file system.
This can be implemented by putting a method in you remote interface like this:
byte[] getFileContents ( String fileName ) throws RemoteException;
if you then implement this method on the serverside and return a byte array, you
can write a new file on the client side, or keep the data in memory, according to your
needs ...
Is there a suitable way to show the process messages to the user and at the
same time specify whether the process was started successfully...
Location: http://www.jguru.com/faq/view.jsp?EID=741015
Created: Jan 30, 2002
Author: Bob Lee (http://www.jguru.com/guru/viewbio.jsp?EID=733188) Question
originally posed by Sudhakar Santhanam
(http://www.jguru.com/guru/viewbio.jsp?EID=561986
I wrote a RemoteRuntime server geared at just that.
http://crazybob.org/runtime.zip. Edit the "runtime.policy" file to tighten/ease the
security restrictions.
As a side note, the call to the RemoteRuntime does not return until the process has
completed. If you run apache or something, make sure it's set up to return the
results and fork another process so that the first can return.
File Moved
Author: Bob Lee (http://www.jguru.com/guru/viewbio.jsp?EID=761813), Dec 16,
2002
This is now http://crazybob.org/downloads/runtime.zip
The problem is that there can be only one RMI registry created in a Vitrual Machine.
(this is a limitation to the concept of RMI).
Since RMI needs to have a few objects with a known Object ID for allowing clients to
find the Registry, these can not exist multiple times in the same VM.
(If you search the RMI-user archives at java.sun.com, you'll find a more detailed
explanation).
What you can do is start one RMI registry from within your application with
LocateRegistry.createRegistry, and start one or more other RMI registries externally
(on the command prompt with 'rmiregistry').
If you extends this class, your object will be automatically exported for RMI access.
If your class is already extending another class, or you just don't like extending from
UnicastRemoteObject, you can also do the following:
UnicastRemoteObject.exportObject ( this );
I want to connect a jini service to a rmi client. Please tell me how to do this
as I have to complete my project.
Location: http://www.jguru.com/faq/view.jsp?EID=1057310
Created: Feb 16, 2003
Author: Edward Harned (http://www.jguru.com/guru/viewbio.jsp?EID=240325)
Question originally posed by ahsan askari
(http://www.jguru.com/guru/viewbio.jsp?EID=1055376
why we use home interface in EJB. In RMI we dont have any concept like
home interface.why we particularly go for Home Interface Both RMI and EJB
are distributed applications. In EJB we use Home interface which is not
avaliable in RMI. There must be several reasons for using Home Interface of
EJB. can any one give reason for this?
Location: http://www.jguru.com/faq/view.jsp?EID=1081979
Created: May 5, 2003
Author: Nick Maiorano (http://www.jguru.com/guru/viewbio.jsp?EID=780589)
Question originally posed by vishnu rajan t k
(http://www.jguru.com/guru/viewbio.jsp?EID=1075172
By posing this question, you seem to be comparing RMI and EJB as if they were the
same type of technology and they are definately not. RMI is a lower level technology
that allows java objects to be distributed across multiple JVMs. Essentially, RMI
abstracts sockets and inter-JVM communications.
EJB, on the other hand, is a technology built atop of RMI but does so much more
than allow java objects to be distributed. It is a framework that allows you to build
enterprise applications by (among other things) abstracting transactions, database
access and concurent processing.
Having said this, the answer to your question is the following. The home interface is
EJB's way of creating an object. Home interfaces act as factories to create session
beans and entity beans. These factories are provided by the application container
and take care of many low level details. Since RMI is a lower level technology, it does
not offer the home interface. You would have to create it yourself.
more EJB/RMI
Author: Laurent Mihalkovic (http://www.jguru.com/guru/viewbio.jsp?EID=407112),
Jun 8, 2003
couple things...
Although EJB originally started as a technology for remoting, and therefore made use
of RMI for containers implementations, the technology has now outgrown its original
intent. The introduction of local interfaces geve EJBs a boost for situations where
remoting was not necessary, leading to faster intra-VM calls.
In view of this departure form the remoting nature of EJBs, I do believe that the real
defining feature of EJBs is the life cycle management provided by the application
server. In recent years, the JVM itself has received many improvements in the area of
memory management and garbage collection. Sun and IBM have both studied
carefully the usage patterns on the servers and built agressive optimization strategies.
Marc Fleury (the vibrant voice behind JBoss) recently published an interesting white
paper about the optimizations built into modern EJB containers, as well as an
interesting view (I happen to share it) that with the flexibility introduced by CMP 2.0,
EJB containers are rapidly becoming elaborate caches. These caches keep the raw
database data in a format directly usable by Java code, taking care of synchronizing
memory and database when necessary.
The paper is really interesting, and it gived an interesting glimpse at what modern
technilogy based on dynamic class instrumentation has in store for the future of EJB
containers.
cheers,
laurent
In RMI we do not have any concept of conatiner services and in EJB, container use
the EJB Object to provide all the services like transacion, security etc. So this way we
use Home interface in EJB, in order to get the reference of EJB object and container
services
EJB is object invocation. i.e an instance of an object will be created and assinged to
the client through which several business methods will be invoked.