[Resin-interest] Resin loads web-fragment.xml for servlet 2.5 web applications
Hello everyone, when deploying a servlet 2.5 web application which contains a jar which itself contains a servlet 3.0 web-fragment.xml resin 4.0 will load this web fragment and initializes/enables all defined filters/listeners etc. However, I would expect that resin ignores web fragments for web applications with a servlet version less than 3.0. Is there a way to force resin to do that? Thank you and best regards, Patric ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Resin classloader leak (possibly caused by the host:default classloader)
Hello everyone, it seems that resin 4.0.23 suffers from a classloader leak. My application's classloader is prevented from being garbage collected. Please have a look at the GC Roots of my applications classloader (after stopping the application and a full garbage collection): Class Name | Retained Heap - com.caucho.env.thread.ResinThread @ 0xe27c9a60 http://*:18443-14 Thread |584 '- com.caucho.network.listen.TcpSocketLinkListener @ 0xe0b86878 | 2.976 '- _suspendAlarm com.caucho.util.Alarm @ 0xe279e330 |760 '- class com.caucho.util.Alarm @ 0xd03f86c0 |480.928 '- _clock com.caucho.util.AlarmClock @ 0xe0aab790 |480.720 '- _clockArray com.caucho.util.Alarm[6] @ 0xe0ac4160 |480.288 '- [15927] com.caucho.util.Alarm @ 0xe8467708 |264 '- _contextLoader com.caucho.loader.EnvironmentClassLoader @ 0xe12f7718 |151.424 '- parent com.caucho.loader.EnvironmentClassLoader @ 0xe11fbde8 |483.344 '- _attributes java.util.concurrent.ConcurrentHashMap @ 0xe11bef38 |392.408 '- segments java.util.concurrent.ConcurrentHashMap$Segment[16] @ 0xe11bef68 |392.336 '- [1] java.util.concurrent.ConcurrentHashMap$Segment @ 0xe11c2a40 |377.016 '- table java.util.concurrent.ConcurrentHashMap$HashEntry[2] @ 0xe11c2a88 |376.920 '- [0] java.util.concurrent.ConcurrentHashMap$HashEntry @ 0xe11c2aa0 |376.880 '- value com.caucho.jsp.el.JspApplicationContextImpl @ 0xe11bbac8 | 376.832 '- _webApp com.caucho.server.webapp.WebApp @ 0xe12103a8 | 84.256 '- _classLoader com.caucho.loader.EnvironmentClassLoader @ 0xe12108c0|129.894.632 -- As you can see three EnvironmentClassLoaders are involved: 0xe12108c0, which is my application classloader (consuming 129 MB of the heap) 0xe11fbde8, which is the classloader with the id host:default 0xe12f7718, which is the classloader for the resin-admin application (which most probably is not important in this case) As you can see, the host:default classloader is still referencing my web application's classloader indirectly (by the entryCache_ Map, referencing to the com.caucho.jsp.el.JspApplicationContextImpl of my web application). What do I have to do to in order that my application classloader can be garbage collected? Thank you and best regards, Patric ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Possible Resin Classloader leakage for JPA applications
Hi Scott, after testing resin 4.0.20 it seems that the reported bug has been fixed. However, there's still another JPA classloader leak which prevents the web application classloader being garbage collected. Because I am not allowed to add a comment to bug 4628 at your mantis site, I am going to report it here: The cause of the issue is that resin loads the JPA implementation library included within a web application (e.g. EclipseLink) with the global classloader instead of the web application's classloader. (why?) As a result, after stopping the web application these classes remain loaded. What makes this even worse is that if a JPA implementation class refers to a class of my web application which is quite common (if you think of hooks, configuration classes etc.) the web application classloader also remains referenced and prevents its garbage collection forever. Best regards, Patric Quoting Patric Rufflar : >> >> Thanks. I've filed this as http://bugs.caucho.com/view.php?id=4628 >> > Thank you for fixing the bug so quickly. > Is it possible to backport it to 3.1 as well? > (if not: is a workaround available?) > > Thanks. > > Patric > >> >>> Please have a look at >>> resin-3.1.10\modules\jpa\src\javax\persistence\Persistence.java >>> >>> On line 51 there's a WeakHashMap defined, which maps the classloader >>> to the corresponding PersistenceProvider instances: >>> >>> private static WeakHashMap >>>_providerMap = new WeakHashMap(); >>> >>> >>> The problem is that a PersistenceProvider instance may reference the >>> key indirectly >>> (which is at least true when not using Amber, e.g. EclipseLink) >>> The loaded class will of course reference its classloader, which is >>> the web application's classloader. >>> However according to the javadocs this will prevent the removal of >>> the entry: >>> >>> "Thus care should be taken to ensure that value objects do not >>> strongly refer to their own keys, >>> either directly or indirectly, since that will prevent the keys from >>> being discarded." >>> >>> With the consequence that the EnvironmentClassLoader cannot be garbage >>> collected. >>> >>> When looking at the GC roots (for a classloader from a stopped application) >>> this can be seen easily: >>> >>> Class Name >>>| Shallow Heap | Retained Heap >>> -- >>> com.caucho.loader.EnvironmentClassLoader @ 0xe68362d0 >>>| 376 | 131.077.664 >>> '- class org.eclipse.persistence.jpa.PersistenceProvider >>> @ 0xd3bda6d8|0 | 0 >>> '- org.eclipse.persistence.jpa.PersistenceProvider @ >>> 0xe7bb2010 | 24 |40 >>> '- [3] javax.persistence.spi.PersistenceProvider[4] @ >>> 0xe7bb2020 | 56 | 144 >>> '- value java.util.WeakHashMap$Entry @ 0xe7c72ca8 >>> | 72 | 432 >>>'- [11] java.util.WeakHashMap$Entry[16] @ 0xe118fc18 >>> | 152 | 800 >>> '- table java.util.WeakHashMap @ 0xe118fbe8 >>> | 72 | 928 >>> '- _providerMap class javax.persistence.Persistence >>> @ 0xd1fc55a8 | 32 | 960 >>> '- [1152] java.lang.Object[1280] @ 0xe0b40378 >>> | 10.264 | 1.774.424 >>> -- >>> >>> As you can see, the second last line (_providerMap class >>> javax.persistence.Persistence @ 0xd1fc55a8) which is actually >>> a caucho class, references the old EnvironmentClassLoader. >>> So in my case, 131 MB will not get released. >>> >>> If I am right - is there a workaround available? >>> (Is it possible to configure the EnvironmentClassLoader that it >>> will not load >>> the PersistenceProvider/Persistence class from Amber but from the JPA >>> implementation which my application provides?) >>> >>> Thank you and best regards, >>> Patric >>> >>> >>> >>> >>> ___ >>> resin-interest mailing list >>> resin-interest@caucho.com >>> http://maillist.caucho.com/mailman/listinfo/resin-interest >>> >> >> >> >> ___ >> resin-interest mailing list >> resin-interest@caucho.com >> http://maillist.caucho.com/mailman/listinfo/resin-interest > > > > ___ > resin-interest mailing list > resin-interest@caucho.com > http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Possible Resin Classloader leakage for JPA applications
> > Thanks. I've filed this as http://bugs.caucho.com/view.php?id=4628 > Thank you for fixing the bug so quickly. Is it possible to backport it to 3.1 as well? (if not: is a workaround available?) Thanks. Patric > >> Please have a look at >> resin-3.1.10\modules\jpa\src\javax\persistence\Persistence.java >> >> On line 51 there's a WeakHashMap defined, which maps the classloader >> to the corresponding PersistenceProvider instances: >> >> private static WeakHashMap >>_providerMap = new WeakHashMap(); >> >> >> The problem is that a PersistenceProvider instance may reference the >> key indirectly >> (which is at least true when not using Amber, e.g. EclipseLink) >> The loaded class will of course reference its classloader, which is >> the web application's classloader. >> However according to the javadocs this will prevent the removal of the entry: >> >> "Thus care should be taken to ensure that value objects do not >> strongly refer to their own keys, >> either directly or indirectly, since that will prevent the keys from >> being discarded." >> >> With the consequence that the EnvironmentClassLoader cannot be garbage >> collected. >> >> When looking at the GC roots (for a classloader from a stopped application) >> this can be seen easily: >> >> Class Name >>| Shallow Heap | Retained Heap >> -- >> com.caucho.loader.EnvironmentClassLoader @ 0xe68362d0 >>| 376 | 131.077.664 >> '- class org.eclipse.persistence.jpa.PersistenceProvider >> @ 0xd3bda6d8|0 | 0 >> '- org.eclipse.persistence.jpa.PersistenceProvider @ >> 0xe7bb2010 | 24 |40 >> '- [3] javax.persistence.spi.PersistenceProvider[4] @ >> 0xe7bb2020 | 56 | 144 >> '- value java.util.WeakHashMap$Entry @ 0xe7c72ca8 >> | 72 | 432 >>'- [11] java.util.WeakHashMap$Entry[16] @ 0xe118fc18 >> | 152 | 800 >> '- table java.util.WeakHashMap @ 0xe118fbe8 >> | 72 | 928 >> '- _providerMap class javax.persistence.Persistence >> @ 0xd1fc55a8 | 32 | 960 >> '- [1152] java.lang.Object[1280] @ 0xe0b40378 >> | 10.264 | 1.774.424 >> -- >> >> As you can see, the second last line (_providerMap class >> javax.persistence.Persistence @ 0xd1fc55a8) which is actually >> a caucho class, references the old EnvironmentClassLoader. >> So in my case, 131 MB will not get released. >> >> If I am right - is there a workaround available? >> (Is it possible to configure the EnvironmentClassLoader that it will not load >> the PersistenceProvider/Persistence class from Amber but from the JPA >> implementation which my application provides?) >> >> Thank you and best regards, >> Patric >> >> >> >> >> ___ >> resin-interest mailing list >> resin-interest@caucho.com >> http://maillist.caucho.com/mailman/listinfo/resin-interest >> > > > > ___ > resin-interest mailing list > resin-interest@caucho.com > http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Possible Resin Classloader leakage for JPA applications
Hi all, I think that resin (at least version 3.1, but most probably 4.0 too) suffers from a critical classloader leak which may cause that the memory occupied by an application will not get released when destroying its servlet context (stopping/redeploying the application). As an result, further restarts/redeployments will sooner or later result in an OutOfMemoryError. Please have a look at resin-3.1.10\modules\jpa\src\javax\persistence\Persistence.java On line 51 there's a WeakHashMap defined, which maps the classloader to the corresponding PersistenceProvider instances: private static WeakHashMap _providerMap = new WeakHashMap(); The problem is that a PersistenceProvider instance may reference the key indirectly (which is at least true when not using Amber, e.g. EclipseLink) The loaded class will of course reference its classloader, which is the web application's classloader. However according to the javadocs this will prevent the removal of the entry: "Thus care should be taken to ensure that value objects do not strongly refer to their own keys, either directly or indirectly, since that will prevent the keys from being discarded." With the consequence that the EnvironmentClassLoader cannot be garbage collected. When looking at the GC roots (for a classloader from a stopped application) this can be seen easily: Class Name | Shallow Heap | Retained Heap -- com.caucho.loader.EnvironmentClassLoader @ 0xe68362d0 | 376 | 131.077.664 '- class org.eclipse.persistence.jpa.PersistenceProvider @ 0xd3bda6d8|0 | 0 '- org.eclipse.persistence.jpa.PersistenceProvider @ 0xe7bb2010 | 24 |40 '- [3] javax.persistence.spi.PersistenceProvider[4] @ 0xe7bb2020 | 56 | 144 '- value java.util.WeakHashMap$Entry @ 0xe7c72ca8 | 72 | 432 '- [11] java.util.WeakHashMap$Entry[16] @ 0xe118fc18 | 152 | 800 '- table java.util.WeakHashMap @ 0xe118fbe8 | 72 | 928 '- _providerMap class javax.persistence.Persistence @ 0xd1fc55a8 | 32 | 960 '- [1152] java.lang.Object[1280] @ 0xe0b40378 | 10.264 | 1.774.424 -- As you can see, the second last line (_providerMap class javax.persistence.Persistence @ 0xd1fc55a8) which is actually a caucho class, references the old EnvironmentClassLoader. So in my case, 131 MB will not get released. If I am right - is there a workaround available? (Is it possible to configure the EnvironmentClassLoader that it will not load the PersistenceProvider/Persistence class from Amber but from the JPA implementation which my application provides?) Thank you and best regards, Patric ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Eclipse plugin: How to create a resin 3.1 server?
Hi, I just installed the most recent release of the Resin Eclipse plugin. However, I cannot create resin 3.1 servers. (Only "resin 4.0" is shown in the "New server" dialog) This was possible in previous releases of that plugin. Is this an intentional behavior? Thank you and best regards, Patric ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
