July 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-1724) Could not load Logmanager "org.jboss.logmanager.LogManager"

by Jack Gibson (JIRA)

[ https://issues.jboss.org/browse/WFLY-1724?page=com.atlassian.jira.plugin.... ] Jack Gibson updated WFLY-1724: ------------------------------ Description: Set system properties to enable SNMP for the JVM fails -Dcom.sun.management.snmp.port=162 -Dcom.sun.management.snmp.acl.file=$HOME/snmp.acl Could not load Logmanager "org.jboss.logmanager.LogManager" java.lang.ClassNotFoundException: org.jboss.logmanager.LogManager at java.net.URLClassLoader$1.run(URLClassLoader.java:366) at java.net.URLClassLoader$1.run(URLClassLoader.java:355) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:354) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at java.util.logging.LogManager$1.run(LogManager.java:183) at java.security.AccessController.doPrivileged(Native Method) at java.util.logging.LogManager.<clinit>(LogManager.java:173) at java.util.logging.Logger.demandLogger(Logger.java:336) at java.util.logging.Logger.getLogger(Logger.java:390) at sun.management.snmp.util.MibLogger.<init>(MibLogger.java:72) at sun.management.snmp.util.MibLogger.<init>(MibLogger.java:57) at sun.management.snmp.AdaptorBootstrap.<clinit>(AdaptorBootstrap.java:61) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:270) at sun.management.Agent.loadSnmpAgent(Agent.java:293) at sun.management.Agent.startAgent(Agent.java:230) at sun.management.Agent.startAgent(Agent.java:369) was: Could not load Logmanager "org.jboss.logmanager.LogManager" java.lang.ClassNotFoundException: org.jboss.logmanager.LogManager at java.net.URLClassLoader$1.run(URLClassLoader.java:366) at java.net.URLClassLoader$1.run(URLClassLoader.java:355) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:354) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at java.util.logging.LogManager$1.run(LogManager.java:183) at java.security.AccessController.doPrivileged(Native Method) at java.util.logging.LogManager.<clinit>(LogManager.java:173) at java.util.logging.Logger.demandLogger(Logger.java:336) at java.util.logging.Logger.getLogger(Logger.java:390) at sun.management.snmp.util.MibLogger.<init>(MibLogger.java:72) at sun.management.snmp.util.MibLogger.<init>(MibLogger.java:57) at sun.management.snmp.AdaptorBootstrap.<clinit>(AdaptorBootstrap.java:61) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:270) at sun.management.Agent.loadSnmpAgent(Agent.java:293) at sun.management.Agent.startAgent(Agent.java:230) at sun.management.Agent.startAgent(Agent.java:369) > Could not load Logmanager "org.jboss.logmanager.LogManager" > ----------------------------------------------------------- > > Key: WFLY-1724 > URL: https://issues.jboss.org/browse/WFLY-1724 > Project: WildFly > Issue Type: Bug > Components: Class Loading > Affects Versions: 8.0.0.Alpha1 > Environment: RHEL 6.4 > Oracle JDK 7_25 > Reporter: Jack Gibson > Assignee: David Lloyd > > Set system properties to enable SNMP for the JVM fails > -Dcom.sun.management.snmp.port=162 > -Dcom.sun.management.snmp.acl.file=$HOME/snmp.acl > Could not load Logmanager "org.jboss.logmanager.LogManager" > java.lang.ClassNotFoundException: org.jboss.logmanager.LogManager > at java.net.URLClassLoader$1.run(URLClassLoader.java:366) > at java.net.URLClassLoader$1.run(URLClassLoader.java:355) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:354) > at java.lang.ClassLoader.loadClass(ClassLoader.java:424) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) > at java.lang.ClassLoader.loadClass(ClassLoader.java:357) > at java.util.logging.LogManager$1.run(LogManager.java:183) > at java.security.AccessController.doPrivileged(Native Method) > at java.util.logging.LogManager.<clinit>(LogManager.java:173) > at java.util.logging.Logger.demandLogger(Logger.java:336) > at java.util.logging.Logger.getLogger(Logger.java:390) > at sun.management.snmp.util.MibLogger.<init>(MibLogger.java:72) > at sun.management.snmp.util.MibLogger.<init>(MibLogger.java:57) > at sun.management.snmp.AdaptorBootstrap.<clinit>(AdaptorBootstrap.java:61) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:270) > at sun.management.Agent.loadSnmpAgent(Agent.java:293) > at sun.management.Agent.startAgent(Agent.java:230) > at sun.management.Agent.startAgent(Agent.java:369) -- 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

12 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1724) Could not load Logmanager "org.jboss.logmanager.LogManager"

by Jack Gibson (JIRA)

