Hi Scott,
Thanks for your answer.
I am afraid you speak about another problem.
At least I don't believe that the problem that I'm speaking about
can be solved in a subclass of URLClassLoader.
If MarshalledObject gets an object in the constructor,
which is loaded by any subclass of URLClassLoader,
MarshalledObject calls getURLs() on it and stores the result inside
itself, so that the array of all URLs from client's classpath is sent
to the server together with each minor parameter, and all URLs from
the server's classpath are sent to client together with each return
value (if its class is not in the system classpath).
Just to make it clear: currently we are not going to use dynamic class
loading at all, we have all needed classes on the client,
we are anxious about the unnecessary network traffic.
And this traffic is absolutely stupid, to be honest :-)
Oleg
Scott M Stark wrote:
> 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
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
