January 2010 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBPORTAL-2466) Native heap memory leak when rendering Portlet URLs causes JVM crash

by Patrik Gottfridsson (JIRA)

Native heap memory leak when rendering Portlet URLs causes JVM crash -------------------------------------------------------------------- Key: JBPORTAL-2466 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2466 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal Core Affects Versions: 2.7.2 Final Environment: Operating system: Linux 2.6.18-164.el5PAE #1 SMP Thu Sep 3 04:10:44 EDT 2009 i686 i686 i386 GNU/Linux JVM: Sun JRE 6.0_16-b01 Java heap settings: -Xms1024m -Xmx1024m -XX:+UseParallelGC -XX:MaxPermSize=256m Running JBoss Portal using "Simple Portal" taglibs in Tomcat 6.0.20 Reporter: Patrik Gottfridsson Under moderate load testing of a page containing thirtysome Portlet URLs, the JVM crashes quickly with various variants of the following stderr message: # A fatal error has been detected by the Java Runtime Environment: # # java.lang.OutOfMemoryError: requested 70968 bytes for Chunk::new. Out of swap space? # # Internal Error (allocation.cpp:215), pid=24331, tid=1870162832 # Error: Chunk::new # # JRE version: 6.0_16-b01 # Java VM: Java HotSpot(TM) Server VM (14.2-b01 mixed mode linux-x86 ) # An error report file with more information is saved as: .. Lowering the Java heap size to 1/4 of the original size avoided the problem (but was for other reasons not acceptable). The problem was thus avoided when garbage collection was more frequent. This behaviour, in combination with the error message above, indicated that this was in fact a native heap leak and that this native memory was being freed when the Java garbage collector cleaned up Java objects and triggered their finalizers. One common case of native heap leak problems is using the GZipOutputStream for compression. The GZipOutputStream is a thin wrapper for native ZLIB resources which consume a lot of native memory. Creating a lot of GZipOuputStream objects without closing them can thus crash the JVM since ZLIB fills upp the native heap before the wrapping GZipOutputStream objects fill upp the Java heap and trigger a garbage collection. Looking at the JBoss Portal sources, GzipOutputStream is used to compress parameters in Portlet URLs. After compression, GZipOutstream.finish() is invoked but never GZipOutstream.close(). This leaves the ZLIB native resources hanging and causes a native heap leak. I manually patched org.jboss.portal.common.io.SerializationFilter to force a GZipOutstream.close(). This solved the problem and the application now behaves nicely under load also with large heap settings. It would be great to have this included in an official patch by changing public <T> void serialize(Serialization<T> serialization, T t, OutputStream out) throws IllegalArgumentException, IOException { GZIPOutputStream zos = new GZIPOutputStream(out); serialization.serialize(t, zos); zos.finish(); } to public <T> void serialize(Serialization<T> serialization, T t, OutputStream out) throws IllegalArgumentException, IOException { GZIPOutputStream zos = null; try { zos = new GZIPOutputStream(out); serialization.serialize(t, zos); zos.finish(); } finally { if (zos != null) { zos.close(); } } } or similar. -- 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

16 years, 6 months

1
0
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1973) Allow for better configurability of metadata processors in Ejb3MetadataProcessingDeployer

by jaikiran pai (JIRA)

Allow for better configurability of metadata processors in Ejb3MetadataProcessingDeployer ------------------------------------------------------------------------------------------ Key: EJBTHREE-1973 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1973 Project: EJB 3.0 Issue Type: Task Components: deployers Affects Versions: 1.1.22 Reporter: jaikiran pai Assignee: jaikiran pai The Ejb3MetadataProcessingDeployer right now runs the merged metadata through a chain of processors which are configured in MetadataUtil (ejb3-common). Any new processors, currently will have to be included in the list maintained by the MetadataUtil. This doesn't allow for cleaner way of adding new processors. For example, if a new processor specific to the no-interface component has to be added, then the following steps have to be done: 1) Update MetadataUtil in ejb3-common to include the new no-interface processor 2) Update the dependency on ejb3-common in ejb3-deployers to refer to the new version generated by step#1 3) This also doesn't allow the processor to be maintained within the no-interface component. And instead it needs to be present in the ejb3-common module for this to work. To get rid of all these issues, we need to make Ejb3MetadataProcessingDeployer more configurable where it can dynamically pull in new processors. Ejb3MetadataProcessingDeployer is a MC bean and MC allows for "incallback" wherein the Ejb3MetadataProcessingDeployer can listen for newly installed processors (which again can be MC beans). This way, the no-interface component can create a new processor and just make it available through its own -jboss-beans.xml file and the Ejb3MetadataProcessingDeployer will pull in this new processor. Furthermore, some processor require the DeploymentUnit (more specifically, the classloader of the DeploymentUnit) during instantiation. So ideally the Ejb3MetadataProcessingDeployer should listen for processor "factories" which are responsible for generating the processors (some of them per deployment unit). -- 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

