RMI broken in Java 6 Update 10

[FutureScalper]

My RMI code has worked perfectly prior to Update 10.

The _Stub class, which is in my jar, could not be loaded by the
classloader, and it was not a security problem.

What has changed in RMI for update 10 ? I doubt I am the only one
with this problem.

OUT: 08.11.02 01:18:23.874: RemoteIndicatorServiceImpl object created.
ERR: 08.11.02 01:18:23.907: java.rmi.ServerException: RemoteException
occurred in server thread; nested exception is:
java.rmi.UnmarshalException: error unmarshalling arguments; nested
exception is:
java.lang.ClassNotFoundException:
com.twc.remote.RemoteIndicatorServiceImpl_Stub
java.rmi.ServerException: RemoteException occurred in server thread;
nested exception is:
java.rmi.UnmarshalException: error unmarshalling arguments; nested
exception is:
java.lang.ClassNotFoundException:
com.twc.remote.RemoteIndicatorServiceImpl_Stub
at sun.rmi.server.UnicastServerRef.oldDispatch(Unknown Source)
at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source)
at sun.rmi.transport.Transport$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Unknown Source)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(Unknown
Source)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown
Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown
Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
at
sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(Unknown
Source)
at sun.rmi.transport.StreamRemoteCall.executeCall(Unknown Source)
at sun.rmi.server.UnicastRef.invoke(Unknown Source)
at sun.rmi.registry.RegistryImpl_Stub.rebind(Unknown Source)
at java.rmi.Naming.rebind(Unknown Source)
at com.twc.trader.ZoneTrader.<init>(Unknown Source)
at com.twc.trader.ZoneTrader.createAndShowGUI(Unknown Source)
at com.twc.trader.ZoneTrader.access$3(Unknown Source)
at com.twc.trader.ZoneTrader$95.run(Unknown Source)
at java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown
Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown
Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
Caused by: java.rmi.UnmarshalException: error unmarshalling arguments;
nested exception is:
java.lang.ClassNotFoundException:
com.twc.remote.RemoteIndicatorServiceImpl_Stub
at sun.rmi.registry.RegistryImpl_Skel.dispatch(Unknown Source)
at sun.rmi.server.UnicastServerRef.oldDispatch(Unknown Source)
at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source)
at sun.rmi.transport.Transport$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Unknown Source)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(Unknown
Source)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown
Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown
Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

*** The class not found is clearly in the jar ***
Caused by: java.lang.ClassNotFoundException:
com.twc.remote.RemoteIndicatorServiceImpl_Stub
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClassInternal(Unknown Source)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Unknown Source)
at sun.rmi.server.LoaderHandler.loadClass(Unknown Source)
at sun.rmi.server.LoaderHandler.loadClass(Unknown Source)
at java.rmi.server.RMIClassLoader$2.loadClass(Unknown Source)
at java.rmi.server.RMIClassLoader.loadClass(Unknown Source)
at sun.rmi.server.MarshalInputStream.resolveClass(Unknown Source)
at java.ibjectInputStream.readNonProxyDesc(Unknown Source)
at java.ibjectInputStream.readClassDesc(Unknown Source)
at java.ibjectInputStream.readOrdinaryObject(Unknown Source)
at java.ibjectInputStream.readObject0(Unknown Source)
at java.ibjectInputStream.readObject(Unknown Source)
... 12 more

OUT: 08.11.02 01:18:23.907: RemoteIndicatorServiceImpl Naming.rebind
FAILURE.

 

[Arne Vajhøj]

My RMI code has worked perfectly prior to Update 10.

The _Stub class, which is in my jar, could not be loaded by the
classloader, and it was not a security problem.

What has changed in RMI for update 10 ? I doubt I am the only one
with this problem.

Could you post code and directory structure to recreate the problem ?

Arne

 

[FutureScalper]

No, code is way too complex. In a nutshell, this is a standalone
Java application which permits a portion of the code to be accessed
externally as an RMI server. Thus, two instances of my executable
can "talk" to each other via RMI. Pretty straight forward, really;
and has been working for years.

I would have expected perhaps some Security problem preventing
the classloading, but that is not the case. The classes are, and
have always been in the jar on the classpath.

Previously, I instantiated the Impl and, in the constructor
simply called Naming.rebind("servicename", this). I've separated
this out to make it much cleaner, and made SURE that all RMI handles
are STATIC variables so they do not disappear prior/during the binding
process, etc.

I spent hours trying to get it to work on Update 10, trying everything
in the book, so to speak, and I just have to get my users to roll back
uninstall Java 6 Update 10 until / unless I can figure it out.

 

[Lew]

No, code is way too complex. In a nutshell, this is a standalone

Please do not top-post. Without some clue of your code it is awfully hard to
diagnose what you're seeing.

Java application which permits a portion of the code to be accessed
externally as an RMI server. Thus, two instances of my executable
can "talk" to each other via RMI. Pretty straight forward, really;
and has been working for years.

Are you absolutely sure you cannot construct a short, self-contained
compilable example (SSCCE) of an RMI call that demonstrates your problem?

Previously, I instantiated the Impl and, in the constructor
simply called Naming.rebind("servicename", this). I've separated
this out to make it much cleaner, and made SURE that all RMI handles
are STATIC variables so they do not disappear prior/during the binding
process, etc.

Static variables are an antipattern.

Is this relevant?

