January 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-1576) org.jgroups.protocols.TP.ChannelThreadGroup leaks classloaders / PermGen memory

by Mattias Jiderhamn (JIRA)

[ https://issues.jboss.org/browse/JGRP-1576?page=com.atlassian.jira.plugin.... ] Mattias Jiderhamn commented on JGRP-1576: ----------------------------------------- I don't have an isolated test case. The problem appeared when using JGroups behind Infinispan for clustered Hibernate Search / Lucene. I have little insight into how Infinispan uses JGroups, but I could upload the config files if that helps? > org.jgroups.protocols.TP.ChannelThreadGroup leaks classloaders / PermGen memory > ------------------------------------------------------------------------------- > > Key: JGRP-1576 > URL: https://issues.jboss.org/browse/JGRP-1576 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 3.2.5 > Reporter: Mattias Jiderhamn > Assignee: Bela Ban > Fix For: 3.2.7 > > > Just like JGRP-1410 there is a custom ThreadGroup org.jgroups.protocols.TP.ChannelThreadGroup which is not destroyed so the parent thread group will keep a reference and keep the classloader from being garbage collected. There is actually code for destroying the thread groups (line 1026-1030) but for some reason it is commented out. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1574) ThreadPool rejection policy detecting stuck threads

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/JGRP-1574?page=com.atlassian.jira.plugin.... ] Radim Vansa commented on JGRP-1574: ----------------------------------- So, the pull requests are issued, but I can't find how to change the status to Pull Request Sent... > ThreadPool rejection policy detecting stuck threads > --------------------------------------------------- > > Key: JGRP-1574 > URL: https://issues.jboss.org/browse/JGRP-1574 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 3.2.6 > Reporter: Radim Vansa > Assignee: Radim Vansa > Priority: Minor > Fix For: 3.2.7, 3.3 > > > Sometimes I find out my OOB threadpool size (which defaults to 200) in our tests too low, causing deadlock (this seems to be the case with the 64 node cluster - we've run out of OOB threads because all of them were stuck). > New rejection policy could usually silently discard the message, but in case that the thread pool does not finish anything (getCompletedTaskCount stays constant) for a period, it would throw a special exception denoting that there's possibly a deadlock (and that raising OOB threadpool could help). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1576) org.jgroups.protocols.TP.ChannelThreadGroup leaks classloaders / PermGen memory

by Marko Lukša (JIRA)

[ https://issues.jboss.org/browse/JGRP-1576?page=com.atlassian.jira.plugin.... ] Marko Lukša commented on JGRP-1576: ----------------------------------- Hi Mattias. Do you perhaps have a test case that reproduces this problem? > org.jgroups.protocols.TP.ChannelThreadGroup leaks classloaders / PermGen memory > ------------------------------------------------------------------------------- > > Key: JGRP-1576 > URL: https://issues.jboss.org/browse/JGRP-1576 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 3.2.5 > Reporter: Mattias Jiderhamn > Assignee: Bela Ban > Fix For: 3.2.7 > > > Just like JGRP-1410 there is a custom ThreadGroup org.jgroups.protocols.TP.ChannelThreadGroup which is not destroyed so the parent thread group will keep a reference and keep the classloader from being garbage collected. There is actually code for destroying the thread groups (line 1026-1030) but for some reason it is commented out. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1574) ThreadPool rejection policy detecting stuck threads

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/JGRP-1574?page=com.atlassian.jira.plugin.... ] Radim Vansa updated JGRP-1574: ------------------------------ Git Pull Request: https://github.com/belaban/JGroups/pull/71, https://github.com/belaban/JGroups/pull/72 > ThreadPool rejection policy detecting stuck threads > --------------------------------------------------- > > Key: JGRP-1574 > URL: https://issues.jboss.org/browse/JGRP-1574 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 3.2.6 > Reporter: Radim Vansa > Assignee: Radim Vansa > Priority: Minor > Fix For: 3.2.7, 3.3 > > > Sometimes I find out my OOB threadpool size (which defaults to 200) in our tests too low, causing deadlock (this seems to be the case with the 64 node cluster - we've run out of OOB threads because all of them were stuck). > New rejection policy could usually silently discard the message, but in case that the thread pool does not finish anything (getCompletedTaskCount stays constant) for a period, it would throw a special exception denoting that there's possibly a deadlock (and that raising OOB threadpool could help). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (AS7-6420) spring-xml deployment fails without any error message given in latest snapshot

