[JBoss JIRA] (ISPN-5064) Tests from org.infinispan.lucene fails on JDK6
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5064?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5064:
-----------------------------------------------
Martin Gencur <mgencur(a)redhat.com> changed the Status of [bug 1172106|https://bugzilla.redhat.com/show_bug.cgi?id=1172106] from ON_QA to VERIFIED
> Tests from org.infinispan.lucene fails on JDK6
> ----------------------------------------------
>
> Key: ISPN-5064
> URL: https://issues.jboss.org/browse/ISPN-5064
> Project: Infinispan
> Issue Type: Bug
> Components: Lucene Directory
> Reporter: Vojtech Juranek
>
> Several tests from {{org.infinispan.lucene}} fails on JDK6,
> * {{org.infinispan.lucene.cacheloader.WarmCacheTest.createBeforeClass}} fails with (see e.g. [this Jekins job|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/j...])
> {noformat}
> java.lang.NoClassDefFoundError: java/nio/file/attribute/FileAttribute
> [...]
> Caused by: java.lang.ClassNotFoundException: java.nio.file.attribute.FileAttribute
> at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
> ... 24 more
> {noformat}
> * org.infinispan.lucene.cacheloader.WarmCacheTest.clearContent fails with
> {noformat}
> java.lang.IllegalStateException: No caches registered! Use registerCacheManager(Cache... caches) to do that!
> at org.infinispan.test.MultipleCacheManagersTest.clearContent(MultipleCacheManagersTest.java:96)
> 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:597)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:564)
> at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:213)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:786)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
> at java.lang.Thread.run(Thread.java:662)
> {noformat}
> * {{org.infinispan.lucene.cacheloader.WarmCacheTest.clearTempDir}} fails with NPE:
> {noformat}
> java.lang.NullPointerException
> at org.infinispan.test.TestingUtil.recursiveFileRemove(TestingUtil.java:573)
> at org.infinispan.lucene.cacheloader.WarmCacheTest.clearTempDir(WarmCacheTest.java:78)
> 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:597)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:564)
> at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:213)
> at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:138)
> at org.testng.internal.TestMethodWorker.invokeAfterClassMethods(TestMethodWorker.java:225)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:114)
> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
> at java.lang.Thread.run(Thread.java:662)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (ISPN-5121) Distributed executor fails when CDI is not on classpath
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-5121?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-5121:
----------------------------------
Status: Open (was: New)
> Distributed executor fails when CDI is not on classpath
> -------------------------------------------------------
>
> Key: ISPN-5121
> URL: https://issues.jboss.org/browse/ISPN-5121
> Project: Infinispan
> Issue Type: Bug
> Components: CDI Integration, Distributed Execution and Map/Reduce
> Affects Versions: 7.1.0.Alpha1, 7.0.3.Final
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
> Fix For: 7.1.0.Final, 7.0.4.Final
>
>
> When running a distributed executor using the infinispan-embedded uber jar, without the CDI API classes on the classpath the following exception is thrown:
> java.lang.NoClassDefFoundError: org/infinispan/cdi/util/BeanManagerProvider
> at org.infinispan.cdi.CDIDistributedTaskLifecycle.onPostExecute(CDIDistributedTaskLifecycle.java:35)
> at org.infinispan.distexec.spi.DistributedTaskLifecycleService.onPostExecute(DistributedTaskLifecycleService.java:48)
> at org.infinispan.commands.read.DistributedExecuteCommand.perform(DistributedExecuteCommand.java:100)
> at org.infinispan.remoting.InboundInvocationHandlerImpl.handleInternal(InboundInvocationHandlerImpl.java:97)
> at org.infinispan.remoting.InboundInvocationHandlerImpl.access$000(InboundInvocationHandlerImpl.java:52)
> at org.infinispan.remoting.InboundInvocationHandlerImpl$2.run(InboundInvocationHandlerImpl.java:193)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (ISPN-5121) Distributed executor fails when CDI is not on classpath
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-5121?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-5121:
----------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/3188
> Distributed executor fails when CDI is not on classpath
> -------------------------------------------------------
>
> Key: ISPN-5121
> URL: https://issues.jboss.org/browse/ISPN-5121
> Project: Infinispan
> Issue Type: Bug
> Components: CDI Integration, Distributed Execution and Map/Reduce
> Affects Versions: 7.1.0.Alpha1, 7.0.3.Final
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
> Fix For: 7.1.0.Final, 7.0.4.Final
>
>
> When running a distributed executor using the infinispan-embedded uber jar, without the CDI API classes on the classpath the following exception is thrown:
> java.lang.NoClassDefFoundError: org/infinispan/cdi/util/BeanManagerProvider
> at org.infinispan.cdi.CDIDistributedTaskLifecycle.onPostExecute(CDIDistributedTaskLifecycle.java:35)
> at org.infinispan.distexec.spi.DistributedTaskLifecycleService.onPostExecute(DistributedTaskLifecycleService.java:48)
> at org.infinispan.commands.read.DistributedExecuteCommand.perform(DistributedExecuteCommand.java:100)
> at org.infinispan.remoting.InboundInvocationHandlerImpl.handleInternal(InboundInvocationHandlerImpl.java:97)
> at org.infinispan.remoting.InboundInvocationHandlerImpl.access$000(InboundInvocationHandlerImpl.java:52)
> at org.infinispan.remoting.InboundInvocationHandlerImpl$2.run(InboundInvocationHandlerImpl.java:193)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (ISPN-5121) Distributed executor fails when CDI is not on classpath
by Tristan Tarrant (JIRA)
Tristan Tarrant created ISPN-5121:
-------------------------------------
Summary: Distributed executor fails when CDI is not on classpath
Key: ISPN-5121
URL: https://issues.jboss.org/browse/ISPN-5121
Project: Infinispan
Issue Type: Bug
Components: CDI Integration, Distributed Execution and Map/Reduce
Affects Versions: 7.0.3.Final, 7.1.0.Alpha1
Reporter: Tristan Tarrant
Assignee: Tristan Tarrant
Fix For: 7.1.0.Final, 7.0.4.Final
When running a distributed executor using the infinispan-embedded uber jar, without the CDI API classes on the classpath the following exception is thrown:
java.lang.NoClassDefFoundError: org/infinispan/cdi/util/BeanManagerProvider
at org.infinispan.cdi.CDIDistributedTaskLifecycle.onPostExecute(CDIDistributedTaskLifecycle.java:35)
at org.infinispan.distexec.spi.DistributedTaskLifecycleService.onPostExecute(DistributedTaskLifecycleService.java:48)
at org.infinispan.commands.read.DistributedExecuteCommand.perform(DistributedExecuteCommand.java:100)
at org.infinispan.remoting.InboundInvocationHandlerImpl.handleInternal(InboundInvocationHandlerImpl.java:97)
at org.infinispan.remoting.InboundInvocationHandlerImpl.access$000(InboundInvocationHandlerImpl.java:52)
at org.infinispan.remoting.InboundInvocationHandlerImpl$2.run(InboundInvocationHandlerImpl.java:193)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (ISPN-5108) Indexes (aka Filters) for MapReduce
by Guillermo GARCIA OCHOA (JIRA)
[ https://issues.jboss.org/browse/ISPN-5108?page=com.atlassian.jira.plugin.... ]
Guillermo GARCIA OCHOA updated ISPN-5108:
-----------------------------------------
Description:
We are using infinispan in a multi-tenant environment. In our first implementation we had a single group of caches for all the tenants and each object had a _'tenandId'_ (that we used as part of the key of each object too).
We had to abandon this approach due to the poor performance of our MapReduce task. The main problem is that each task 'iterate' over each element in the "shared" cache when we only need to process the elements of the tenant 'X'.
To fix this issue we were forced to create caches for each tenant, and now the MapReduce is as good as it gets (Infinispan 7 improved a lot the performance).
The problem with our current approach is that it does not scale-out: For each tenant, we create several caches that leads to the creation of thread pools and other resources on each node.
*PROPOSED SOLUTION*
Allow creating 'indexes' (aka 'filters') that points to a group of element on the cache. The idea is to 'register' some index/filters on each cache an updating it on every put. Then, when executing a MapRecuce task we can indicate the 'index'/'filter' to execute the task over the referred entries only.
This will help us in our use case but it can also improve any MapReduce task executed over infinispan if it is correctly 'tunned'. We are hopping to get your attention before reaching our scale-up limits :)
Thanks in advance and happy holidays!
(i) This is the main feature of Oracle Coherence to improve MapReduce-like tasks (more info [here|http://docs.oracle.com/cd/E18686_01/coh.37/e18692/querylang.htm#CEGG...])
was:
We are using infinispan in a multi-tenant environment. In our first implementation we had a single group of caches for all the tenants and each object had a _'tenandId'_ (that we used as part of the key of each object too).
We had to abandon this approach due to the poor performance of our MapReduce task. The main problem is that each task 'iterate' over each element in the "shared" cache when we only need to process the elements of the tenant 'X'.
To fix this issue we were forced to create caches for each tenant, and now the MapReduce is as good as it gets (Infinispan 7 improved a lot the performance).
The problem with our current approach is that it does not scale-out: For each tenant, we create several caches that leads to the creation of thread pools and other resources on each node.
*PROPOSED SOLUTION*
Allow creating 'indexes' (aka 'filters') that points to a group of element on the cache. The idea is to 'register' some index/filters on each cache an updating it on every put. Then, when executing a MapRecuce task we can indicate the 'index'/'filter' to execute the task over the referred entries only.
This will help us in our use case but it can also improve any MapReduce task executed over infinispan if it is correctly 'tunned'. We are hopping to get your attention before reaching our scale-up limits :)
Thanks in advance and happy holidays!
(i) This is the main feature of Oracle Coherence to improve MapReduce-like task (more info [here|http://docs.oracle.com/cd/E18686_01/coh.37/e18692/querylang.htm#CEGG...])
> Indexes (aka Filters) for MapReduce
> -----------------------------------
>
> Key: ISPN-5108
> URL: https://issues.jboss.org/browse/ISPN-5108
> Project: Infinispan
> Issue Type: Feature Request
> Components: Distributed Execution and Map/Reduce
> Reporter: Guillermo GARCIA OCHOA
>
> We are using infinispan in a multi-tenant environment. In our first implementation we had a single group of caches for all the tenants and each object had a _'tenandId'_ (that we used as part of the key of each object too).
> We had to abandon this approach due to the poor performance of our MapReduce task. The main problem is that each task 'iterate' over each element in the "shared" cache when we only need to process the elements of the tenant 'X'.
> To fix this issue we were forced to create caches for each tenant, and now the MapReduce is as good as it gets (Infinispan 7 improved a lot the performance).
> The problem with our current approach is that it does not scale-out: For each tenant, we create several caches that leads to the creation of thread pools and other resources on each node.
> *PROPOSED SOLUTION*
> Allow creating 'indexes' (aka 'filters') that points to a group of element on the cache. The idea is to 'register' some index/filters on each cache an updating it on every put. Then, when executing a MapRecuce task we can indicate the 'index'/'filter' to execute the task over the referred entries only.
> This will help us in our use case but it can also improve any MapReduce task executed over infinispan if it is correctly 'tunned'. We are hopping to get your attention before reaching our scale-up limits :)
> Thanks in advance and happy holidays!
> (i) This is the main feature of Oracle Coherence to improve MapReduce-like tasks (more info [here|http://docs.oracle.com/cd/E18686_01/coh.37/e18692/querylang.htm#CEGG...])
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (ISPN-4884) Deployment scanner should be enabled to allow filter/converter jar deployment
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4884?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4884:
-----------------------------------------------
Vitalii Chepeliuk <vchepeli(a)redhat.com> changed the Status of [bug 1156397|https://bugzilla.redhat.com/show_bug.cgi?id=1156397] from ON_QA to VERIFIED
> Deployment scanner should be enabled to allow filter/converter jar deployment
> -----------------------------------------------------------------------------
>
> Key: ISPN-4884
> URL: https://issues.jboss.org/browse/ISPN-4884
> Project: Infinispan
> Issue Type: Enhancement
> Components: Server
> Affects Versions: 7.0.0.CR2
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Priority: Critical
> Fix For: 7.0.0.Final
>
>
> When we want to copy JARS and deploy it on JDG server in standalone/clustered.xml is no deployment-scanner element defined. It should be added when server is built
> Steps to Reproduce:
> 1. cp filter-converter.jar infinispan-server-7.0.0.CR2/standalone/deployments/
> 2. look at console output of server
> 3. check if there is no output from deployment scanner
> Current results: not output from deployment scanner, because it is not enabled
> Expected results: we should see following output in console log
> JBAS015012: Started FileSystemDeploymentService for directory /home/infinispan-server-7.0.0.CR2/standalone/deployments
> JBAS015876: Starting deployment of "filter-converter.jar" (runtime-name: "filter-converter.jar")
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[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 commented on ISPN-4500:
-----------------------------------------------
Vitalii Chepeliuk <vchepeli(a)redhat.com> changed the Status of [bug 1118593|https://bugzilla.redhat.com/show_bug.cgi?id=1118593] from ON_QA to VERIFIED
> 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
> 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.3.11#6341)
9 years, 3 months