16 years, 6 months

1
4
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1977) Change the packaging type of ejb3_1 component to jar

by jaikiran pai (JIRA)

Change the packaging type of ejb3_1 component to jar ---------------------------------------------------- Key: EJBTHREE-1977 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1977 Project: EJB 3.0 Issue Type: Task Components: ejb3_1 Affects Versions: EJB3_1 1.0.0 Reporter: jaikiran pai Assignee: jaikiran pai Fix For: EJB3_1 1.0.1 Right now the ejb3_1 component is pom packaging. Changing it to jar packaging will allow us to package any EJB3.1 runtime level configurations. -- 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

16 years, 6 months

1
1
0 / 0

[JBoss JIRA] Created: (JBMETA-248) JBoss Metadata Rar 2.0.0.Alpha5

by Jeff Zhang (JIRA)

JBoss Metadata Rar 2.0.0.Alpha5 ------------------------------- Key: JBMETA-248 URL: https://jira.jboss.org/jira/browse/JBMETA-248 Project: JBoss Metadata Issue Type: Release Security Level: Public (Everyone can see) Components: rar Reporter: Jeff Zhang Assignee: Jeff Zhang Fix For: 2.0.0.CR1 -- 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

16 years, 6 months

1
1
0 / 0

[JBoss JIRA] Created: (JBMETA-247) consolidate rar metadata for dtd 1.0 and xsd 1.5

by Jeff Zhang (JIRA)

consolidate rar metadata for dtd 1.0 and xsd 1.5 ------------------------------------------------ Key: JBMETA-247 URL: https://jira.jboss.org/jira/browse/JBMETA-247 Project: JBoss Metadata Issue Type: Task Security Level: Public (Everyone can see) Components: rar Reporter: Jeff Zhang Assignee: Jeff Zhang Fix For: 2.0.0.CR1 1.0: <!ELEMENT connector (display-name, description?, icon?, vendor-name, spec-version, eis-type, version, license?, resourceadapter)> <!ELEMENT resourceadapter ( managedconnectionfactory-class, connectionfactory-interface, connectionfactory-impl-class, connection-interface, connection-impl-class, transaction-support, config-property*, authentication-mechanism*, reauthentication-support, security-permission* )> 1.5: <!ELEMENT connector (description*, display-name*, icon*, vendor-name, eis-type, resourceadapter-version, license?, resourceadapter)> <!ELEMENT resourceadapter (resourceadapter-class?, config-property*, outbound-resourceadapter?, inbound-resourceadapter?, adminobject*, security-permission*)> <!ELEMENT outbound-resourceadapter ( connection-definition+, transaction-support, authentication-mechanism*, reauthentication-support)> <!ELEMENT connection-definition ( managedconnectionfactory-class, config-property*, connectionfactory-interface, connectionfactory-impl-class, connection-interface, connection-impl-class)> -- 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

16 years, 6 months

1
1
0 / 0

[JBoss JIRA] Created: (JBJCA-259) JBoss Metadata Rar 2.0.0.Alpha5

by Jeff Zhang (JIRA)

JBoss Metadata Rar 2.0.0.Alpha5 ------------------------------- Key: JBJCA-259 URL: https://jira.jboss.org/jira/browse/JBJCA-259 Project: JBoss JCA Issue Type: Sub-task Components: Build Reporter: Jeff Zhang Assignee: Jeff Zhang Fix For: 1.0.0.Alpha8 -- 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

16 years, 6 months

1
0
0 / 0

[JBoss JIRA] Created: (JBWEB-158) Thrown Errors while Context-Start are not logged

by Frank Stolle (JIRA)

