Sometimes you might want to mention the JVM details too. But it looks moe of a code issue rather than a configuration one..<br><br>Regards,<br>jd<br><br><div class="gmail_quote">On Tue, Jul 13, 2010 at 6:14 PM, jitesh dundas <span dir="ltr"><<a href="mailto:jiteshbdundas@gmail.com">jiteshbdundas@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">If I am not wrong, you need to add some Bean for this..Managed Bean..I think the experts will help you more on this..<br>
<br>Actually, just google on this ...<br><br>Regards,<br><font color="#888888">jd</font><div><div></div><div class="h5"><br><br><div class="gmail_quote">On Tue, Jul 13, 2010 at 6:08 PM, Jari Juslin <span dir="ltr"><<a href="mailto:zds@iki.fi" target="_blank">zds@iki.fi</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hello,<br>
<br>
everybody.<br>
<br>
I have a problem with JBoss leaking memory over repeated re-deployments<br>
of same ear file. Obviously the ear file changes slightly between the<br>
re-deploys, but name is the same, so it should replace the old one<br>
entirely on each re-reploy.<br>
<br>
Over time, after dozen or so hot-re-deploys, JBoss stops to<br>
OutOfMemoryError at deploy time. To trace the issue I captured full<br>
memory dump and analyzed it with Ecliple Memory Analysis Tool. Here is a<br>
screenshot from the data it shows:<br>
<<a href="http://zds.iki.fi/zds/temp/jboss_leak_0.png" target="_blank">http://zds.iki.fi/zds/temp/jboss_leak_0.png</a>><br>
<br>
And the main leak point as text:<br>
<br>
One instance of "org.jboss.mx.server.MBeanServerImpl" loaded by<br>
"org.jboss.classloader.spi.base.BaseClassLoader @ 0x7ffe9d4baa50"<br>
occupies 83 098 176 (21,06%) bytes. The memory is accumulated in one<br>
instance of<br>
"EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap$Entry[]"<br>
loaded by "org.jboss.bootstrap.NoAnnotationURLClassLoader @<br>
0x7ffe9c604bb8".Keywords<br>
org.jboss.bootstrap.NoAnnotationURLClassLoader @ 0x7ffe9c604bb8<br>
org.jboss.classloader.spi.base.BaseClassLoader @ 0x7ffe9d4baa50<br>
org.jboss.mx.server.MBeanServerImpl<br>
EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap$Entry[]<br>
<br>
Looking further down the object tree, I get drown to sea of interlinked<br>
HashMaps. It would seem the memory leak, if it exists, is about having<br>
lots and lots of internal bookkeeping information gathered in small<br>
pieces to interlinked network of object references.<br>
<br>
So, the question is, what can I do to this?<br>
<br>
<br>
-Jari<br>
_______________________________________________<br>
jboss-user mailing list<br>
<a href="mailto:jboss-user@lists.jboss.org" target="_blank">jboss-user@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/jboss-user" target="_blank">https://lists.jboss.org/mailman/listinfo/jboss-user</a><br>
</blockquote></div><br>
</div></div></blockquote></div><br>