you should choose a very good profiler, which can do longtime observation of servers.
Then you'll should trace it. I don't think that the jboss as has this issue. We're running
several jboss-instances which are running much longer than 14 days. On the other hand
a memory leak is a difficult point which is often hard to find. And, of course, often, but not
everytime, the leaks are found in the personal code. So it's really hard to find a solution for
such leaks in a forum.
I am thankful to you for your reply.
i already use Eclipse Memory analyser for the heap analysis and found that MBeanServerImpl Objects are getting loaded and getting accumalated.
i also read about Orphen Class loaders.
still not clear how to make them clean.
i already have attached image shown in Eclipse memory A.
leak.jpg 4.0 MB
just having this information doesn't help much. But I would say you should have a look at your own code.
I think this happens after a deployment of your application. So if it's an application you sholud look
for what is happening within the classloader of the application. When it's an mbean you should have
a look for the classes loaded there.
Profiling and finding memory-leaks isn't such an easy thing. May be you should also try another profiler than the
Eclipse TPTP. Some of them have some more specialized features, which may help finding your leakage.
i also checked with YourKit profililer i could only see that there are EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock instances gettign acumalated in memory. JMSManagedConnection is holding this. is there any way to cleanup this.
apart from this i can see many instances of org.hibernate.hql.ast.util.JoinProcessor, i'm not sure if its normal if not how to clean them up.
the org.hibernate.hql.ast.util.JoinProcessor is part of hibernate as it says the name. If you're using hibernate (directly or indirectly) these come up if you've got join's which I would expect. If you don't work in the depth of hibernate internals you should have no troubles with them.
If they still increase and aren't cleaned up you'll should check your application code and configuration.
The other one is part of the JBoss internals, which you can use of course, if you don't they may be an indicator for an issue but personally I think that they're related to the normal usage of jboss.
At first I'd like to repeat: "If you find a hoof print in europe you would say that's one of a horse and not one of a zebra." What I mean: The memory issue is mostly an issue of added deployments or configurations. It's mostly not an issue of the applicationserver itself.
To help you I need definately some more information:
a) What are you deploying (mbeans, beans, entities, war's,...)?
b) Do you spawn threads?
c) Do you make use of jms?
d) Any other specialities?
e) Any proprietary libraries?
Due to the fact that your application uses more and more memory over 14 days make me believe that you've got something which will
be called regular and doesn't release the objects. Do you have custom mbeans? What about your sessionbeans? Do the stateless have any class-level fields? What about the stateful? Are there any Lists which are filled and not released (such as class-level fields)?
We have all kind of stuff you mentioned.
b) Stateless Session Beans.
c) we do NOT have Stateful session bean.
d) Extensive use of JMS as a eventing system. (every client creates a connection and wait for messages which are publised 5 msg/sec or more).
as per your questions.
a) What are you deploying (mbeans, beans, entities, war's,...)? Yes.
b) Do you spawn threads? NO
c) Do you make use of jms? Extensive
d) Any other specialities? live server and has live connected clients (RMI and SOAP)
e) Any proprietary libraries? NA
somehow we got the issue with our own way of using some native library. so is is fixed.
thanks a lot.