Dynamic Generation of Stub Classes (since 5.0)
This release adds support for the dynamic generation of stub classes at
runtime, obviating the need to use the Java Remote Method Invocation (Java
RMI) stub compiler, rmic, to pregenerate stub classes for remote objects. Note
that rmic must still be used to pregenerate stub classes for remote objects
that need to support clients running on earlier versions.

I reviewed
<http://java.sun.com/javase/6/docs/technotes/guides/rmi/index.html>
but didn't find anything that seems to help.

It would help to have an SSCCE.

 

[FutureScalper]

I spawn rmiregistry.exe on Windows as a separate process, and each
of my instances registers a unique name for its services. All
access is localhost, for purposes of this discussion.

Again, the primary exception is class not found exception, so
if this is a bug, it affects class loading of the _Stub class
I'd say.

I guess I can construct some sort of test case. But doesn't
the exception give enough information? Why would the _Stub
class loading be the issue? It's in the jar.

OK, it's a signed jar, and OK, it's run by Java Web Start; there
are quite a few variables here, but it's a straightforward usage
of RMI which has worked forever without any issues until Update
10 came along.

 

[FutureScalper]

No, I am not trying to use an inprocess rmi registry. The
rmiregistry.exe process is running in a separate process so
that isn't the issue.

 

[FutureScalper]

I generate the jar using this rmic approach; and am not relying
upon the new "stubless" approach

rem compiling and adding skel and stub to ZoneTrader.jar
rmic -v1.2 -keep -classpath ../bin -d ./bin
com.twc.remote.RemoteIndicatorServiceImpl
jar -uf FutureScalper.jar -C ./bin com/twc/remote/
RemoteIndicatorServiceImpl_Stub.class
rem Stub added to FutureScalper.jar

No, I am not trying to use an inprocess rmi registry.  The
rmiregistry.exe process is running in a separate process so
that isn't the issue.

Please do not top-post.  Without some clue of your code it is awfully hard to
diagnose what you're seeing.

Are you absolutely sure you cannot construct a short, self-contained
compilable example (SSCCE) of an RMI call that demonstrates your problem?
<http://sscce.org/>

Static variables are an antipattern.

Is this relevant?
<http://java.sun.com/javase/6/docs/technotes/guides/rmi/relnotes.html>

I reviewed
<http://java.sun.com/javase/6/docs/technotes/guides/rmi/index.html>
but didn't find anything that seems to help.

It would help to have an SSCCE.

 

[Lew]

Please do not top-post.

I generate the jar using this rmic approach; and am not relying
upon the new "stubless" approach

What would happen if you did try the stub-free approach?

We really need an SSCCE.

 

[Arne Vajhøj]

> No, code is way too complex.

In that case nobody can
* confirm whether it is a bug
* identify under what circumstances it materializes
* check whether it already is known
* make an official bug report with SUN

Arne

 

[FutureScalper]

Please do not top-post.


What would happen if you did try the stub-free approach?

We really need an SSCCE.

OK, thanks. Over the next few weeks I'll get around
to figuring it out and will post what I find.

 

[Lothar Kimmeringer]

FutureScalper wrote:

[provide source-code]

No, code is way too complex.

Sorry, but if it really is a bug in the JVM it must be
possible to create an example of a remote-interface with
corresponding implementation and RMI-client-class that
lead to the error.

Independent from that, check the filesystem, if the Stub-
class-file resides in the corresponding directory after
calling rmic (or the ant-target if you like).

If there is no Stub-class there is no problem in understanding
why there is a ClassNotFoundError.


Regards, Lothar
--
Lothar Kimmeringer E-Mail: (e-mail address removed)
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!

 

[Arne Vajhøj]

FutureScalper wrote:
[provide source-code]

No, code is way too complex.

Sorry, but if it really is a bug in the JVM it must be
possible to create an example of a remote-interface with
corresponding implementation and RMI-client-class that
lead to the error.

I am pretty sure that he think it is a bug in the Java library
or the Java utilities - not in the JVM.

Arne

 

[dremspider]

I generate the jar using this rmic approach; and am not relying
upon the new "stubless" approach

rem compiling and adding skel and stub to ZoneTrader.jar
rmic -v1.2 -keep -classpath ../bin -d ./bin
com.twc.remote.RemoteIndicatorServiceImpl
jar -uf FutureScalper.jar -C ./bin com/twc/remote/
RemoteIndicatorServiceImpl_Stub.class
rem Stub added to FutureScalper.jar

Has anyone verified this? I have am new to RMI and need to use it for
a project in my class. I have been banging my head for hours. At
this point all I have tried are tutorials online as well as copying
and pasting code from Sun as well as others and I still can't get it
to work as it keeps failing with the same error. I saw this message
and started to think that it may just be an issue with Java. I have
tried it on Linux and Windows and each time when I generate the stubs
with rmic I only get a stub file and not a skeleton file. I then try
to run it and I get a message that the stub class is not found, even
though it is in my class path and all of that. Can anyone verify this
is the case?

http://www.onezerozeroone.eu/html/rmi_howto.html

 

[Arved Sandstrom]

Please do not top-post.


What would happen if you did try the stub-free approach?

We really need an SSCCE.

With JDK 1.6.0_10 on Ubuntu Linux the stub-free approach works. Under the
circumstances, if I were in the same boat _and_ could update the clients
to at least 5.0, I'd go that route.

AHS