Jack Gibson created WFLY-1724: --------------------------------- Summary: Could not load Logmanager "org.jboss.logmanager.LogManager" Key: WFLY-1724 URL: https://issues.jboss.org/browse/WFLY-1724 Project: WildFly Issue Type: Bug Components: Class Loading Affects Versions: 8.0.0.Alpha1 Environment: RHEL 6.4 Oracle JDK 7_25 Reporter: Jack Gibson Assignee: David Lloyd Could not load Logmanager "org.jboss.logmanager.LogManager" java.lang.ClassNotFoundException: org.jboss.logmanager.LogManager at java.net.URLClassLoader$1.run(URLClassLoader.java:366) at java.net.URLClassLoader$1.run(URLClassLoader.java:355) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:354) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at java.util.logging.LogManager$1.run(LogManager.java:183) at java.security.AccessController.doPrivileged(Native Method) at java.util.logging.LogManager.<clinit>(LogManager.java:173) at java.util.logging.Logger.demandLogger(Logger.java:336) at java.util.logging.Logger.getLogger(Logger.java:390) at sun.management.snmp.util.MibLogger.<init>(MibLogger.java:72) at sun.management.snmp.util.MibLogger.<init>(MibLogger.java:57) at sun.management.snmp.AdaptorBootstrap.<clinit>(AdaptorBootstrap.java:61) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:270) at sun.management.Agent.loadSnmpAgent(Agent.java:293) at sun.management.Agent.startAgent(Agent.java:230) at sun.management.Agent.startAgent(Agent.java:369) -- 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

12 years, 12 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-191) Dynamic addition of rules with "evals" does not update the WM

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-191?page=com.atlassian.jira.plugin... ] Mario Fusco resolved DROOLS-191. -------------------------------- Fix Version/s: 6.0.0.CR1 Resolution: Done > Dynamic addition of rules with "evals" does not update the WM > ------------------------------------------------------------- > > Key: DROOLS-191 > URL: https://issues.jboss.org/browse/DROOLS-191 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 5.5.0.Final > Reporter: Davide Sottara > Assignee: Mario Fusco > Priority: Minor > Fix For: 5.5.1.Final, 6.0.0.CR1 > > -- 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

12 years, 12 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-191) Dynamic addition of rules with "evals" does not update the WM

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-191?page=com.atlassian.jira.plugin... ] Mario Fusco reassigned DROOLS-191: ---------------------------------- Assignee: Mario Fusco (was: Mark Proctor) > Dynamic addition of rules with "evals" does not update the WM > ------------------------------------------------------------- > > Key: DROOLS-191 > URL: https://issues.jboss.org/browse/DROOLS-191 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 5.5.0.Final > Reporter: Davide Sottara > Assignee: Mario Fusco > Priority: Minor > Fix For: 5.5.1.Final > > -- 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

12 years, 12 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1663) TimeScheduler3 could spawn too many threads

by Igor Mazur (JIRA)

[ https://issues.jboss.org/browse/JGRP-1663?page=com.atlassian.jira.plugin.... ] Igor Mazur updated JGRP-1663: ----------------------------- Description: With default timer thread pool settings this code could spawn thousands of threads: protected void submitToPool(final Task entry) { try { pool.execute(entry); } catch(RejectedExecutionException rejected) { // only thrown if rejection policy is "abort" Thread thread=timer_thread_factory != null? timer_thread_factory.newThread(entry, "Timer temp thread") : new Thread(entry, "Timer temp thread"); thread.start(); } } On my environment I got 19000 threads. was: With default timer thread pool settings this code could spawn tousands of threads: protected void submitToPool(final Task entry) { try { pool.execute(entry); } catch(RejectedExecutionException rejected) { // only thrown if rejection policy is "abort" Thread thread=timer_thread_factory != null? timer_thread_factory.newThread(entry, "Timer temp thread") : new Thread(entry, "Timer temp thread"); thread.start(); } } On my environment I got 19000 threads. > TimeScheduler3 could spawn too many threads > ------------------------------------------- > > Key: JGRP-1663 > URL: https://issues.jboss.org/browse/JGRP-1663 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.3.3 > Reporter: Igor Mazur > Assignee: Bela Ban > Priority: Optional > > With default timer thread pool settings this code could spawn thousands of threads: > protected void submitToPool(final Task entry) { > try { > pool.execute(entry); > } > catch(RejectedExecutionException rejected) { // only thrown if rejection policy is "abort" > Thread thread=timer_thread_factory != null? > timer_thread_factory.newThread(entry, "Timer temp thread") > : new Thread(entry, "Timer temp thread"); > thread.start(); > } > } > On my environment I got 19000 threads. -- 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

12 years, 12 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1663) TimeScheduler3 could spawn too many threads

by Igor Mazur (JIRA)

Igor Mazur created JGRP-1663: -------------------------------- Summary: TimeScheduler3 could spawn too many threads Key: JGRP-1663 URL: https://issues.jboss.org/browse/JGRP-1663 Project: JGroups Issue Type: Bug Affects Versions: 3.3.3 Reporter: Igor Mazur Assignee: Bela Ban Priority: Optional With default timer thread pool settings this code could spawn tousands of threads: protected void submitToPool(final Task entry) { try { pool.execute(entry); } catch(RejectedExecutionException rejected) { // only thrown if rejection policy is "abort" Thread thread=timer_thread_factory != null? timer_thread_factory.newThread(entry, "Timer temp thread") : new Thread(entry, "Timer temp thread"); thread.start(); } } On my environment I got 19000 threads. -- 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

