Speakers Ann Wollrath (ann) and Adrian Colley (aecolley)
Moderator Edward Ort (MDR-edO)
This is a moderated forum.
MDR-edO: Welcome to Java Live! Today's session is focused on Remote Method Invocation
(RMI). Our guests are RMI architect Ann Wollrath and Sun engineer Adrian Colley. They'll answer
your RMI questions. So let's begin. Who has the first question?
lesterjl: I'm having a problem using RMI from an applet when the client is behind a
firewall. Apparently the system parameters (proxyHost
and proxyPort
)
are not being set by the web browser, however the URLConnection
or the properites
classes seem to be able to request files from the web server without this information. If I have
my applet force the http.proxyHost
and proxyPort
parameters it works
the way it should. My question is how do I determine what the correct proxy settings are for the
client machine my applet is running on? Or is their another around this problem?
aecolley: You can't really anticipate the proxy that a user will need to use on his or her
network. Unfortunately, there isn't an automatic way around firewalls, which is why they're
secure.
NiclasH: Tell us about the upcoming security features, such as User Authentication
and Secure Transport. It seems to be the most wanted extension to RMI.
ann: Hi Niclas, the new RMI security specification is available.
david: What is the future of RMI/IIOP?
ann: Hi David, what specifically do you want to know?
sunil: Hi everybody, how would one distinguish source files and determine that this
is RMI Server and this class is RMI Client. If Naming.bind()
is used then it is
server and Naming.lookUp()
is used its a client. Or any other way for it?
aecolley: Generally a program can be both an RMI client and an RMI server at the same
time. The terms "client" and "server" are relative to a remote call.
Tejas Shah: As far as I understand HTTP tunneling is done by the
DefaultSocketFactory
in RMI, and SSL support can be provided by installing a custom
socket factory. How can I do both?
aecolley: You have to reimplement HTTP tunneling if you want to do HTTP-tunneling through
some other tunnel (such as SSLSocket). An alternative, which you might not like, is to use a
HTTPS proxy server.
NiclasH: There has been some suggestions that Serialization of the Stack
trace
object in a Throwable
is optionally available, for transfer to the
client, for better debugging purposes. Are there any such plans?
ann: Hi Niclas, the most recent draft RMI security specification can be found at RMI-Security.
Nitya: Hi. Are there any plans to support MulticastRemoteObjects
to
allow replication?
ann: While this feature is desirable, we don't have plans currently to support it. It
would require defining a common serialized format for stack traces.
aigen: We are using EJBTMs, which are based on
RMI. One thing I find curious is that the remote interface is built and compiled separately from
the remote object. This makes development awkward. Is there some way, such as IDL, that the
process can be simplified?
ann: Hi aigen, in the next release of RMI, we plan on supporting customizable remote
references types. While we don't plan on directly supporting a
MulticastRemoteObject
, the additions to the RMI API will allow one to be defined to
work in the new framework.
aecolley: The remote interface is shared between the service and the client; I don't see a
way to eliminate it. Do you mean that it's awkward to build the stubs separately? If so, then
it's easy to use the rmic -keepgenerated
option to generate stub source, which you
can then recompile with javac
multiple times. Is that what you're asking?
juanmi: If RMI is a standard interface, why do we need to use
narrow
when talking to a CORBA object? Wouldn't it be more natural if we talk to
RMI/IIOP the same way we talk RMI/JRMP?
ann: Hi juanmi, RMI/IIOP stubs do not implement all the interfaces that the remote object
implements (like RMI/JRMP does), therefore you need to perform a network operation to check the
cast so that a simple JavaTM programming language cast can't be
used.
Jim: To get the new RMI security specification mentioned above, what version of
Java must be running?
aecolley: The security described in the security specification hasn't been released. We
won't assign a version number until much closer to release. Have patience!
Seema: Hi, we are facing problems regarding RMI with NAT (Network Address
Translation). Our Server has, say internal IP 1.1.1.1 and external IP 2.2.2.2, and rmiregistry is
running on default port 1099. The RMI server is bound with Internal IP 1.1.1.1
java.rmi.server.hostname property set to internal IP 1.1.1.1 at command line. Also tried to set
the server name to aaa.something.com) We have opened ports 1099 for RMI , 5050 for HTTP through
firewall. When we try to connect to server from an applet outside our domain, through IP
2.2.2.2:5050, a java.rmi.Connect exception is thrown with the message: "Connection refused
to host aaa.something.com no further information."
We tried the same thing with a different RMI applet, but got following result: It found the
server (passed Naming.lookup(...) successfully), but it threw an exception,
java.rmi.ConnectIOException: Exception creating connection to:1.1.1.1; nested exception
is:java.net.NoRouteToHostException: Operation timed out: no further information
java.net.NoRouteToHostException: Operation timed out: no further information.
aecolley: You can only pick one IP address or hostname for java.rmi.server.hostname. You
picked the internal address, but you should have picked the external address. If you want
internal hosts to use the same objects, you need to be able to use the external address from
inside the firewall. Alternatively, arrange for aaa.something.com to resolve to 1.1.1.1
internally and 2.2.2.2 externally. Isn't this in the FAQ?
Nitya: Is there some capability in RMI-IIOP to support "persistent"
objects such as those allowed by other ORBs such as Visibroker? In particular, is there any hook
to eliminate transient identifiers from the object key?
ann: Hi Nitya, RMI/IIOP does not support persistent objects. I don't know what the plans
are for supporting them in the future.
Shanthi: Are there any online RMI samples that can help me build an international
chat server/client?
aecolley: Not that I know of. I think you're expected to design it as an object system
and then decide how to build it with RMI.
Tom: Time-outs confuse me... Let's suppose I have a client that gets a reference
to an object on a server via lookup. This client also happens to extend
UnicastRemoteObject
, and the first thing it does is send a reference of itself to
the server object in order to do some callbacks. The server maintains this reference as a local
object at its end. If both client and server stop invoking methods on each other at this point,
how long will it take to time out and how will each be aware of it? Do I sound like I know what
I'm talking about? :)
ann: Hi Tom, are you talking about connection time-out?
Tom: I think so... what other kinds of timeouts would occur in this case?
aecolley: Tom, the other kind of timeout is a lease timeout for Distributed Garbage
Collection. The Unreferenced
interface sounds like what you're looking for. If
you're looking for a connection timeout, there's a bevy of system properties (in the RMI-USERS
archive) for tuning them.
Tejas Shah: aecolley : Is it possible to piggy-back on Sun's
DefaultSocketFactory
to change the transport to secure sockets. If not, how
difficult would it be to take Sun's code for the DefaultSocketFactory
and change it
to use SSL sockets ?
aecolley: Yes, if you intercept the SocketImpl
(which is documented
somewhere) or if you go and hack sun.rmi.transport.proxy.RMIMasterSocketFactory
(which isn't).
Chris Butzow: Could there be and advantage to compressing a large byte array before
returning to an RMI client? Particularly if it were going across multiple tiers? (From a DB
Server to an Application Server and then to the Client.). Or does RMI do compression "under
the covers" so there would be no advantage?
ann: Hi Chris, RMI does not do compression "under the covers." There is a
tradeoff using compression. If the bandwidth is really low, than compression might help, but the
compression costs might outweigh the lower transmission cost over a higher bandwidth network.
david: When you read the RMI spec, it talks about many features which are only
supported in the JRMP version. I'd like to know how this can be reconciled. Also, you just
mentioned security (for JRMP, I assume), is it Javasoft's intention to have JRMP and IIOP just be
alternative transports?
Sam: Tejas Sh: Take a look at the JSSE-examples, there is one about RMI and SSL.
Sam:Is it possible to do a remote application like this: First I create an
application. Then I create a small RMI-Interface, which calls a new instance of the application.
Does a client can operate with the application like he has it local?
ann: Hi david, RMI/IIOP was not intended as an alternate transport for RMI. RMI/IIOP is,
in some sense, defined as an intersection of the RMI and CORBA technologies so it cannot possess
all the features of both. RMI/IIOP
may include some of the new features of RMI over time.
amy: Could the input-output part of an applet be done with RMI?
aecolley: I'm not sure what I/O has to do with applets, except that applets aren't allowed
to do it :-). An applet could use RMI as communication with its (home) data store, if that's
what you mean. Of course, HTTP PUT is probably more suited to raw data storage.
aecolley: No, not like it's local, for the simple reason that a
RemoteException
could be thrown. You could interact with it as if it was remote but
still an object (in the OO sense) so long as you're prepared to catch and handle network errors.
Hope this answers.
ann: Hi, david, some of my message got cut off. The last sentence should say that
RMI/IIOP will include some of the new features of RMI over time.
nitya: Hi. Is the RMISocketFactory
mechanism applicable to RMI-IIOP as
well? Also, where can we get more information on the internals of RMI-IIOP? RMI-JRMP was a
well-documented, well-supported package in comparison.
Shanthi: Does IE5.0 support RMI calls? Or should we communicate through proxy?
Chris Butzow: Is there a limit to the size of and object returned to an RMI client
from an RMI Server? For very large objects, I have seen an exception something like "RMI End
of File..." Is there a limit? Is it a universal limit? Is there a way to determine the
limit? Set the limit?
ann: Hi nitya, I'm not sure what the plans are for RMI/IIOP. I think that
RMISocketFactories might be supported in the next release.
NiclasH: The J2ME group just requested feedback on RMI in constrained environments.
We suggested that they would allow crippled RMI versions: a) No support for dynamic classloading
b) No support for general purpose serialization, only java.lang
classes. Would
this be an possibility or is the codebase so intertwined with serialization, that it is not
feasible?
aecolley: There's a tiny RMI effort already underway for the J2ME/CLDC. I'm not sure that
dropping support for general purpose serialization is such a good idea, though it has to compete
with other features for the constrained resource budget, of course. We'll see.
aecolley: Shanthi, I have no personal experience of IE5.0, but I'm told that its RMI
support is no better than IE4.0's (none except for a mysterious drop-in zip file). I'd use the
Java Plug-In if I were forced to use IE.
ann: Hi Chris, there is no hard limit on the size of the object returned in an RMI call.
The only real limit would be memory resources. The end of file may signify some other kind of
serialization failure.
lesterjl: I'll accept I can't automatically obtain the client proxy settings to use
RMI tunneling. However, my company has determined that asking the end user for this information
directly is not a good idea. Due mainly to the fact most of the users will not know what these
settings need to be. Other than creating my own HTTP wrapped protocol using classes that know how
to use the proxy server. An idea I don't relish. Do you know of any other companies who may have
found an alternative solution?
ann: Hi lesterjl, is the problem that RMI is not falling back on HTTP from an applet
running in Netscape? If so, the http.proxyHost
property does not have to be set to
the proxy host name. It can be set to anything and it should work.
Seema1: aeolley, We tried with both IP and hostname.
aecolley: Seemal: but did you make sure that the hostname resolves to the internal address
when looked up internally, and the external address when looked up externally? Hosts files are
generally useful for this kind of trick.
Tejas Shah: I'm trying to write an interface that will transparently return an
RMI/JRMP object or an RMI/IIOP object based on whether the client is inside or outside the
firewall. But trying to send an RMI/IIOP object as a return from an RMI remote object gives an
RMI Unmarshal
exception in the client. Is this not supported ?
NiclasH: One of the weekly returning issues on RMI-Users is the pros/cons of the
Registry, its limitation versus ease of use, etc. Are we to expect that the RMI Team launches a
more advanced Registry, without going to the full extent of JiniTM technology, perhaps based on JNDI?
ann: Hi Niclas, the registry was just intended for bootstrapping (to find the first remote
reference). Providing a fully functional name service is beyond the scope of RMI and is provided
in Jini and via JNDI to other name services.
nitya: Is there a possibility of having RMI provide interfaces that will allow an
alternative transport to be plugged in - say a multicast protocol that provides the requisite
reliability and ordering guarantees?
aecolley:The standard pluggable unit has always been the socket factory. To do more you'd
need to get at the transport layer, which isn't really public or entirely modular (for
instance
, exportObject
has an `int port' argument).
ann: Hi Tejas, what version of Java is running on the client?
Tejas Shah: Hi Ann, I was running it with 1.1.7, but I can upgrade to 1.2 or 1.3 if
necessary.
lesterjl: That does seem to be the problem. I give that an attempt. Thank you.
ann: Hi nitya, we plan on providing an easier way to plug in an transport in the next RMI
release after kestrel (after 1.3).
ann: Hi Tejas, your client needs to be upgraded to 1.2.2 in order to unmarshal an RMI/IIOP
stub.
ann: Any more questions?
aecolley: Any serialization or Jini questions then?
aigen: I'm not familiar with RMI Tunneling. What's that?
aecolley: RMI tunneling is like general protocol tunneling: for some reason you can't talk
protocol A
to a peer, but you can talk protocol B, so you embed your type A packets
inside type B packets and arrange for the recipient to unpack them. It's rather sneaky, and it
bypasses firewall restrictions (much like asking visiting customers to wear FedEx suits because
you can't retrain your building security staff). RMI-over-HTTP tunneling embeds the RMI protocol
inside HTTP POST requests, because most firewalls pass HTTP unhindered today. However, so many
protocols are being embedded inside HTTP that it will eventually become necessary to filter HTTP
contents, too, and then we're back to square one.
juanmi: If I make a Remote interface and implement it using a
Proxy.class
(JDK 1.3). How can I return it as a remote object using RMI-iiop or
RMI-JRMP? (I haven't got a rmic stub
).
ann: Hi juanmi, in 1.3 you can return dynamic proxy classes using RMI-JRMP. You cannot
export a remote object as a Proxy class (you will not get a dynamic proxy class), however you can
construct one and pass an instance of a proxy class in an RMI call. You cannot pass an dyanmic
proxy in RMI-IIOP in 1.3. In 1.4 we will be supporting dynamic proxies as remote object stubs by
default.
NiclasH: After the Kestrel release the evolution seems to slow down considerably.
Are we to expect that the RMI Team will work on debugging, deployment and runtime analysis tools,
that are obviously in high demand?
ann: Hi Niclas, actually after the Kestrel release we will (and currently are) working on
security, custom remote reference types and easier ways to use alternate transports with RMI
objects. Please let us know what you need in terms of debugging and deployment tools so that we
can consider them in our future plans.
juanmi: How distributed garbage collect is going to be supported (if so) by
RMI-IIOP? is Activation going to be supported or referenced ?
ann: Hi juanmi, the IIOP protocol does not currently support garbage collection. We don't
know what the plans are for supporting it in the future in RMI/IIOP.
aecolley: So, what _do_ y'all want in the line of RMI debugging/development tools?
aecolley: Some of these topics are good for discussion on RMI-USERS. Anyone who doesn't
like typing or wants a personal experience can come heckle us at this year's JavaOneSM.
MDR-edO: Well our hour is up. I want to thank all of our participants for their excellent
questions. And I want to especially thank our guests Ann and Adrian.
ann: Thanks for the great questions and hope to see you at JavaOne.
aecolley: This was fun (except for the user interface). Happy hacking, all!
MDR-edO: Last moderator (me) signing off. The forum is now unmoderated
nitya: Hi. Yes. How does the Tie class function in RMI-IIOP?? Is there an
equivalent -keepgenerated flag to get the source?
aecolley: From RMI's point of view, it's getting a remote reference before you
have a remote reference. RMI does it by allowing you to construct a remote
reference to a Registry.
juanmi: well i´ve want to know why we must use rmic on a class that implements
the remote interface, won´t be better running it on the remote interface
aecolley: A class that implements more than one remote interface needs a
single stub that implements the same interfaces
NiclasH: Yes, regarding JINI... Since RMI is currently not available in J2ME (and
its relatives) and registering the service object in the LUS requires RMI at the
moment, this is a serious situation in the device world. Is there any plans to
modify this behavior to allow the device to tell the LUS to pick up a
pre-serialized proxy object over for instance HTTP?? Hope you understand...
aecolley: You need RMI to register with reggie, but not with other Jini lookup
services (and there are others that I know about that haven't been released to
the public yet)
Sam: Is it possible to develop first an application and afterward doing an
remote interface?
aecolley: Yes, it's possible, though consideration of the remote failures
may make it clunky or unusable. Consider NFS, which was a file system
remodified, though its applications weren't prepared for remote exceptions.
nitya: A followup on a question I saw on the RMI-USERS list. If only the
implementation of a remote method changes, do we need to run rmic and regenerate
the stub classes?
aecolley: No, you don't have to rerun rmic unless you change the remote
interfaces (or add or delete interfaces).
sunil: Do I need a PWS to test an applet that uses RMI?
sunil: PWS - Personal Web Server
aecolley: Yes, you need a web server of some kind.
Class-server.zip is good and
small
juanmi: If we talk to a JINI registry: Can it have attached RMI-JRMP and CORBA
Objects? if so, how we know if we need to do a narrow? if is corba(RMI-IIOP)
how we get the stub to make the dynamic cast)?
aecolley: It can have RMI objects or CORBA objects or HTTP objects or anything else
serializable. You shouldn't depend on its implementation, just on its interface. I think
narrowing is only necessary for CORBA calls, not for
getting CORBA objects from other calls.
amy: Thanks, aecolley. I will put it this way : is it advisable letting an applet
getting (priorly unzipping MB's of measurement) data via RMI?
aecolley: Sure, so long as the data are Serializable
sunil: RMI works on TCP. What is JRMP?
aecolley: JRMP is the name given by the RMI/IIOP team to the (thitherto
unnamed) Java RMI wire protocol. It stands for Java Remote Method Protocol.
NiclasH: sunil; JRMP is the RMI Wire Protocol (former name) which defines how
the TCP data stream is formatted.
Sam: Does it make sense to create a new application with a "Factory
Pattern" as main RMI-Interface?
aecolley: Yes, and such objects are often used to escape from the primitive
rmiregistry as soon as possible after application startup.
coelhon: Remote Server Implementation are Thread safe?
aecolley: Remote methods are dispatched in parallel, so they're not any
more thread-safe than concurrent threads. You can use synchronized if you need
it.
john c: you guys sound like you have been working with RMI for some time. Would
you know if a remote object can have it's exported methods invoked reentrantly?
In other words, does the RMI library synchronize all exported functions?
aecolley: The methods can indeed execute reentrantly. RMI doesn't
synchronize them.
juanmi: The problem is if i´m looking to the services, just looking
and making reflection to find a service (at the Jini registry) that feeds my
needs. The registry serves me the remote object face (it works as a proxy), he
must give me its stub so i can communicate whit it, and if its a corba object i
need to make a narrow. how can i know it???
aecolley: You need to narrow it after casting it to the remote
interface? I'm sorry, but I don't think I know the answer to your question.
apr: Is JINI/RMI prepared for really low quality extremely unreliable TCP/IP
WAN? I'm not talking about the Leases concept, which is great but that works on
top of RemoteEvents that in turn uses RMI.
aecolley: Jini is designed exactly for unreliable networks (which is really
all of them, potentially). The worst that will happen is that service will be
unavailable for longer than strictly necessary.
coelhon: If I have a dozen remote objects registering them in RMI registry
could be expensive what is best way to implement this?
coelhon: Thanks, I think that is what I should do. So, client don't
have have to lookup for all these objects in registry.
adrian: No, you don't need to bind remote objects in the registry in
order that they be callable.
coelhon: If there are thousands clients trying to access the same method on
remote object that could make things really slow? And what is the best solution?
adrian: Well, the "best" solution is to get more than one server so you
spread the load. The next best is to make the remote method unsynchronized and
fast.
NiclasH: coelhon; If you are expecting REALLY heavy load, I would suggest that
you implement your own socket factories, to refuse connections at some point. If
your client side then has a fail-over strategy in place, you have a reasonable
load-balancing in place (provided that you can distribute the RMI resource.)
adrian: I have a meeting with my manager now. So long, world.
_______
1 As used on this web site, the terms "Java
Virtual Machine" or "JVM" mean a virtual machine for the Java
platform.
Reader Feedback
Tell us what you think of this transcript.