[JBoss JIRA] (ISPN-8530) Default value of "merge-policy" xsd attribute should not be a lambda
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-8530?page=com.atlassian.jira.plugin.... ]
Ryan Emerson updated ISPN-8530:
-------------------------------
Summary: Default value of "merge-policy" xsd attribute should not be a lambda (was: Default value of "merge-policy" xsd attribute has an unstable name like org.infinispan.conflict.MergePolicies$$Lambda$72/520956294)
> Default value of "merge-policy" xsd attribute should not be a lambda
> --------------------------------------------------------------------
>
> Key: ISPN-8530
> URL: https://issues.jboss.org/browse/ISPN-8530
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 9.1.0.Final
> Reporter: Adrian Nistor
> Assignee: Ryan Emerson
> Fix For: 9.2.0.Final
>
>
> A different lambda name gets generated during each build.
> So an xsd created and deployed to http://docs.jboss.org/infinispan/schemas/ becomes out of sync after next build. We can fix that by redeploying the schema but we cannot assume users will always re-fetch it.
> Using static inner classes (non-anonymous) would be preferable in this case even though the lambda code looks nicer. This solution maintains backward compat with 9.1 too.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (ISPN-8448) Retried prepare times out while partition is in degraded mode
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-8448?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-8448:
-------------------------------
Fix Version/s: 9.1.3.Final
9.2.0.Beta1
(was: 9.2.0.Beta2)
(was: 9.1.4.Final)
> Retried prepare times out while partition is in degraded mode
> -------------------------------------------------------------
>
> Key: ISPN-8448
> URL: https://issues.jboss.org/browse/ISPN-8448
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 8.1.9.Final, 9.0.3.Final, 8.2.8.Final, 9.1.2.Final, 9.2.0.Alpha2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 8.1.10.Final, 8.2.9.Final, 9.2.0.Beta1, 9.1.3.Final
>
>
> Since ISPN-5046, prepare commands are retried if one of the prepare targets has left the cluster. However, when the cache enters degraded mode, the prepare targets still include the owners in other partitions, and the prepare command is retried again.
> Each retry automatically waits for cache topology {{<command topology> + 1}}. But the second retry is not really triggered by a topology change, so the retry blocks for {{remoteTimeout}} milliseconds before failing with a {{TimeoutException}}.
> This situation actually happens in {{OptimisticTxPartitionAndMergeDuringPrepareTest}}, but the tests do not fail because it doesn't wait for an {{AvailabilityException}} specifically: they just take 15+ seconds each.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (ISPN-8448) Retried prepare times out while partition is in degraded mode
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-8448?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-8448:
--------------------------------
Fix Version/s: 9.1.4.Final
(was: 9.1.3.Final)
> Retried prepare times out while partition is in degraded mode
> -------------------------------------------------------------
>
> Key: ISPN-8448
> URL: https://issues.jboss.org/browse/ISPN-8448
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 8.1.9.Final, 9.0.3.Final, 8.2.8.Final, 9.1.2.Final, 9.2.0.Alpha2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 8.1.10.Final, 8.2.9.Final, 9.2.0.Beta2, 9.1.4.Final
>
>
> Since ISPN-5046, prepare commands are retried if one of the prepare targets has left the cluster. However, when the cache enters degraded mode, the prepare targets still include the owners in other partitions, and the prepare command is retried again.
> Each retry automatically waits for cache topology {{<command topology> + 1}}. But the second retry is not really triggered by a topology change, so the retry blocks for {{remoteTimeout}} milliseconds before failing with a {{TimeoutException}}.
> This situation actually happens in {{OptimisticTxPartitionAndMergeDuringPrepareTest}}, but the tests do not fail because it doesn't wait for an {{AvailabilityException}} specifically: they just take 15+ seconds each.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (ISPN-8220) ClusteredCacheMgmtInterceptorMBeanTest fails intermittently
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-8220?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-8220:
--------------------------------
Fix Version/s: 9.1.4.Final
(was: 9.1.3.Final)
> ClusteredCacheMgmtInterceptorMBeanTest fails intermittently
> -----------------------------------------------------------
>
> Key: ISPN-8220
> URL: https://issues.jboss.org/browse/ISPN-8220
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management, Test Suite - Core
> Affects Versions: 9.1.0.Final
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Labels: testsuite_stability
> Fix For: 9.1.4.Final
>
>
> {code:java}
> org.infinispan.util.concurrent.TimeoutException: Timed out waiting for topology 6
> at org.infinispan.interceptors.impl.AsyncInterceptorChainImpl.invoke(AsyncInterceptorChainImpl.java:259)
> at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1679)
> at org.infinispan.cache.impl.CacheImpl.put(CacheImpl.java:1327)
> at org.infinispan.cache.impl.CacheImpl.put(CacheImpl.java:1793)
> at org.infinispan.cache.impl.CacheImpl.put(CacheImpl.java:282)
> at org.infinispan.cache.impl.AbstractDelegatingCache.put(AbstractDelegatingCache.java:358)
> at org.infinispan.cache.impl.EncoderCache.put(EncoderCache.java:655)
> at org.infinispan.jmx.ClusteredCacheMgmtInterceptorMBeanTest.testCorrectStatsInCluster(ClusteredCacheMgmtInterceptorMBeanTest.java:48)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: org.infinispan.util.concurrent.TimeoutException: Timed out waiting for topology 6
> at org.infinispan.interceptors.impl.BaseStateTransferInterceptor$CancellableRetry.run(BaseStateTransferInterceptor.java:347)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> ... 3 more
> ... Removed 16 stack frames
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (ISPN-8217) RestStoreTest.tearDown intermittent failure
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-8217?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-8217:
--------------------------------
Fix Version/s: 9.1.4.Final
(was: 9.1.3.Final)
> RestStoreTest.tearDown intermittent failure
> -------------------------------------------
>
> Key: ISPN-8217
> URL: https://issues.jboss.org/browse/ISPN-8217
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 9.1.0.Final
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Fix For: 9.1.4.Final
>
>
> The test fails intermittently with the following:
> {code:java}
> io.netty.channel.ChannelException: eventfd_write() failed: Bad file descriptor
> at io.netty.channel.epoll.Native.eventFdWrite(Native Method)
> at io.netty.channel.epoll.EpollEventLoop.wakeup(EpollEventLoop.java:126)
> at io.netty.util.concurrent.SingleThreadEventExecutor.shutdownGracefully(SingleThreadEventExecutor.java:589)
> at io.netty.util.concurrent.MultithreadEventExecutorGroup.shutdownGracefully(MultithreadEventExecutorGroup.java:163)
> at org.infinispan.server.core.transport.NettyTransport.stop(NettyTransport.java:161)
> at org.infinispan.server.core.AbstractProtocolServer.stop(AbstractProtocolServer.java:144)
> at org.infinispan.persistence.rest.RestStoreTest.tearDown(RestStoreTest.java:73)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> ... Removed 18 stack frames
>
> {code}
> I believe this is caused by Netty not closing connections properly. See [here|http://netty.io/news/2017/07/06/4-0-49-Final-4-1-13-Final.html]. Upgrading Netty to the latest version should hopefully resolve this issue.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (ISPN-8517) Lazily ressurect ice fromMemory
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-8517?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-8517:
--------------------------------
Fix Version/s: 9.1.4.Final
(was: 9.1.3.Final)
> Lazily ressurect ice fromMemory
> -------------------------------
>
> Key: ISPN-8517
> URL: https://issues.jboss.org/browse/ISPN-8517
> Project: Infinispan
> Issue Type: Sub-task
> Components: Off Heap
> Affects Versions: 9.2.0.Alpha2
> Reporter: William Burns
> Assignee: William Burns
> Fix For: 9.2.0.Beta2, 9.1.4.Final
>
>
> Currently many places do
> {code}
> ice = ice = offHeapEntryFactory.fromMemory(address)
> if (wrappedKey.equalsWrappedBytes(ice.getKey()))
> {code}
> In cases where this ends up being a miss, we read the entire value which is wasteful. And the CPU may not have the key in the cache size we read the object into memory. Where as if we do
> {code}
> if (offHeapEntryFactory.equalsKey(address, key))
> ice = ice = offHeapEntryFactory.fromMemory(address)
> {code}
> we know that CPU is reading from the address location twice in a row, which has a very high chance of still being in CPU caches which should hopefully provide better performance. We also then don't have to read the entire ice object in memory unless there was a hit.
> We also should change _performGet_ to return the address instead of the ice. This way callers can use this address for other optimizations such as when doing a _evict_ or _compute_ which have to read the entry first before a remove.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (ISPN-8516) OSGI integration tests random failure listening to RMI port
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-8516?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-8516:
--------------------------------
Fix Version/s: 9.1.4.Final
(was: 9.1.3.Final)
> OSGI integration tests random failure listening to RMI port
> -----------------------------------------------------------
>
> Key: ISPN-8516
> URL: https://issues.jboss.org/browse/ISPN-8516
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 9.1.2.Final, 9.2.0.Alpha2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Labels: testsuite_stability
> Fix For: 9.2.0.Beta2, 9.1.4.Final
>
>
> Because of [PAXEXAM-901|https://ops4j1.jira.com/browse/PAXEXAM-901], the [{{default-test}} Surefire execution|https://github.com/infinispan/infinispan/blob/master/integratio...] doesn't stop the {{@PerSuite}} Karaf container.
> That means the {{@PerClass}} Karaf container created for {{OSGiKarafFeaturesTest}} cannot listen to the RMI port:
> {noformat}
> 2017-11-06T19:51:01,920 | WARN | pool-15-thread-2 | Activator | 37 - org.apache.karaf.management.server - 4.1.2 | Error starting activator
> java.rmi.server.ExportException: Port already in use: 1099; nested exception is:
> java.net.BindException: Address already in use (Bind failed)
> at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:341) [?:?]
> at sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:249) [?:?]
> at sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:411) [?:?]
> at sun.rmi.transport.LiveRef.exportObject(LiveRef.java:147) [?:?]
> at sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:236) [?:?]
> at sun.rmi.registry.RegistryImpl.setup(RegistryImpl.java:213) [?:?]
> at sun.rmi.registry.RegistryImpl.<init>(RegistryImpl.java:173) [?:?]
> at sun.rmi.registry.RegistryImpl.<init>(RegistryImpl.java:144) [?:?]
> at java.rmi.registry.LocateRegistry.createRegistry(LocateRegistry.java:239) [?:?]
> at org.apache.karaf.management.RmiRegistryFactory.init(RmiRegistryFactory.java:126) [37:org.apache.karaf.management.server:4.1.2]
> at org.apache.karaf.management.internal.Activator.doStart(Activator.java:104) [37:org.apache.karaf.management.server:4.1.2]
> at org.apache.karaf.util.tracker.BaseActivator.run(BaseActivator.java:242) [37:org.apache.karaf.management.server:4.1.2]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
> at java.lang.Thread.run(Thread.java:748) [?:?]
> Caused by: java.net.BindException: Address already in use (Bind failed)
> at java.net.PlainSocketImpl.socketBind(Native Method) ~[?:?]
> at java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387) ~[?:?]
> at java.net.ServerSocket.bind(ServerSocket.java:375) ~[?:?]
> at java.net.ServerSocket.<init>(ServerSocket.java:237) ~[?:?]
> at org.apache.karaf.management.RmiRegistryFactory$KarafServerSocketFactory.createServerSocket(RmiRegistryFactory.java:181) ~[?:?]
> at sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(TCPEndpoint.java:666) ~[?:?]
> at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:330) ~[?:?]
> ... 16 more
> {noformat}
> Usually the tests still pass, but I believe this random failure is caused by {{OSGiKarafFeaturesTest}} connecting to the wrong Karaf instance:
> {noformat}
> 19:51:06,280 ERROR (main:[]) [TestSuiteProgress] Test failed: OSGiKarafFeaturesTest.testCleanInstall
> java.lang.ClassNotFoundException: org.objectweb.howl.log.LogConfigurationException (no security manager: RMI class loader disabled)
> at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:396) ~[?:1.8.0_151]
> at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:186) ~[?:1.8.0_151]
> at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:637) ~[?:1.8.0_151]
> at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:264) ~[?:1.8.0_151]
> at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:219) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1868) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1751) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2042) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1573) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2287) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.defaultReadObject(ObjectInputStream.java:563) ~[?:1.8.0_151]
> at java.lang.Throwable.readObject(Throwable.java:914) ~[?:1.8.0_151]
> at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) ~[?:?]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_151]
> at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_151]
> at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1158) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2178) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2069) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1573) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2287) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.defaultReadObject(ObjectInputStream.java:563) ~[?:1.8.0_151]
> at java.lang.Throwable.readObject(Throwable.java:914) ~[?:1.8.0_151]
> at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) ~[?:?]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_151]
> at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_151]
> at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1158) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2178) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2069) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1573) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:433) ~[?:1.8.0_151]
> at java.util.ArrayList.readObject(ArrayList.java:797) ~[?:1.8.0_151]
> at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source) ~[?:?]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_151]
> at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_151]
> at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1158) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2178) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2069) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1573) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2287) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.defaultReadObject(ObjectInputStream.java:563) ~[?:1.8.0_151]
> at java.lang.Throwable.readObject(Throwable.java:914) ~[?:1.8.0_151]
> at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) ~[?:?]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_151]
> at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_151]
> at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1158) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2178) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2069) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1573) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2287) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.defaultReadObject(ObjectInputStream.java:563) ~[?:1.8.0_151]
> at java.lang.Throwable.readObject(Throwable.java:914) ~[?:1.8.0_151]
> at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) ~[?:?]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_151]
> at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_151]
> at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1158) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2178) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2069) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1573) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2287) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2211) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2069) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1573) ~[?:1.8.0_151]
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:433) ~[?:1.8.0_151]
> at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:252) ~[?:1.8.0_151]
> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:161) ~[?:1.8.0_151]
> at java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:227) ~[?:1.8.0_151]
> at java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:179) ~[?:1.8.0_151]
> at com.sun.proxy.$Proxy41.remoteCall(Unknown Source) ~[?:?]
> at org.ops4j.pax.exam.rbc.client.intern.RemoteBundleContextClientImpl$1.invoke(RemoteBundleContextClientImpl.java:102) ~[pax-exam-container-rbc-client-4.11.0.jar:?]
> at com.sun.proxy.$Proxy42.call(Unknown Source) ~[?:?]
> at org.ops4j.pax.exam.rbc.client.intern.RemoteBundleContextClientImpl.call(RemoteBundleContextClientImpl.java:290) ~[pax-exam-container-rbc-client-4.11.0.jar:?]
> at org.ops4j.pax.exam.container.remote.RBCRemoteTarget.call(RBCRemoteTarget.java:60) ~[pax-exam-container-remote-4.11.0.jar:?]
> at org.ops4j.pax.exam.karaf.container.internal.KarafTestContainer.call(KarafTestContainer.java:652) ~[pax-exam-container-karaf-4.11.0.jar:?]
> at org.ops4j.pax.exam.spi.reactors.EagerSingleStagedReactor.invoke(EagerSingleStagedReactor.java:109) ~[pax-exam-spi-4.11.0.jar:?]
> at org.ops4j.pax.exam.junit.impl.ProbeRunner$2.evaluate(ProbeRunner.java:267) ~[pax-exam-junit4-4.11.0.jar:?]
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) [junit-4.11.jar:?]
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) [junit-4.11.jar:?]
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) [junit-4.11.jar:?]
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) [junit-4.11.jar:?]
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) [junit-4.11.jar:?]
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) [junit-4.11.jar:?]
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) [junit-4.11.jar:?]
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) [junit-4.11.jar:?]
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309) [junit-4.11.jar:?]
> at org.ops4j.pax.exam.junit.impl.ProbeRunner.run(ProbeRunner.java:98) [pax-exam-junit4-4.11.0.jar:?]
> at org.ops4j.pax.exam.junit.PaxExam.run(PaxExam.java:93) [pax-exam-junit4-4.11.0.jar:?]
> at org.infinispan.it.osgi.util.CustomPaxExamRunner.run(CustomPaxExamRunner.java:73) [test-classes/:?]
> at org.junit.runners.Suite.runChild(Suite.java:127) [junit-4.11.jar:?]
> at org.junit.runners.Suite.runChild(Suite.java:26) [junit-4.11.jar:?]
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) [junit-4.11.jar:?]
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) [junit-4.11.jar:?]
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) [junit-4.11.jar:?]
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) [junit-4.11.jar:?]
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) [junit-4.11.jar:?]
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309) [junit-4.11.jar:?]
> at org.junit.runners.Suite.runChild(Suite.java:127) [junit-4.11.jar:?]
> at org.junit.runners.Suite.runChild(Suite.java:26) [junit-4.11.jar:?]
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) [junit-4.11.jar:?]
> at org.apache.maven.surefire.junitcore.pc.Scheduler$1.run(Scheduler.java:393) [surefire-junit47-2.20.jar:2.20]
> at org.apache.maven.surefire.junitcore.pc.InvokerStrategy.schedule(InvokerStrategy.java:54) [surefire-junit47-2.20.jar:2.20]
> at org.apache.maven.surefire.junitcore.pc.Scheduler.schedule(Scheduler.java:352) [surefire-junit47-2.20.jar:2.20]
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) [junit-4.11.jar:?]
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) [junit-4.11.jar:?]
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) [junit-4.11.jar:?]
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309) [junit-4.11.jar:?]
> at org.apache.maven.surefire.junitcore.pc.ParallelComputerBuilder$PC$1.run(ParallelComputerBuilder.java:595) [surefire-junit47-2.20.jar:2.20]
> at org.apache.maven.surefire.junitcore.JUnitCore.run(JUnitCore.java:55) [surefire-junit47-2.20.jar:2.20]
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:137) [surefire-junit47-2.20.jar:2.20]
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:107) [surefire-junit47-2.20.jar:2.20]
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:83) [surefire-junit47-2.20.jar:2.20]
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:75) [surefire-junit47-2.20.jar:2.20]
> at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:157) [surefire-junit47-2.20.jar:2.20]
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:386) [surefire-booter-2.20.jar:2.20]
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:323) [surefire-booter-2.20.jar:2.20]
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:143) [surefire-booter-2.20.jar:2.20]
> {noformat}
> The Windows/Solaris failures probably have the same cause, so we shouldn't need {{@SkipOnOS}} once we fix this.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months