Re: [JBoss-dev] MarshalledObject + URLClassLoader = huge network traffic
This is fixed in main. See the ContainerFactory, WebService, WebServer and WebClassLoader for the changes. - Original Message - From: Joseph Dane [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, June 08, 2001 11:59 AM Subject: Re: [JBoss-dev] MarshalledObject + URLClassLoader = huge network traffic on a related note, can someone comment on dynaimc code downloading problem and the proposed solution? I just recently started checking out JBoss, and have generally been impressed. but the fact that dynamic downloading just plain doesn't work is really, *really*, unfortunate. -- joe ___ 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
Re: [JBoss-dev] MarshalledObject + URLClassLoader = huge network traffic
on a related note, can someone comment on dynaimc code downloading problem and the proposed solution? I just recently started checking out JBoss, and have generally been impressed. but the fact that dynamic downloading just plain doesn't work is really, *really*, unfortunate. -- joe ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[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
Re: [JBoss-dev] MarshalledObject + URLClassLoader = huge network traffic
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
Re: [JBoss-dev] MarshalledObject + URLClassLoader = huge network traffic
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
RE: [JBoss-dev] MarshalledObject + URLClassLoader = huge network traffic
Hello Oleg, But I think that the getURLs() method of the new class (that will subclass URLClassLoader), will only return the http://... URL from where code can be downloaded. The method will not prompt every classloader in the chain for their URLs. The goal of this new class is (almost) only to override the behaviour of the getURLs method to return only a single URL. HTH. Cheers, Sacha -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]De la part de Oleg Nitz Envoye : jeudi, 7 juin 2001 19:32 A : Scott M Stark Objet : Re: [JBoss-dev] MarshalledObject + URLClassLoader = huge network traffic 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 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