by jarkko rantavuori (JIRA)

[ https://issues.jboss.org/browse/AS7-6420?page=com.atlassian.jira.plugin.s... ] jarkko rantavuori updated AS7-6420: ----------------------------------- Steps to Reproduce: Try to deploy attached spring-xml 2.10 component, downloaded from spring enterprise repository, in the JBoss AS7 snapshot installation (link as a comment). Using web-based admin console, red message "deployment failed" appears, but no reason is available in logs, System.out or UI. Removing spring-ws deployment, again from admin console, makes spring-xml deployment appear in the admin console UI. was:Try to deploy attached spring-xml 2.10 component, downloaded from spring enterprise repository, in the latest JBoss AS7 snapshot. Using web-based admin console, red message "deployment failed" appears, but no reason is available in logs, System.out or UI. > spring-xml deployment fails without any error message given in latest snapshot > ------------------------------------------------------------------------------ > > Key: AS7-6420 > URL: https://issues.jboss.org/browse/AS7-6420 > Project: Application Server 7 > Issue Type: Bug > Components: OSGi, Server > Affects Versions: 7.2.0.Alpha1 > Environment: Windows 7, 64-bit > Reporter: jarkko rantavuori > Assignee: Thomas Diesler > Attachments: org.springframework.xml-2.1.0.RELEASE.jar > > > Today, 30.1.2013, I just got the latest snapshot from https://ci.jboss.org/jenkins/job/JBoss-AS-7.x-latest/lastSuccessfulBuild/... and tried to deploy my Spring framework on it. Spring-xml 2.10 component fails without any error message given, whereas the same jar deployed without issues in 18.12.2012 snapshot. > I tried to set set "JAVA_OPTS=%JAVA_OPTS% -Dorg.jboss.as.logging.per-deployment=false" to get an error message, but that did not help. > Jar is from Spring enterprise repository, containing OSGi metadata, so this might be OSGi related. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (AS7-6420) spring-xml deployment fails without any error message given in latest snapshot

by jarkko rantavuori (JIRA)

[ https://issues.jboss.org/browse/AS7-6420?page=com.atlassian.jira.plugin.s... ] jarkko rantavuori commented on AS7-6420: ---------------------------------------- I've now uploaded my whole JBoss into http://slsh.kapsi.fi/misc/jboss-as-7.2.0.Alpha1-SNAPSHOT.zip (~124M). Using that, spring-xml deployment doesn't appear in the admin panel at all, nor does it let you deploy that package, showing just the red message in admin UI. However, if spring-ws deployment is removed, spring-xml deployment appears in admin UI. > spring-xml deployment fails without any error message given in latest snapshot > ------------------------------------------------------------------------------ > > Key: AS7-6420 > URL: https://issues.jboss.org/browse/AS7-6420 > Project: Application Server 7 > Issue Type: Bug > Components: OSGi, Server > Affects Versions: 7.2.0.Alpha1 > Environment: Windows 7, 64-bit > Reporter: jarkko rantavuori > Assignee: Thomas Diesler > Attachments: org.springframework.xml-2.1.0.RELEASE.jar > > > Today, 30.1.2013, I just got the latest snapshot from https://ci.jboss.org/jenkins/job/JBoss-AS-7.x-latest/lastSuccessfulBuild/... and tried to deploy my Spring framework on it. Spring-xml 2.10 component fails without any error message given, whereas the same jar deployed without issues in 18.12.2012 snapshot. > I tried to set set "JAVA_OPTS=%JAVA_OPTS% -Dorg.jboss.as.logging.per-deployment=false" to get an error message, but that did not help. > Jar is from Spring enterprise repository, containing OSGi metadata, so this might be OSGi related. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (AS7-6420) spring-xml deployment fails without any error message given in latest snapshot

by jarkko rantavuori (JIRA)

[ https://issues.jboss.org/browse/AS7-6420?page=com.atlassian.jira.plugin.s... ] jarkko rantavuori edited comment on AS7-6420 at 1/30/13 9:37 AM: ----------------------------------------------------------------- (comment removed) was (Author: jrantav): Um, copied the whole server installation to another folder, and this now works... > spring-xml deployment fails without any error message given in latest snapshot > ------------------------------------------------------------------------------ > > Key: AS7-6420 > URL: https://issues.jboss.org/browse/AS7-6420 > Project: Application Server 7 > Issue Type: Bug > Components: OSGi, Server > Affects Versions: 7.2.0.Alpha1 > Environment: Windows 7, 64-bit > Reporter: jarkko rantavuori > Assignee: Thomas Diesler > Attachments: org.springframework.xml-2.1.0.RELEASE.jar > > > Today, 30.1.2013, I just got the latest snapshot from https://ci.jboss.org/jenkins/job/JBoss-AS-7.x-latest/lastSuccessfulBuild/... and tried to deploy my Spring framework on it. Spring-xml 2.10 component fails without any error message given, whereas the same jar deployed without issues in 18.12.2012 snapshot. > I tried to set set "JAVA_OPTS=%JAVA_OPTS% -Dorg.jboss.as.logging.per-deployment=false" to get an error message, but that did not help. > Jar is from Spring enterprise repository, containing OSGi metadata, so this might be OSGi related. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1576) org.jgroups.protocols.TP.ChannelThreadGroup leaks classloaders / PermGen memory

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1576?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1576: --------------------------- Fix Version/s: 3.2.7 > org.jgroups.protocols.TP.ChannelThreadGroup leaks classloaders / PermGen memory > ------------------------------------------------------------------------------- > > Key: JGRP-1576 > URL: https://issues.jboss.org/browse/JGRP-1576 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 3.2.5 > Reporter: Mattias Jiderhamn > Assignee: Bela Ban > Fix For: 3.2.7 > > > Just like JGRP-1410 there is a custom ThreadGroup org.jgroups.protocols.TP.ChannelThreadGroup which is not destroyed so the parent thread group will keep a reference and keep the classloader from being garbage collected. There is actually code for destroying the thread groups (line 1026-1030) but for some reason it is commented out. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (AS7-6419) Failed to start service jboss.deployment.subunit javax.resource.ResourceException: IJ000852: Validation exception

by Stefano Maestri (JIRA)

[ https://issues.jboss.org/browse/AS7-6419?page=com.atlassian.jira.plugin.s... ] Stefano Maestri edited comment on AS7-6419 at 1/30/13 9:28 AM: --------------------------------------------------------------- you need much more deps. Taking from a test in AS7 testsuite: <dependencies> <module name="javax.api"/> <module name="javax.resource.api"/> <module name="javax.validation.api"/> <module name="org.hibernate.validator"/> <module name="org.jboss.as.naming"/> <module name="org.jboss.as.transactions"/> <module name="org.jboss.common-core"/> <module name="org.jboss.jboss-transaction-spi"/> <module name="org.jboss.ironjacamar.api"/> <module name="org.jboss.logging"/> <module name="org.jboss.threads"/> <module name="javax.xml.stream.api"/> <module name="javax.jms.api" /> </dependencies> was (Author: maeste): you need much more deps: <dependencies> <module name="javax.api"/> <module name="javax.resource.api"/> <module name="javax.validation.api"/> <module name="org.hibernate.validator"/> <module name="org.jboss.as.naming"/> <module name="org.jboss.as.transactions"/> <module name="org.jboss.common-core"/> <module name="org.jboss.jboss-transaction-spi"/> <module name="org.jboss.ironjacamar.api"/> <module name="org.jboss.logging"/> <module name="org.jboss.threads"/> <module name="javax.xml.stream.api"/> <module name="javax.jms.api" /> </dependencies> > Failed to start service jboss.deployment.subunit javax.resource.ResourceException: IJ000852: Validation exception > ----------------------------------------------------------------------------------------------------------------- > > Key: AS7-6419 > URL: https://issues.jboss.org/browse/AS7-6419 > Project: Application Server 7 > Issue Type: Bug > Components: JCA > Affects Versions: 7.2.0.Alpha1 > Environment: Configuration: > JDK-Version: 1.6.0_33 > Operating System: Windows 7 (32 Bit) > JBoss Application Server jboss-as-7.2.0.Alpha1-SNAPSHOT (build Dec. 19th 2012) > JDK-Version: 1.6.0_33 > Resource Adapter: BeanConnect 3.0 developed by our Company (Fujitsu) > Reporter: Martin Keller > Assignee: Stefano Maestri > > Tbis Problem was reported before see https://issues.jboss.org/browse/AS7-6384, but now the components to reproduce it is included. > Starting an application using our JCA 1.6 resource adapter fails with > java.lang.RuntimeException: javax.resource.ResourceException: IJ000852: Validation exception > It works ok in the JBoss JCA 1.5 environment and on other application servers with JCA1.6 environment: > GlassFish OS Edition 3, IBM WebSphere 8.0 and WebLogic 12. > Questions: > What could be the cause for this exception? > Can we switch off the validation? > What is missing to run the validation successful? > Details: > The full stack is: > 15:04:02,128 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool – 64) MSC00001: Failed to start service jboss.deployment.subunit."BCSamplePfa.ear"."1stBCEJBs.jar".component.CallEISOltpMdb.START: org.jboss.msc.service.StartException in service jboss.deployment.subunit."BCSamplePfa.ear"."1stBCEJBs.jar".component.CallEISOltpMdb.START: java.lang.RuntimeException: javax.resource.ResourceException: IJ000852: Validation exception > at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:57) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT] > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [rt.jar:1.6.0_33] > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [rt.jar:1.6.0_33] > at java.util.concurrent.FutureTask.run(FutureTask.java:138) [rt.jar:1.6.0_33] > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_33] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_33] > at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_33] > at org.jboss.threads.JBossThread.run(JBossThread.java:122) > Caused by: java.lang.RuntimeException: javax.resource.ResourceException: IJ000852: Validation exception > at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent.start(MessageDrivenComponent.java:177) > at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT] > ... 7 more > Caused by: javax.resource.ResourceException: IJ000852: Validation exception > at org.jboss.jca.core.rar.EndpointImpl.activate(EndpointImpl.java:147) > at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent.start(MessageDrivenComponent.java:175) > ... 8 more > Caused by: javax.validation.ValidationException: Unable to find a default provider > at javax.validation.Validation$GenericBootstrapImpl.configure(Validation.java:264) [validation-api-1.0.0.GA.jar:] > at org.jboss.jca.core.bv.BeanValidationUtil.createValidatorFactory(BeanValidationUtil.java:51) > at org.jboss.jca.core.bv.BeanValidationUtil.createValidator(BeanValidationUtil.java:63) > at org.jboss.jca.core.rar.EndpointImpl.activate(EndpointImpl.java:135) > ... 9 more -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (AS7-6365) Hibernate/Infinispan 2nd Level Caches set to transaction-mode=NONE stop functioning after an explicit eviction

by Fredrik Lagerblad (JIRA)

[ https://issues.jboss.org/browse/AS7-6365?page=com.atlassian.jira.plugin.s... ] Fredrik Lagerblad commented on AS7-6365: ---------------------------------------- I've now tried with the latest JBoss 7 nightly, both with packaged hibernate and the latest (4.1.9) - but the bug remains. So have filed a Jira on Hibernate as you suggested: https://hibernate.onjira.com/browse/HHH-7959 > Hibernate/Infinispan 2nd Level Caches set to transaction-mode=NONE stop functioning after an explicit eviction > -------------------------------------------------------------------------------------------------------------- > > Key: AS7-6365 > URL: https://issues.jboss.org/browse/AS7-6365 > Project: Application Server 7 > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 7.1.3.Final (EAP) > Reporter: Fredrik Lagerblad > Assignee: Scott Marlow > > The caches in the 'infinispan' subsystem configured with <transaction mode="NONE"/> get stuck in state= CLEARING when you perform a programmatic evict() on them to clear the caches. (Using e.g. em.getEntityManagerFactory().getCache().evictAll() ) > > The problem seem to lie within the class 'org.hibernate.cache.infinispan.impl.BaseRegion, where the 'checkValid' method fails to clear the cache (and set back the state to VALID). The reason it fails is due to that it calls: cacheAdapter.withinTx() , which in turn tries to get the TransactionManager from the cache (which seems to be null for these non-transactional caches), and then NPEs on the tm.begin(); The NPE is caught and logs out "Could not invalidate region: null", and never set the state in VALID. So from thereon the caches are in an Invalid state and is not used anymore by Infinispan, thus leading to much performance. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
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 2013