jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexandru Popescu" <the.mindstorm.mailingl...@gmail.com>
Subject Re: permgen error with jackrabbit 1.1
Date Wed, 18 Oct 2006 21:07:41 GMT
On 10/19/06, Michael Neale <michael.neale@gmail.com> wrote:
> Yeah bumping up PermGen is usually fine, and not indicative of a memory leak
> necessarily.
>
> The Sun JVM (at least) does not treat class data the same as regular objects
> (but JRockit does, apprently, do it wouldn't have this problem).

I don't think this is really the problem, because the lifecycle of
classes is different then the lifecycle of regular objects, and really
tied to classloading mechanisms. And the permgen the OP is talking
about seems to be related to the fact that the classloader cannot be
dismissed because some classes are hanging around. After a new
deployment a new classloader is created and so on, this finally
resulting in the permgen error.

The only real fix for this is to figure out what classes are left
behind and fix this. And I agree, that this is not an easy task :-).

./alex
--
.w( the_mindstorm )p.



> I have run
> in to this many times before, but usually are we are generating 14K classes
> (!) on the fly (which the JVMs did NOT expect people would be doing so much
> !).
>
> On 10/18/06, Larry Ogrodnek <Larry@theladders.com> wrote:
> >
> > Depending on your application, you may just need to increase your
> > PermGen size.
> >
> > PermGen space is for system-use only, used by the ClassLoader:
> >
> > "The permanent generation is used to hold reflective of the VM itself
> > such as class objects and method objects. These reflective objects are
> > allocated directly into the permanent generation, and it is sized
> > independently from the other generations. Generally, sizing of this
> > generation can be ignored because the default size is adequate. However,
> > programs that load many classes may need a larger permanent generation."
> >
> > They go on to say: "For instance, some implementations of JSPTM pages do
> > this. If necessary, the maximum permanent generation size can be
> > increased with MaxPermSize."
> >
> >
> > I've seen this happen when I redeploy tomcat many times without a
> > restart (we have a lot of JSP pages).
> >
> > Try adding:
> >
> > -XX:PermSize=128m -XX:MaxPermSize=128m
> >
> > To your startup script, JAVA_OPTS, or whatever...
> >
> > http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html
> > http://java.sun.com/docs/hotspot/gc1.4.2/faq.html
> >
> > -l
> >
> >
> > -----Original Message-----
> > From: Torgeir Veimo [mailto:torgeir@pobox.com]
> > Sent: Wednesday, October 18, 2006 8:56 AM
> > To: users@jackrabbit.apache.org
> > Subject: permgen error with jackrabbit 1.1
> >
> > I'm getting out of permgen space with jackrabbit running under tomcat
> > when the webapp has been reloaded enough times.
> >
> > I've been trying to find the problem using jconsole, and it appears
> > if I do a session.login(); and session.logout(), then a good number
> > of classes will not be unloaded after the webapp has been reloaded.
> > I'm using TransientRepository and the following repository.xml file:
> >
> > <Repository>
> >      <FileSystem
> > class="org.apache.jackrabbit.core.fs.local.LocalFileSystem">
> >          <param name="path" value="${rep.home}/repository"/>
> >      </FileSystem>
> >      <Security appName="Jackrabbit">
> >          <AccessManager
> > class="org.apache.jackrabbit.core.security.SimpleAccessManager"/>
> >          <LoginModule
> > class="org.apache.jackrabbit.core.security.SimpleLoginModule">
> >             <!-- anonymous user name ('anonymous' is the default
> > value) -->
> >             <param name="anonymousId" value="anonymous"/>
> >          </LoginModule>
> >      </Security>
> >      <Workspaces rootPath="${rep.home}/workspaces"
> > defaultWorkspace="default" />
> >      <Workspace name="${wsp.name}">
> >          <FileSystem
> > class="org.apache.jackrabbit.core.fs.local.LocalFileSystem">
> >              <param name="path" value="${wsp.home}"/>
> >          </FileSystem>
> >          <PersistenceManager
> > class="org.apache.jackrabbit.core.state.xml.XMLPersistenceManager" />
> >          <SearchIndex
> > class="org.apache.jackrabbit.core.query.lucene.SearchIndex">
> >              <param name="path" value="${wsp.home}/index"/>
> >              <param name="autoRepair" value="true"/>
> >              <param name="analyzer"
> > value="org.apache.lucene.analysis.standard.StandardAnalyzer"/>
> >              <param name="textFilterClasses"
> >
> > value="org.apache.jackrabbit.core.query.HTMLTextFilter,org.apache.jackra
> >
> > bbit.core.query.XMLTextFilter"/>
> >          </SearchIndex>
> >      </Workspace>
> >      <Versioning rootPath="${rep.home}/versions">
> >          <FileSystem
> > class="org.apache.jackrabbit.core.fs.local.LocalFileSystem">
> >              <param name="path" value="${rep.home}/versions"/>
> >          </FileSystem>
> >          <PersistenceManager
> > class="org.apache.jackrabbit.core.state.xml.XMLPersistenceManager" />
> >      </Versioning>
> > </Repository>
> >
> > The code that is running and using Jackrabbit is limited to this:
> >
> > String rootDirectory = (String) ConfigManager.getEnvironmentEntry
> > ("jackrabbit/directory");
> > String configFile = (String) ConfigManager.getEnvironmentEntry
> > ("jackrabbit/configfile");
> >
> > URL url = event.getServletContext().getResource(configFile);
> > InputStream repositoryXml = event.getServletContext
> > ().getResourceAsStream(configFile);
> > RepositoryConfig config = RepositoryConfig.create(repositoryXml,
> > rootDirectory);
> > repository = new TransientRepository(config);
> >
> > Session session = repository.login();
> > session.logout();
> >
> >
> > --
> > Torgeir Veimo
> > torgeir@pobox.com
> >
> >
> >
> >
>
>

Mime
View raw message