--
You received this message because you are subscribed to the Google Groups "Payara Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to payara-forum...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/payara-forum/3b0495e68b97fd56277a95cf1bf37484b5c403e7.camel%40gmail.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/payara-forum/FE39D49C-88D9-4C67-B8FC-B04B84E09139%40gmail.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/payara-forum/CAOF9RgDG%2B8Q6Lsdb%3D1Ve1Zd3%2BT_UUCAOdS8GzkTJyX%3DiOTayGQ%40mail.gmail.com.
Normally this indicates memory leaks due to ClassLoaders not being released. Now we do test Payara for Classloader memory leaks on redeployment regularly but it is also possible for some to slip through. However it could also be caused by the application you are deploying if you keep references to application class instances in thread locals or global caches etc.
Simplest way to debug this is deploy the application. Do a Heap Dump and use a memory analyser tool like Eclipse MAT to look for instances of WebAppClassLoader in the dump. Then undeploy you application force a few GCs and then do a Heap Dump again and (assuming your application is a war) you should see the number of instances of WebAppClassLoader decrease by 1. Rinse and repeat. If the number of WebAppClassLoader instances keeps increasing by one on every cycle you have a ClassLoader leak. In that case you need to find the GC Roots that are holding onto these WebAppClassLoader instances. That’s normally not too difficult using MAT but can be fiddly.
That’s how we track them down in our testing
Steve