Re: Scaling Reggie

Gregg Wonderly wrote:

> This is an interesting issue. The codebase, being downloaded to
> reggie, would cause a new classloader, per client. Java would then
> also create a jar index and do some other things that consume memory
> to manage access to that codebase jar. For my clients, I almost
> always strive to have them use a http://localhost:8080/ url for their
> codebase so that the services (which have explicit knowledge of the
> clients 'platform', in general) use a single classloader for all
> clients. You have to be careful about static class data, but
> otherwise, I've found this to be a good way to minimize memory use
> with  large numbers of clients.

No doubt the ones that designed and Reggie know this better than me and
will correct me, but it is my current understanding that Reggie won't
create class loaders due to the codebase annotation for the service
proxy and attributes registered. The smart proxy of Reggie performs some
magic with these and they are never unmarshalled at the Reggie side,
from the perspective of Reggie these objects are just dead payload
similar as Entries in a JavaSpace.

There is one case though I can think of where Reggie does create class
loaders and that is with the registration of the remote event listeners
for receiving service discovery events [1]. So in case the service with
a codebase referring to 90MB of JAR file(s) is registering for receiving
events a class loader is created in the JVM Reggie is running, but
otherwise not and this makes Dennis his case so intriguing.

[1] another case why an inverted event model can be handy as there is no
need for the server to create additional class loaders, sorry couldn't
resist :-)

> I'm betting that it's simply the size of the jar indexes and URLClassLoader
> counts that are creating the memory issue. Perhaps those details end
> up using non-heap memory which is sized fairly small? I think that
> the total numer of classes that can be loaded is impacted by non-heap
> memory size too right?

Indeed there is some indexing performed by URLClassLoader and with a
collection of 90MB of JAR files this could be more than trivial and
consume resources, although the server registering itself seems to
handle it just fine so to me it doesn't serve as an explanation why
Reggie would experience an OOME. Well we just have to await a
reproduction with a stacktrace I guess.
--
Mark

--------------------------------------------------------------------------
Getting Started:     http://www.jini.org/wiki/Category:Getting_Started
Community Web Site:  http://jini.org
jini-users Archive:  http://archives.java.sun.com/archives/jini-users.html
Unsubscribing:       email "signoff JINI-USERS"  to [email protected]