[JBoss JIRA] (ISPN-4500) Karaf cause OOME when running iOSGI integration tests on all environments
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4500?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-4500:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1118593
> Karaf cause OOME when running iOSGI integration tests on all environments
> -------------------------------------------------------------------------
>
> Key: ISPN-4500
> URL: https://issues.jboss.org/browse/ISPN-4500
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Integration
> Affects Versions: 7.0.0.Alpha3, 7.0.0.Alpha4
> Environment: Windows, Solaris, RHEL
> Reporter: Vitalii Chepeliuk
> Assignee: Ion Savin
> Labels: testsuite_stability
>
> Karaf is parsing XML file and can not fing closing </hr> tag. There should be no <hr> tag at all. Then it throws following exception
> {noformat}
> org.xml.sax.SAXParseException; lineNumber: 6; columnNumber: 3; The element type "hr" must be terminated by the matching end-tag "</hr>".
> at org.apache.xerces.parsers.DOMParser.parse(Unknown Source)
> at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source)
> at javax.xml.parsers.DocumentBuilder.parse(Unknown Source)
> at org.apache.karaf.features.internal.FeatureValidationUtil.validate(FeatureValidationUtil.java:52)
> at org.apache.karaf.features.internal.FeaturesServiceImpl.validateRepository(FeaturesServiceImpl.java:215)
> at org.apache.karaf.features.internal.FeaturesServiceImpl.internalAddRepository(FeaturesServiceImpl.java:257)
> at org.apache.karaf.features.internal.FeaturesServiceImpl.addRepository(FeaturesServiceImpl.java:237)
> at org.apache.karaf.features.internal.FeaturesServiceImpl.addRepository(FeaturesServiceImpl.java:225)
> at org.infinispan.it.osgi.features.OSGiKarafFeaturesTest.checkInstall(OSGiKarafFeaturesTest.java:87)
> at org.infinispan.it.osgi.features.OSGiKarafFeaturesTest.testCleanInstall(OSGiKarafFeaturesTest.java:71)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:67)
> at org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:37)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:138)
> at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.invokeViaJUnit(JUnitProbeInvoker.java:124)
> at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.findAndInvoke(JUnitProbeInvoker.java:97)
> at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.call(JUnitProbeInvoker.java:73)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:80)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
> at sun.rmi.transport.Transport$1.run(Transport.java:177)
> at sun.rmi.transport.Transport$1.run(Transport.java:174)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:173)
> at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:556)
> at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:811)
> at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:670)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> {noformat}
> Very often EOF Exceotion is thrown
> {noformat}
> java.io.EOFException
> at java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2598)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1318)
> at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1990)
> at java.io.ObjectInputStream.defaultReadObject(ObjectInputStream.java:500)
> at java.lang.Throwable.readObject(Throwable.java:914)
> at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1017)
> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1893)
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1798)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)
> at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1990)
> at java.io.ObjectInputStream.defaultReadObject(ObjectInputStream.java:500)
> at java.lang.Throwable.readObject(Throwable.java:914)
> at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1017)
> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1893)
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1798)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)
> at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1990)
> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1915)
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1798)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370)
> at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:244)
> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:161)
> at java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:194)
> at java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:148)
> at com.sun.proxy.$Proxy20.remoteCall(Unknown Source)
> at org.ops4j.pax.exam.rbc.client.intern.RemoteBundleContextClientImpl$1.invoke(RemoteBundleContextClientImpl.java:101)
> at com.sun.proxy.$Proxy21.call(Unknown Source)
> at org.ops4j.pax.exam.rbc.client.intern.RemoteBundleContextClientImpl.call(RemoteBundleContextClientImpl.java:268)
> at org.ops4j.pax.exam.container.remote.RBCRemoteTarget.call(RBCRemoteTarget.java:65)
> at org.ops4j.pax.exam.karaf.container.internal.KarafTestContainer.call(KarafTestContainer.java:533)
> at org.ops4j.pax.exam.spi.reactors.SingletonStagedReactor.invoke(SingletonStagedReactor.java:113)
> at org.ops4j.pax.exam.spi.reactors.PerSuiteStagedReactor.invoke(PerSuiteStagedReactor.java:47)
> at org.ops4j.pax.exam.junit.impl.ProbeRunner$2.evaluate(ProbeRunner.java:278)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.ops4j.pax.exam.junit.impl.ProbeRunner.run(ProbeRunner.java:112)
> at org.ops4j.pax.exam.junit.PaxExam.run(PaxExam.java:93)
> at org.junit.runners.Suite.runChild(Suite.java:127)
> at org.junit.runners.Suite.runChild(Suite.java:26)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> {noformat}
> And finally is start to leak memory and end up with
> {noformat}
> java.lang.OutOfMemoryError: Java heap space
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 2 months
[JBoss JIRA] (ISPN-4499) Prevent shadowing user-defined jgroups configuration file
by Martin Gencur (JIRA)
[ https://issues.jboss.org/browse/ISPN-4499?page=com.atlassian.jira.plugin.... ]
Martin Gencur updated ISPN-4499:
--------------------------------
Description:
When users create their own JGroups configuration file and name it the same way as default configuration files (jgroups-udp.xml / jgroups-tcp-xml / jgroups-ec2.xml), they might not be visible to the user application as they're shadowed by the default configuration files.
Proposed solution:
* place current jgroups configuration files into META-INF/configs folder (this folder doesn't have to have an obscure name such as "_internal" because of the following two points which complement the solution)
* define order in which the config files are read by class loader (i.e. first scan user application, then path under META-INF/configs)
* when Infinispan is started, log the path to the configuration file used, e.g.:
{code}
2014-06-12 06:45:02,871 [thread-name] INFO [package-name] Using JGroups configuration file 'jar:META-INF/example_configurations/jgroups/udp.xml'
2014-06-12 06:45:02,871 [thread-name] INFO [package-name] Using JGroups configuration file 'file:/app_home/config/jgroups-udp.xml'
{code}
was:
When users create their own JGroups configuration file and name it the same way as default configuration files (jgroups-udp.xml / jgroups-tcp-xml / jgroups-ec2.xml), they might not be visible to the user application as they're shadowed by the default configuration files.
Proposed solution:
* place current jgroups configuration files into META-INF/configs folder
* define order in which the config files are read by class laoder (i.e. first scan user application, then path under META-INF/configs)
* when Infinispan is started, log the path to the configuration file used, e.g.:
{code}
2014-06-12 06:45:02,871 [thread-name] INFO [package-name] Using JGroups configuration file 'jar:META-INF/example_configurations/jgroups/udp.xml'
2014-06-12 06:45:02,871 [thread-name] INFO [package-name] Using JGroups configuration file 'file:/app_home/config/jgroups-udp.xml'
{code}
> Prevent shadowing user-defined jgroups configuration file
> ---------------------------------------------------------
>
> Key: ISPN-4499
> URL: https://issues.jboss.org/browse/ISPN-4499
> Project: Infinispan
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Configuration
> Affects Versions: 7.0.0.Alpha4
> Reporter: Martin Gencur
> Assignee: Martin Gencur
>
> When users create their own JGroups configuration file and name it the same way as default configuration files (jgroups-udp.xml / jgroups-tcp-xml / jgroups-ec2.xml), they might not be visible to the user application as they're shadowed by the default configuration files.
> Proposed solution:
> * place current jgroups configuration files into META-INF/configs folder (this folder doesn't have to have an obscure name such as "_internal" because of the following two points which complement the solution)
> * define order in which the config files are read by class loader (i.e. first scan user application, then path under META-INF/configs)
> * when Infinispan is started, log the path to the configuration file used, e.g.:
> {code}
> 2014-06-12 06:45:02,871 [thread-name] INFO [package-name] Using JGroups configuration file 'jar:META-INF/example_configurations/jgroups/udp.xml'
> 2014-06-12 06:45:02,871 [thread-name] INFO [package-name] Using JGroups configuration file 'file:/app_home/config/jgroups-udp.xml'
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 2 months
[JBoss JIRA] (ISPN-4500) Karaf cause OOME when running iOSGI integration tests on all environments
by Vitalii Chepeliuk (JIRA)
Vitalii Chepeliuk created ISPN-4500:
---------------------------------------
Summary: Karaf cause OOME when running iOSGI integration tests on all environments
Key: ISPN-4500
URL: https://issues.jboss.org/browse/ISPN-4500
Project: Infinispan
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Integration
Affects Versions: 7.0.0.Alpha4, 7.0.0.Alpha3
Environment: Windows, Solaris, RHEL
Reporter: Vitalii Chepeliuk
Assignee: Ion Savin
Karaf is parsing XML file and can not fing closing </hr> tag. There should be no <hr> tag at all. Then it throws following exception
{noformat}
org.xml.sax.SAXParseException; lineNumber: 6; columnNumber: 3; The element type "hr" must be terminated by the matching end-tag "</hr>".
at org.apache.xerces.parsers.DOMParser.parse(Unknown Source)
at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source)
at javax.xml.parsers.DocumentBuilder.parse(Unknown Source)
at org.apache.karaf.features.internal.FeatureValidationUtil.validate(FeatureValidationUtil.java:52)
at org.apache.karaf.features.internal.FeaturesServiceImpl.validateRepository(FeaturesServiceImpl.java:215)
at org.apache.karaf.features.internal.FeaturesServiceImpl.internalAddRepository(FeaturesServiceImpl.java:257)
at org.apache.karaf.features.internal.FeaturesServiceImpl.addRepository(FeaturesServiceImpl.java:237)
at org.apache.karaf.features.internal.FeaturesServiceImpl.addRepository(FeaturesServiceImpl.java:225)
at org.infinispan.it.osgi.features.OSGiKarafFeaturesTest.checkInstall(OSGiKarafFeaturesTest.java:87)
at org.infinispan.it.osgi.features.OSGiKarafFeaturesTest.testCleanInstall(OSGiKarafFeaturesTest.java:71)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:67)
at org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:37)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
at org.junit.runner.JUnitCore.run(JUnitCore.java:138)
at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.invokeViaJUnit(JUnitProbeInvoker.java:124)
at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.findAndInvoke(JUnitProbeInvoker.java:97)
at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.call(JUnitProbeInvoker.java:73)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:80)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
at sun.rmi.transport.Transport$1.run(Transport.java:177)
at sun.rmi.transport.Transport$1.run(Transport.java:174)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:173)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:556)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:811)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:670)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
{noformat}
Very often EOF Exceotion is thrown
{noformat}
java.io.EOFException
at java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2598)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1318)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1990)
at java.io.ObjectInputStream.defaultReadObject(ObjectInputStream.java:500)
at java.lang.Throwable.readObject(Throwable.java:914)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1017)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1893)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1798)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1990)
at java.io.ObjectInputStream.defaultReadObject(ObjectInputStream.java:500)
at java.lang.Throwable.readObject(Throwable.java:914)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1017)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1893)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1798)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1990)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1915)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1798)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370)
at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:244)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:161)
at java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:194)
at java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:148)
at com.sun.proxy.$Proxy20.remoteCall(Unknown Source)
at org.ops4j.pax.exam.rbc.client.intern.RemoteBundleContextClientImpl$1.invoke(RemoteBundleContextClientImpl.java:101)
at com.sun.proxy.$Proxy21.call(Unknown Source)
at org.ops4j.pax.exam.rbc.client.intern.RemoteBundleContextClientImpl.call(RemoteBundleContextClientImpl.java:268)
at org.ops4j.pax.exam.container.remote.RBCRemoteTarget.call(RBCRemoteTarget.java:65)
at org.ops4j.pax.exam.karaf.container.internal.KarafTestContainer.call(KarafTestContainer.java:533)
at org.ops4j.pax.exam.spi.reactors.SingletonStagedReactor.invoke(SingletonStagedReactor.java:113)
at org.ops4j.pax.exam.spi.reactors.PerSuiteStagedReactor.invoke(PerSuiteStagedReactor.java:47)
at org.ops4j.pax.exam.junit.impl.ProbeRunner$2.evaluate(ProbeRunner.java:278)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.ops4j.pax.exam.junit.impl.ProbeRunner.run(ProbeRunner.java:112)
at org.ops4j.pax.exam.junit.PaxExam.run(PaxExam.java:93)
at org.junit.runners.Suite.runChild(Suite.java:127)
at org.junit.runners.Suite.runChild(Suite.java:26)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
{noformat}
And finally is start to leak memory and end up with
{noformat}
java.lang.OutOfMemoryError: Java heap space
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 2 months
[JBoss JIRA] (ISPN-4499) Prevent shadowing user-defined jgroups configuration file
by Martin Gencur (JIRA)
Martin Gencur created ISPN-4499:
-----------------------------------
Summary: Prevent shadowing user-defined jgroups configuration file
Key: ISPN-4499
URL: https://issues.jboss.org/browse/ISPN-4499
Project: Infinispan
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: Configuration
Affects Versions: 7.0.0.Alpha4
Reporter: Martin Gencur
Assignee: Martin Gencur
When users create their own JGroups configuration file and name it the same way as default configuration files (jgroups-udp.xml / jgroups-tcp-xml / jgroups-ec2.xml), they might not be visible to the user application as they're shadowed by the default configuration files.
Proposed solution:
* place current jgroups configuration files into META-INF/configs folder
* define order in which the config files are read by class laoder (i.e. first scan user application, then path under META-INF/configs)
* when Infinispan is started, log the path to the configuration file used, e.g.:
{code}
2014-06-12 06:45:02,871 [thread-name] INFO [package-name] Using JGroups configuration file 'jar:META-INF/example_configurations/jgroups/udp.xml'
2014-06-12 06:45:02,871 [thread-name] INFO [package-name] Using JGroups configuration file 'file:/app_home/config/jgroups-udp.xml'
{code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 2 months
[JBoss JIRA] (ISPN-4436) Karaf stucked when running iOSGI integration tests on IBM JDK
by Vitalii Chepeliuk (JIRA)
[ https://issues.jboss.org/browse/ISPN-4436?page=com.atlassian.jira.plugin.... ]
Vitalii Chepeliuk updated ISPN-4436:
------------------------------------
Summary: Karaf stucked when running iOSGI integration tests on IBM JDK (was: Karaf cause OOME when running iOSGI integration tests on all environments)
> Karaf stucked when running iOSGI integration tests on IBM JDK
> -------------------------------------------------------------
>
> Key: ISPN-4436
> URL: https://issues.jboss.org/browse/ISPN-4436
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Vitalii Chepeliuk
> Assignee: Ion Savin
> Labels: testsuite_stability
>
> {noformat}
> __ __ ____
> / //_/____ __________ _/ __/
> / ,< / __ `/ ___/ __ `/ /_
> / /| |/ /_/ / / / /_/ / __/
> /_/ |_|\__,_/_/ \__,_/_/
> Apache Karaf (2.3.3)
> Hit '<tab>' for a list of available commands
> and '[cmd] --help' for help on a specific command.
> Hit '<ctrl-d>' or type 'osgi:shutdown' or 'logout' to shutdown Karaf.
> karaf@root> Failed to instantiate SLF4J LoggerFactory
> Reported exception:
> java.lang.NoClassDefFoundError: org.slf4j.impl.StaticLoggerBinder
> at org.slf4j.LoggerFactory.bind(LoggerFactory.java:121)
> at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:111)
> at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:268)
> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:241)
> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:254)
> at org.ops4j.pax.exam.rbc.internal.Activator.<clinit>(Activator.java:46)
> at java.lang.J9VMInternals.newInstanceImpl(Native Method)
> at java.lang.Class.newInstance(Class.java:1774)
> at org.apache.felix.framework.Felix.createBundleActivator(Felix.java:4177)
> at org.apache.felix.framework.Felix.activateBundle(Felix.java:1972)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:1895)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:931)
> at org.apache.karaf.features.internal.FeaturesServiceImpl.installFeatures(FeaturesServiceImpl.java:530)
> at org.apache.karaf.features.internal.FeaturesServiceImpl.start(FeaturesServiceImpl.java:1207)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:94)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:619)
> at org.apache.aries.blueprint.utils.ReflectionUtils.invoke(ReflectionUtils.java:297)
> at org.apache.aries.blueprint.container.BeanRecipe.invoke(BeanRecipe.java:958)
> at org.apache.aries.blueprint.container.BeanRecipe.runBeanProcInit(BeanRecipe.java:712)
> at org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:824)
> at org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:787)
> at org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)
> at java.util.concurrent.FutureTask.run(FutureTask.java:273)
> at org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)
> at org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:245)
> at org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:183)
> at org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:668)
> at org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:370)
> at org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:261)
> at org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:259)
> at org.apache.aries.blueprint.container.BlueprintExtender.modifiedBundle(BlueprintExtender.java:222)
> at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:500)
> at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:433)
> at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$AbstractTracked.track(BundleHookBundleTracker.java:725)
> at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.bundleChanged(BundleHookBundleTracker.java:463)
> at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$BundleEventHook.event(BundleHookBundleTracker.java:422)
> at org.apache.felix.framework.util.SecureAction.invokeBundleEventHook(SecureAction.java:1103)
> at org.apache.felix.framework.util.EventDispatcher.createWhitelistFromHooks(EventDispatcher.java:695)
> at org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:483)
> at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4244)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:1923)
> at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191)
> at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295)
> at java.lang.Thread.run(Thread.java:853)
> Caused by: java.lang.ClassNotFoundException: org.slf4j.impl.StaticLoggerBinder not found by org.ops4j.pax.exam.rbc [87]
> at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1460)
> at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
> at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:827)
> {noformat}
> Jenkins job could be found here
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e...
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 2 months
[JBoss JIRA] (ISPN-4436) Karaf cause OOME when running iOSGI integration tests on all environments
by Vitalii Chepeliuk (JIRA)
[ https://issues.jboss.org/browse/ISPN-4436?page=com.atlassian.jira.plugin.... ]
Vitalii Chepeliuk updated ISPN-4436:
------------------------------------
Summary: Karaf cause OOME when running iOSGI integration tests on all environments (was: Karaf is stucked when running iOSGI integration tests)
> Karaf cause OOME when running iOSGI integration tests on all environments
> --------------------------------------------------------------------------
>
> Key: ISPN-4436
> URL: https://issues.jboss.org/browse/ISPN-4436
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Vitalii Chepeliuk
> Assignee: Ion Savin
> Labels: testsuite_stability
>
> {noformat}
> __ __ ____
> / //_/____ __________ _/ __/
> / ,< / __ `/ ___/ __ `/ /_
> / /| |/ /_/ / / / /_/ / __/
> /_/ |_|\__,_/_/ \__,_/_/
> Apache Karaf (2.3.3)
> Hit '<tab>' for a list of available commands
> and '[cmd] --help' for help on a specific command.
> Hit '<ctrl-d>' or type 'osgi:shutdown' or 'logout' to shutdown Karaf.
> karaf@root> Failed to instantiate SLF4J LoggerFactory
> Reported exception:
> java.lang.NoClassDefFoundError: org.slf4j.impl.StaticLoggerBinder
> at org.slf4j.LoggerFactory.bind(LoggerFactory.java:121)
> at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:111)
> at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:268)
> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:241)
> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:254)
> at org.ops4j.pax.exam.rbc.internal.Activator.<clinit>(Activator.java:46)
> at java.lang.J9VMInternals.newInstanceImpl(Native Method)
> at java.lang.Class.newInstance(Class.java:1774)
> at org.apache.felix.framework.Felix.createBundleActivator(Felix.java:4177)
> at org.apache.felix.framework.Felix.activateBundle(Felix.java:1972)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:1895)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:931)
> at org.apache.karaf.features.internal.FeaturesServiceImpl.installFeatures(FeaturesServiceImpl.java:530)
> at org.apache.karaf.features.internal.FeaturesServiceImpl.start(FeaturesServiceImpl.java:1207)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:94)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:619)
> at org.apache.aries.blueprint.utils.ReflectionUtils.invoke(ReflectionUtils.java:297)
> at org.apache.aries.blueprint.container.BeanRecipe.invoke(BeanRecipe.java:958)
> at org.apache.aries.blueprint.container.BeanRecipe.runBeanProcInit(BeanRecipe.java:712)
> at org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:824)
> at org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:787)
> at org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)
> at java.util.concurrent.FutureTask.run(FutureTask.java:273)
> at org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)
> at org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:245)
> at org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:183)
> at org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:668)
> at org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:370)
> at org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:261)
> at org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:259)
> at org.apache.aries.blueprint.container.BlueprintExtender.modifiedBundle(BlueprintExtender.java:222)
> at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:500)
> at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:433)
> at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$AbstractTracked.track(BundleHookBundleTracker.java:725)
> at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.bundleChanged(BundleHookBundleTracker.java:463)
> at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$BundleEventHook.event(BundleHookBundleTracker.java:422)
> at org.apache.felix.framework.util.SecureAction.invokeBundleEventHook(SecureAction.java:1103)
> at org.apache.felix.framework.util.EventDispatcher.createWhitelistFromHooks(EventDispatcher.java:695)
> at org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:483)
> at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4244)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:1923)
> at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191)
> at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295)
> at java.lang.Thread.run(Thread.java:853)
> Caused by: java.lang.ClassNotFoundException: org.slf4j.impl.StaticLoggerBinder not found by org.ops4j.pax.exam.rbc [87]
> at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1460)
> at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
> at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:827)
> {noformat}
> Jenkins job could be found here
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e...
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 2 months
[JBoss JIRA] (ISPN-4497) Race condition in LocalLockMergingSegmentReadLocker results in file content being deleted
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-4497?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero commented on ISPN-4497:
---------------------------------------
[~chp-anujs] thanks! your very detailed analysis is extremely helpful.
> Race condition in LocalLockMergingSegmentReadLocker results in file content being deleted
> -----------------------------------------------------------------------------------------
>
> Key: ISPN-4497
> URL: https://issues.jboss.org/browse/ISPN-4497
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Lucene Directory
> Affects Versions: 5.2.6.Final
> Reporter: Anuj Shah
> Assignee: Sanne Grinovero
>
> There is a race condition in LocalLockMergingSegmentReadLocker which can lead to more calls delete on the underlying DistributedSegmentReadLocker which results in the file being removed from the caches.
> This happens with three or more threads acquiring and releasing locks on the same file simultaneously:
> # Thread 1 (T1) acquires a lock and creates a {{LocalReadLock}}, call it L1 - the underlying lock is acquired
> # T2 starts to acquire and holds a reference to L1
> # T3 starts to acquire and holds a reference to L1
> # T1 releases - L1 at this stage only has value of 1 - so the underlying lock is released, and L1 is removed from the map
> # T2 continues - finds L1 with value 0 and acquires the underlying lock
> # T3 continues - increments L1 value to 2
> # T2 releases - creates a new {{LocalReadLock}}, L2 - this has zero value so the underlying lock is released, and L2 is removed from the map
> # T3 releases - creates a new {{LocalReadLock}}, L3 - this has zero value so the underlying lock is released, and L3 is removed from the map
> # The final step triggers a real file delete as underlying lock is released one too many times
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 2 months
[JBoss JIRA] (ISPN-4498) OutOfMemoryError when CI is ran with tracing
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-4498?page=com.atlassian.jira.plugin.... ]
William Burns commented on ISPN-4498:
-------------------------------------
Also a side note that updating to log4j2 would also solve this as this is only an issue with Log4j1.2. Even after the JBLOGGING-106 is fixed we will still need to call to clear the NDC by hand with log4j1.2, log4j2 uses a java.lang.ThreadLocal so the leakage wouldn't occur even without the clear.
> OutOfMemoryError when CI is ran with tracing
> --------------------------------------------
>
> Key: ISPN-4498
> URL: https://issues.jboss.org/browse/ISPN-4498
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Test Suite - Server
> Affects Versions: 7.0.0.Alpha4
> Reporter: William Burns
> Assignee: William Burns
>
> The CI will fail very often when tracing is enabled with some sort of OOM error.
> http://ci.infinispan.org/viewType.html?buildTypeId=Infinispan_MasterHotsp...
> Looking closer this appears to be an issue with an accumulation of Threads. These threads aren't running either but rather are held in memory unneedingly. It appears that they are being retained in the log4j1.2 NDC class in it's hashtable. Upon further investigation we never call to NDC.remove which would clear up the current any dead threads.
> I have crated JBLOGGING-106 to fix this as well. In the mean time we shouldn't use NDC.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 3 months
[JBoss JIRA] (ISPN-4459) Memory leak in Hot Rod client tests
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-4459?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-4459:
-------------------------------
Assignee: William Burns (was: Mircea Markus)
> Memory leak in Hot Rod client tests
> -----------------------------------
>
> Key: ISPN-4459
> URL: https://issues.jboss.org/browse/ISPN-4459
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Test Suite - Server
> Affects Versions: 7.0.0.Alpha4
> Reporter: Dan Berindei
> Assignee: William Burns
> Labels: testsuite_stability
> Fix For: 7.0.0.Final
>
> Attachments: jprofiler_screenshot.png
>
>
> Even though the HotRod client tests stop their servers, each test instance keeps the reference to the servers it has started (both tests extending HotRodSingleNodeTest and those extending HotRodMultiNodeTest).
> In some tests, like the remote query tests, those servers' worker threads also keep references to huge thread-local {{io.netty.buffer.PoolThreadCache}} s (see attachment). Because of this, I'm sometimes seeing an OOM in the HotRod client suite. We should either clear the server references in the tests, or clear the worker threads when shutting down the server.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 3 months
[JBoss JIRA] (ISPN-4498) OutOfMemoryError when CI is ran with tracing
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-4498?page=com.atlassian.jira.plugin.... ]
William Burns reassigned ISPN-4498:
-----------------------------------
Assignee: William Burns (was: Mircea Markus)
> OutOfMemoryError when CI is ran with tracing
> --------------------------------------------
>
> Key: ISPN-4498
> URL: https://issues.jboss.org/browse/ISPN-4498
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Test Suite - Server
> Affects Versions: 7.0.0.Alpha4
> Reporter: William Burns
> Assignee: William Burns
>
> The CI will fail very often when tracing is enabled with some sort of OOM error.
> http://ci.infinispan.org/viewType.html?buildTypeId=Infinispan_MasterHotsp...
> Looking closer this appears to be an issue with an accumulation of Threads. These threads aren't running either but rather are held in memory unneedingly. It appears that they are being retained in the log4j1.2 NDC class in it's hashtable. Upon further investigation we never call to NDC.remove which would clear up the current any dead threads.
> I have crated JBLOGGING-106 to fix this as well. In the mean time we shouldn't use NDC.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 3 months