This really should be fixed by having a new URLClassLoader subclass that
returns the java.rmi.server.codebase so that code can be properly downloaded
to the clients while still loading classes from the local urls. This fixes
the current
dynamic class loading problem. I have a solution based on what Vlad and
Sacha
had mentioned in their investigation of the problem that I'm going to commit
next
week.
----- Original Message -----
From: "Oleg Nitz" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, June 07, 2001 9:27 AM
Subject: [JBoss-dev] MarshalledObject + URLClassLoader = huge network
traffic
> Hi,
>
> We've noticed the enormous traffic between client and server.
> Investigation showed that the problem is in MarshalledObject:
> "...classes are annotated with a codebase URL from where the class can
> be loaded (if available)", which means that when the enclosed
> object was loaded via URLClassLoader, then the list of all URLs of the
> classloader is enclosed in the MarshalledObject instance.
> This list includes full names of all jar-files residing in the local
> filesystem, in any case they can't be used on the remote computer.
> In our project we use URLClassLoader in the client application,
> JBoss and underlying JMX library use it as well, the result is awful.
> My proposition to JBoss developers: to introduce own class which would
> do the same things as the standard MarshalledObject class, but will
> not enclose the URLs list,
> or will contain only non-"file:" URLs ("http:", "ftp:"),
> which can be used on the remote machine, at least theoretically.
> I will implement this idea when/if it meets with approval.
> Comments are appreciated.
>
> Oleg
>
>
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