Thrown Errors while Context-Start are not logged ------------------------------------------------ Key: JBWEB-158 URL: https://jira.jboss.org/jira/browse/JBWEB-158 Project: JBoss Web Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossWeb-2.1.2.GA Environment: JBoss 5.1.0.GA Reporter: Frank Stolle Assignee: Remy Maucherat I always got the following exception while deploying an application: 15:24:00,910 ERROR [AbstractKernelController] Error installing to Start: name=jboss.web.deployment:war=XXXXXXXXX/management state=Create mode=Manual requiredState=Installed org.jboss.deployers.spi.DeploymentException: URL file:/opt/jboss-5.1.0.GA/server/default/tmp/aaaa-44jwh6-g4fmqmf8-1-g4fmsf9j-9w/XXXXXXXX.war/ deployment failed at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:331) at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:142) at org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:461) at org.jboss.web.deployers.WebModule.startModule(WebModule.java:118) at org.jboss.web.deployers.WebModule.start(WebModule.java:97) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668) at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:206) at $Proxy38.start(Unknown Source) at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42) at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:37) ... No other error was logged. The reason was the following error, because a duplicate xml-api was in my classpath (my fault). I wrote a Context-listener which catched all Exceptions and Errors during initialization of Seam and so I got: java.lang.LinkageError: loader constraints violated when linking org/xml/sax/EntityResolver class at org.jboss.seam.util.XML.getRootElement(XML.java:22) at org.jboss.seam.init.Initialization.initComponentsFromXmlDocument(Initialization.java:227) at org.jboss.seam.init.Initialization.create(Initialization.java:134) at org.jboss.seam.servlet.SeamListener.contextInitialized(SeamListener.java:35) at my.ContextListener.contextInitialized(ContextListener.java:151) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3910) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4393) at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:310) at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:142) ... I think TomcatDeployer should not only catch Exceptions, but also Errors and log them. In TomcatDeployment.java line 310ff: try { // Start it context.start(); // Build the ENC } catch (Exception e) { context.destroy(); DeploymentException.rethrowAsDeploymentException("URL " + warUrlStr + " deployment failed", e); } finally { RunAsListener.metaDataLocal.set(null); JBossContextConfig.metaDataLocal.set(null); JBossContextConfig.metaDataShared.set(null); JBossContextConfig.deployerConfig.set(null); JBossContextConfig.kernelLocal.set(null); JBossContextConfig.deploymentUnitLocal.set(null); } if (context.getState() != 1) { context.destroy(); throw new DeploymentException("URL " + warUrlStr + " deployment failed"); } we should add catch (Error e) { context.destroy(); DeploymentException.rethrowAsDeploymentException("URL " + warUrlStr + " deployment failed", e); } -- 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

16 years, 6 months

2
2
0 / 0

[JBoss JIRA] Created: (JBWEB-157) NPE in TomcatResolver for client-requests without a Host-Header when a HTTP_HOST-RewriteCond is configured.

by Markus Grieder (JIRA)

NPE in TomcatResolver for client-requests without a Host-Header when a HTTP_HOST-RewriteCond is configured. ----------------------------------------------------------------------------------------------------------- Key: JBWEB-157 URL: https://jira.jboss.org/jira/browse/JBWEB-157 Project: JBoss Web Issue Type: Bug Security Level: Public (Everyone can see) Components: Rewrite Valve Affects Versions: JBossWeb-2.1.3.GA Environment: JBoss 5.1.0.GA, Linux, SUN JDK 1.6.0_16 Reporter: Markus Grieder Assignee: Remy Maucherat Using the following RewriteValve-configuration and do a HTTP-request without a Host-Header generates a NPE (Some old HTTP1.0-clients and bots don't provide a Host-Header). -------------------------- RewriteCond %{HTTP_HOST} www.domain.invalid RewriteRule .* - [F] -------------------------- I reproduced this in JBossWeb2.1.3, but the bug is not yet fixed in trunk. Stacktrace: 2010-01-08 16:26:27,845 ERROR [org.apache.catalina.connector.CoyoteAdapter] (http-0.0.0.0-9080-1) An exception or error occurred in the container during the request processing java.lang.NullPointerException at org.jboss.web.rewrite.TomcatResolver.resolve(TomcatResolver.java:59) at org.jboss.web.rewrite.Substitution$ServerVariableElement.evaluate(Substitution.java:63) at org.jboss.web.rewrite.Substitution.evaluate(Substitution.java:235) at org.jboss.web.rewrite.RewriteCond.evaluate(RewriteCond.java:198) at org.jboss.web.rewrite.RewriteRule.evaluate(RewriteRule.java:112) at org.jboss.web.rewrite.RewriteValve.invoke(RewriteValve.java:293) at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330) at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:905) at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:592) at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2036) at java.lang.Thread.run(Thread.java:619) -- 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

16 years, 6 months

2
2
0 / 0

[JBoss JIRA] Created: (JGRP-1127) Transport: ability to query whether the transport supports multicasting

by Bela Ban (JIRA)

Transport: ability to query whether the transport supports multicasting ----------------------------------------------------------------------- Key: JGRP-1127 URL: https://jira.jboss.org/jira/browse/JGRP-1127 Project: JGroups Issue Type: Task Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.9 If the transport supports multicasting, code in blocks (for example) can send anycasts as multicasts, else it would send it as multiple unicasts -- 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

16 years, 6 months

1
1
0 / 0

[JBoss JIRA] Created: (JGRP-1125) UNICAST: send ACK without OOB flag

by Bela Ban (JIRA)

UNICAST: send ACK without OOB flag ---------------------------------- Key: JGRP-1125 URL: https://jira.jboss.org/jira/browse/JGRP-1125 Project: JGroups Issue Type: Task Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.9 Bundling UNICAST ACKs is faster then sending them individually. However, at the receiver side, ACKs willbe handled by the default thread pool, *not* the OOB thread pool. This change is only done to support faster anycasting in Infinispan 4.0.0.GA, in JGroups 2.10, ACKs will be marked as OOB again. Once https://jira.jboss.org/jira/browse/JGRP-1090 is implemented, we bundle OOB messages anyway, so this change is unnecessary -- 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

16 years, 6 months

1
1
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2010