Hello Oleg,
I agree with your idea that this setting should be optional. Nevertheless, I
do not think it is possible to do true transparent dynamic classloading and
not setting this URL in the stream but rather let the RMI marshaller
subsystem contact a JNDI name. Nevertheless, it would be still possible to
completly suppress the optional URL during the marshalling (i.e. getURLs
return an empty vector) and, in the client code, to set the appropriate rmi
system codebase properties such that the dynamic classloading can occurs.
The problem with this approach is that the client is only able to dynically
download code from a single source whereas with the "standard" way, you can
have as many sources as you want.
Cheers,
Sacha
> -----Message d'origine-----
> De : [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]De la part
> de Oleg Nitz
> Envoye : jeudi, 7 juin 2001 23:32
> A : [EMAIL PROTECTED]
> Objet : Re: [JBoss-dev] MarshalledObject + URLClassLoader = huge
> network traffic
>
>
> Thanks Sacha, I understand the idea now.
> It didn't come to my mind, so I count it as a great one :-)
> Looking forward to see its implementation in CVS.
> I hope the http://... URL will be optional: if I don't use dynamic
> classloading, I don't want to have this overhead on each call.
> Even if I used it, I'd like the URL to be passed in some other
> way, not with
> each MarshalledObject instance, that would be still rather expensive IMHO.
> E.g. the URL could be available via JNDI.
>
> Regards,
> Oleg
>
> On Thursday 07 June 2001 22:16, you wrote:
> > 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
>
>
> _______________________________________________
> 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
