[JBoss JIRA] Updated: (WELD-76) OOME on servlet container redeployment
by Pete Muir (JIRA)
[ https://jira.jboss.org/jira/browse/WELD-76?page=com.atlassian.jira.plugin... ]
Pete Muir updated WELD-76:
--------------------------
Fix Version/s: 1.0.1.CR1
(was: 1.0.0.GA)
> OOME on servlet container redeployment
> --------------------------------------
>
> Key: WELD-76
> URL: https://jira.jboss.org/jira/browse/WELD-76
> Project: Weld
> Issue Type: Bug
> Reporter: Christian Bauer
> Priority: Critical
> Fix For: 1.0.1.CR1
>
>
> Redeploying /examples/wicket/numberguess (no code changes, just repeated deploy/undeploy cycles) to Jetty, running from within IntelliJ but in a separate VM.
> With default max heap size (JConsole reports 84 MB) after 3 redeployment cycles or with Xmx256m after about 10 cycles, the VM simply hangs at 100% CPU load with a full heap and the log:
> [Timer-1] 07:57:54,804 DEBUG [org.jboss.webbeans.bootstrap.AbstractBeanDeployer] Bean: Built-in implicit javax.inject.Instance bean
> [Timer-1] 07:57:54,805 DEBUG [org.jboss.webbeans.bootstrap.AbstractBeanDeployer] Bean: org.jboss.webbeans.bean-web-module-NewManagedBean-org.jboss.webbeans.wicket.BeanManagerLookup
> [Timer-1] 07:57:54,806 DEBUG [org.jboss.webbeans.bootstrap.AbstractBeanDeployer] Bean: org.jboss.webbeans.bean-web-module-NewManagedBean-org.jboss.webbeans.conversation.NumericConversationIdGenerator
> [Timer-1] 07:57:55,879 DEBUG [org.jboss.webbeans.bootstrap.AbstractBeanDeployer] Bean: org.jboss.webbeans.bean-web-module-NewManagedBean-org.teleal.hub.bookmarks.ui.HelloWorld
> [Timer-1] 07:57:55,881 DEBUG [org.jboss.webbeans.bootstrap.WebBeansBootstrap] Web Beans initialized. Validating beans.
> (Had to stop the process with KILL signal.)
> Sometimes it doesn't hang and I get this instead:
> java.lang.OutOfMemoryError: Java heap space
> at java.util.jar.Attributes.read(Attributes.java:377)
> at java.util.jar.Manifest.read(Manifest.java:182)
> at java.util.jar.Manifest.<init>(Manifest.java:52)
> at java.util.jar.JarFile.getManifestFromReference(JarFile.java:165)
> at java.util.jar.JarFile.getManifest(JarFile.java:146)
> at sun.misc.URLClassPath$JarLoader$2.getManifest(URLClassPath.java:693)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:221)
> at java.net.URLClassLoader.access$000(URLClassLoader.java:56)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
> at org.mortbay.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:392)
> at org.mortbay.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:363)
> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:374)
> at java.lang.Class.getDeclaredFields0(Native Method)
> at java.lang.Class.privateGetDeclaredFields(Class.java:2291)
> at java.lang.Class.getDeclaredFields(Class.java:1743)
> at org.jboss.webbeans.introspector.jlr.WBClassImpl.<init>(WBClassImpl.java:210)
> at org.jboss.webbeans.introspector.jlr.WBClassImpl.of(WBClassImpl.java:130)
> at org.jboss.webbeans.resources.ClassTransformer$1.call(ClassTransformer.java:59)
> at org.jboss.webbeans.resources.ClassTransformer$1.call(ClassTransformer.java:55)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at org.jboss.webbeans.util.collections.ConcurrentCache.putIfAbsent(ConcurrentCache.java:125)
> at org.jboss.webbeans.resources.ClassTransformer.loadClass(ClassTransformer.java:54)
> at org.jboss.webbeans.introspector.jlr.WBClassImpl.<init>(WBClassImpl.java:146)
> at org.jboss.webbeans.introspector.jlr.WBClassImpl.of(WBClassImpl.java:130)
> at org.jboss.webbeans.resources.ClassTransformer$1.call(ClassTransformer.java:59)
> at org.jboss.webbeans.resources.ClassTransformer$1.call(ClassTransformer.java:55)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at org.jboss.webbeans.util.collections.ConcurrentCache.putIfAbsent(ConcurrentCache.java:125)
> With Xmx1024m, after about 20 cycles:
> java.lang.OutOfMemoryError: PermGen space
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:675)
> at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
> at java.net.URLClassLoader.access$000(URLClassLoader.java:56)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
> at org.mortbay.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:392)
> at org.mortbay.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:363)
> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:374)
> at org.apache.wicket.settings.Settings.<init>(Settings.java:139)
> at org.apache.wicket.Application.getSettings(Application.java:874)
> at org.apache.wicket.Application.getPageSettings(Application.java:545)
> at org.apache.wicket.Application.internalInit(Application.java:972)
> at org.apache.wicket.protocol.http.WebApplication.internalInit(WebApplication.java:551)
> at org.jboss.webbeans.wicket.WebBeansApplication.internalInit(WebBeansApplication.java:71)
> at org.apache.wicket.protocol.http.WicketFilter.init(WicketFilter.java:693)
> at org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:97)
> at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
> at org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:658)
> at org.mortbay.jetty.servlet.Context.startContext(Context.java:140)
> at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1250)
> at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517)
> at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:467)
> at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
> at org.mortbay.jetty.deployer.ContextDeployer.deploy(ContextDeployer.java:268)
> at org.mortbay.jetty.deployer.ContextDeployer.redeploy(ContextDeployer.java:287)
> at org.mortbay.jetty.deployer.ContextDeployer.access$100(ContextDeployer.java:67)
> at org.mortbay.jetty.deployer.ContextDeployer$ScannerListener.fileChanged(ContextDeployer.java:99)
> at org.mortbay.util.Scanner.reportChange(Scanner.java:464)
> at org.mortbay.util.Scanner.reportDifferences(Scanner.java:330)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 6 months
[JBoss JIRA] Updated: (WELD-59) Clustered WebBeans, no support for sessionscoped (and higher) replication
by Pete Muir (JIRA)
[ https://jira.jboss.org/jira/browse/WELD-59?page=com.atlassian.jira.plugin... ]
Pete Muir updated WELD-59:
--------------------------
Fix Version/s: 1.0.1.CR1
(was: 1.0.0.GA)
> Clustered WebBeans, no support for sessionscoped (and higher) replication
> -------------------------------------------------------------------------
>
> Key: WELD-59
> URL: https://jira.jboss.org/jira/browse/WELD-59
> Project: Weld
> Issue Type: Bug
> Components: Scopes & Contexts
> Affects Versions: 1.0.0.PREVIEW1
> Environment: JBoss AS 5.1 + JDK 6
> Reporter: John Ament
> Fix For: 1.0.1.CR1
>
> Attachments: ClusteredWebBeansTestApp.zip, ClusteredWebBeansTestApp.zip
>
>
> From what I can tell, this is what happens.
> Assume you have a 2 node environment w/ apache httpd + mod_jk in front of the jboss servers, used to limit servers exposed + a loadbalancer (F5 ASM) in front of those. The apache servers are only configured to talk to one jboss server each (httpd + jboss are on same box, they only talk to the local client). the f5 serving the initial request is configured for pure round robin (no cookie persistence) and as a result request 1 could go to server 1 and then request 2 goes to server 2.
> Now assume that the two jboss servers are clustered together, the EJBs are clustered and have a cache policy (based on the JBoss annotations). They only have local interfaces. In addition, there are some classes that are only POJOs; but they sit in the ejb module. Based on what's happening these objects should be replicated as part of the HTTP session state.
> A few problems seem to occur when the request goes to the second server after the first request goes to the first server.
> 1. References to the resources required by the EJBs are not injected in the second server. This includes members decorated @Resource or @PersistenceContext
> 2. References to EJBs required at the view level are not restored.
> In addition, concurrent modification exceptions seem to be more likely when deployed like this, resulting in having to downgrade EJBs to POJOs in order to remain stateful.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 6 months