12 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1723) Upgrade to HornetQ 2.4.0.Alpha1

by Jeff Mesnil (JIRA)

Jeff Mesnil created WFLY-1723: --------------------------------- Summary: Upgrade to HornetQ 2.4.0.Alpha1 Key: WFLY-1723 URL: https://issues.jboss.org/browse/WFLY-1723 Project: WildFly Issue Type: Component Upgrade Components: JMS Reporter: Jeff Mesnil Assignee: Jeff Mesnil HornetQ 2.4.0.Alpha1 depends on Netty 3.6.6.Final -- 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

12 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7) Extremely slow response times in Remote EJB invocation on cluster membership change

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-7?page=com.atlassian.jira.plugin.sys... ] RH Bugzilla Integration commented on WFLY-7: -------------------------------------------- Radoslav Husar <rhusar(a)redhat.com> changed the Status of [bug 900480|https://bugzilla.redhat.com/show_bug.cgi?id=900480] from NEW to CLOSED > Extremely slow response times in Remote EJB invocation on cluster membership change > ----------------------------------------------------------------------------------- > > Key: WFLY-7 > URL: https://issues.jboss.org/browse/WFLY-7 > Project: WildFly > Issue Type: Bug > Components: Clustering, EJB > Reporter: Radoslav Husar > Assignee: jaikiran pai > Labels: failover_testing > Fix For: 8.0.0.Beta1 > > > In failover scenarios [1], the response times of remote EJB client are sometimes extremely large. > On *graceful* shutdown, response times reach up to one minute [2]. Graceful failover is a positive test, no such exceptions are anticipated. > On server crash in a cluster, RTs reach up to 1 minute as well [3]. > [1] https://docspace.corp.redhat.com/docs/DOC-92019#Failover_Tests > [2] http://hudson.qa.jboss.com/hudson/view/EAP6/view/EAP6-Failover/job/eap-6x... > [3] http://hudson.qa.jboss.com/hudson/view/EAP6/view/EAP6-Failover/job/eap-6x... -- 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

12 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7) Extremely slow response times in Remote EJB invocation on cluster membership change

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-7?page=com.atlassian.jira.plugin.sys... ] RH Bugzilla Integration commented on WFLY-7: -------------------------------------------- Radoslav Husar <rhusar(a)redhat.com> made a comment on [bug 900480|https://bugzilla.redhat.com/show_bug.cgi?id=900480] Latest EAP 6.1.0 runs show that this is no longer an issue. The response time increase upon failover is minimal (especially compared to original concern when response times could reach up to a minute). http://hudson.qa.jboss.com/hudson/job/eap-6x-failover-ejb-ejbremote-shutd... Partially due to Infinispan 5.2.x upgrade in EAP 6.1 generation. Closing. > Extremely slow response times in Remote EJB invocation on cluster membership change > ----------------------------------------------------------------------------------- > > Key: WFLY-7 > URL: https://issues.jboss.org/browse/WFLY-7 > Project: WildFly > Issue Type: Bug > Components: Clustering, EJB > Reporter: Radoslav Husar > Assignee: jaikiran pai > Labels: failover_testing > Fix For: 8.0.0.Beta1 > > > In failover scenarios [1], the response times of remote EJB client are sometimes extremely large. > On *graceful* shutdown, response times reach up to one minute [2]. Graceful failover is a positive test, no such exceptions are anticipated. > On server crash in a cluster, RTs reach up to 1 minute as well [3]. > [1] https://docspace.corp.redhat.com/docs/DOC-92019#Failover_Tests > [2] http://hudson.qa.jboss.com/hudson/view/EAP6/view/EAP6-Failover/job/eap-6x... > [3] http://hudson.qa.jboss.com/hudson/view/EAP6/view/EAP6-Failover/job/eap-6x... -- 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

12 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7) Extremely slow response times in Remote EJB invocation on cluster membership change

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-7?page=com.atlassian.jira.plugin.sys... ] Radoslav Husar closed WFLY-7. ----------------------------- Resolution: Out of Date > Extremely slow response times in Remote EJB invocation on cluster membership change > ----------------------------------------------------------------------------------- > > Key: WFLY-7 > URL: https://issues.jboss.org/browse/WFLY-7 > Project: WildFly > Issue Type: Bug > Components: Clustering, EJB > Reporter: Radoslav Husar > Assignee: jaikiran pai > Labels: failover_testing > Fix For: 8.0.0.Beta1 > > > In failover scenarios [1], the response times of remote EJB client are sometimes extremely large. > On *graceful* shutdown, response times reach up to one minute [2]. Graceful failover is a positive test, no such exceptions are anticipated. > On server crash in a cluster, RTs reach up to 1 minute as well [3]. > [1] https://docspace.corp.redhat.com/docs/DOC-92019#Failover_Tests > [2] http://hudson.qa.jboss.com/hudson/view/EAP6/view/EAP6-Failover/job/eap-6x... > [3] http://hudson.qa.jboss.com/hudson/view/EAP6/view/EAP6-Failover/job/eap-6x... -- 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

12 years, 12 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 July 2013