What timing.  I checked the link went I sent the response, and it was up,
but it is indeed coming up blank now.

Google cache to the rescue!

Here is the bit that deals with the Introspector.  You should still check
the page sometime later for the other possible causes and fixes, however, as
there are too many to list concisely here.  Google cache also has the whole
thing if you do a search for the link.  Sorry if it doesn't all make sense,
it is taken right out of the middle of the article, so it loses some of its
context.


clipped:
-------------------------------------------------------------------------------------
Here's what you will need to add to the web.xml.

<listener>
        <listener-class>com.browermedia.ShutDownListener</listener-class>
</listener>

This registers the listener, who's 'contextDestroyed()' method will be
called during the hot shutdown/restart process.
java.beans.Introspector - Slightly less Evil singleton

Another JVM level singleton is java.beans.Introspector. This case is at the
heart of the Java Beans API, and it maintains a cache of all inspected
classes. Since its loaded by the system classloader, ALL classes in ALL
applications could be cached by it. And a lot of Java API's could potenially
make use of it, meaning all their classloaders stay around forever (or
shutdown). Since Spring <http://www.springframework.org/> is big on Java
beans, this is a discussion they have come across. You can find a thread
discussing the details
here<http://article.gmane.org/gmane.comp.java.springframework.devel/6562>.

The solution is similar to the DriverManager, you need to clean up during
shutdown. If you are using Spring, you can use their
'IntrospectorCleanupListener' class, or add this to our ShutDownListener.

public void contextDestroyed(ServletContextEvent event) {
    // Driver Clean up stuff omitted

    // Flushes the cache of classes
    java.beans.Introspector.flushCaches();
}

This is going to clear ALL the classes, regardless of what ClassLoader or
application they came from, but its all that available.

------------------------------------------------------------------------------------------

HTH,

Spencer





On 1/25/06, Cliff Zhao <[EMAIL PROTECTED]> wrote:
>
> I got a blank page for the link. Can you get the page now?
>
> On 1/25/06, Spencer Crissman <[EMAIL PROTECTED]> wrote:
> >
> > I haven't had this happen recently, so I'm not sure if this is the same
> as
> > the Perm Gen error, but the following link details several causes of the
> > JVM
> > potentially running out of memory on hot redeploys of web
> > applications.  We
> > had one web app that was doing this fairly often, and implementing the
> > fixes
> > that are described eliminated the errors for us.
> >
> > http://www.patrickpeak.com/page/patrick/20050614#your_web_app_is_leaking
> >
> > I would imagine the java bean introspection is the most likely source of
> > your troubles, given the amount of reliance Tapestry has on it.  Any
> java
> > bean class that gets introspected is added to the JVM's
> > java.beans.Introspector's cache, which hangs around indefinitely unless
> > flushed.  This means that each time you redeploy, an additional copy of
> > each
> > class that gets introspected gets added to the cache, and can cause your
> > memory space to fill up.
> >
> > The link has the details for the fix, along with other potential gotchas
> > if
> > that does not help.
> >
> > Spencer
> >
> >
> > On 1/25/06, Ivano <[EMAIL PROTECTED]> wrote:
> > >
> > > Could it be that, redeploying the application, JBoss creates a new
> > > associated classloader, without releasing old classes and thus filling
> > > up the memory space?
> > >
> > > Ivano Pagano
> > >
> > > Jason Dyer wrote:
> > >
> > > >I can't find the link right now, but I remember reading that when you
> > > load a
> > > >class, it gets stored in PermGen memory.  The problem is that
> > (apparently
> > > and
> > > >AFAICR) when a new version of a class is loaded, the old version is
> > never
> > > >released from PermGen (Permanent Generation memory...)
> > > >
> > > >This was specifically blamed on the JVM, and not a Tomcat bug.  The
> > fact
> > > that
> > > >it seems to happen with JBoss as well would tend to support that
> > > assertion.
> > > >
> > > >-Jason
> > > >
> > > >On Wednesday 25 January 2006 10:52, Sergiy Kyrylkov wrote:
> > > >
> > > >
> > > >>Here is more
> > > >>
> > > >>http://wiki.jboss.org/wiki/Wiki.jsp?page=OutOfMemoryExceptions
> > > >>
> > > >>Jason, what makes you think it is a JVM issue?
> > > >>
> > > >>Sergiy
> > > >>
> > > >>
> > > >>
> > > >>>-----Original Message-----
> > > >>>From: Jason Dyer [mailto:[EMAIL PROTECTED]
> > > >>>Sent: Wednesday, January 25, 2006 5:44 PM
> > > >>>To: Tapestry users
> > > >>>Subject: Re: OutOfMemoryError
> > > >>>
> > > >>>I had the same problem with tomcat.  You can delay it by increasing
> > > >>>permanent
> > > >>>memory to the JVM, but the only real fix seems to be restarting on
> > > >>>deploy...
> > > >>>
> > > >>>Apparently this is a JVM issue, not particular to any app server.
> > > >>>
> > > >>>On Wednesday 25 January 2006 10:38, Cliff Zhao wrote:
> > > >>>
> > > >>>
> > > >>>>After several times redeploy my war file in JBoss 4.0.3SP1, I get
> > this
> > > >>>>error: java.lang.OutOfMemoryError: PermGen space
> > > >>>>
> > > >>>>Any advice?
> > > >>>>
> > > >>>>Thanks.
> > > >>>>
> > > >>>>
> > > >>>--
> > > >>>Immortality consists largely of boredom.
> > > >>>             -- Zefrem Cochrane, "Metamorphosis", stardate 3219.8
> > > >>>--------------
> > > >>>Jason Dyer
> > > >>>BlueTarp Financial, inc.
> > > >>>
> > >
> >>>---------------------------------------------------------------------
> > > >>>To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> > > >>>For additional commands, e-mail:
> > [EMAIL PROTECTED]
> > > >>>
> > > >>>
> > >
> >>---------------------------------------------------------------------
> > > >>To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > >>For additional commands, e-mail:
> [EMAIL PROTECTED]
> > > >>
> > > >>
> > > >
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> >
>
>

Reply via email to