[JBoss JIRA] (ISPN-8590) Operations Code from client to server should be a short
by Katia Aresti (JIRA)
[ https://issues.jboss.org/browse/ISPN-8590?page=com.atlassian.jira.plugin.... ]
Katia Aresti updated ISPN-8590:
-------------------------------
Description:
Hotrod operations sent from the client to the server are today read like byte (this is not the case concerning responses codes, that are read like short from the hotrod client).
New hotrod operations and request codes won't enter in a byte soon.
was:
Hotrod operations sent from the client to the server are today treated like byte (this is not the case concerning responses codes, that are read like short from the hotrod client).
New hotrod operations and request codes won't enter in a byte soon.
> Operations Code from client to server should be a short
> -------------------------------------------------------
>
> Key: ISPN-8590
> URL: https://issues.jboss.org/browse/ISPN-8590
> Project: Infinispan
> Issue Type: Enhancement
> Components: Hot Rod
> Reporter: Katia Aresti
> Assignee: Katia Aresti
>
> Hotrod operations sent from the client to the server are today read like byte (this is not the case concerning responses codes, that are read like short from the hotrod client).
> New hotrod operations and request codes won't enter in a byte soon.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (ISPN-8590) Operations Code from client to server should be a short
by Katia Aresti (JIRA)
Katia Aresti created ISPN-8590:
----------------------------------
Summary: Operations Code from client to server should be a short
Key: ISPN-8590
URL: https://issues.jboss.org/browse/ISPN-8590
Project: Infinispan
Issue Type: Enhancement
Components: Hot Rod
Reporter: Katia Aresti
Assignee: Katia Aresti
Hotrod operations send from the client to the server are today treated like byte (this is not the case concerning responses codes, that are read like short from the hotrod client).
New hotrod operations and request codes won't enter in a byte soon.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (ISPN-6395) Unify clustered queries with non clustered queries
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-6395?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-6395:
------------------------------------
Description:
Clustered queries currently have a different method, and they work on top on non-shared indexes.
We should detect (or make it explicitly configurable) the fact that the index is not shared and use clustered query internally, but exposing a single method, with a new parameter to allow doing a query in a single step or two steps (broadcast).
Last, but not least, we should offer the possibility to broadcast Ickle queries apart from Lucene Queries, as Ickle queries are String and don't have serialization issues.
was:
Clustered queries currently have a different method, and they work on top on non-shared indexes.
We should detect (or make it explicitly configurable) the fact that the index is not shared and use clustered query internally, but exposing a single Query method.
We should also expose a new parameter in the Query API to allow doing a query in a single step or two steps (broadcast).
Last, but not least, we should offer the possibility to broadcast Ickle queries apart from LuceneQueries
> Unify clustered queries with non clustered queries
> --------------------------------------------------
>
> Key: ISPN-6395
> URL: https://issues.jboss.org/browse/ISPN-6395
> Project: Infinispan
> Issue Type: Feature Request
> Components: Embedded Querying
> Affects Versions: 9.2.0.Beta1
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Fix For: 9.2.0.Final
>
>
> Clustered queries currently have a different method, and they work on top on non-shared indexes.
> We should detect (or make it explicitly configurable) the fact that the index is not shared and use clustered query internally, but exposing a single method, with a new parameter to allow doing a query in a single step or two steps (broadcast).
> Last, but not least, we should offer the possibility to broadcast Ickle queries apart from Lucene Queries, as Ickle queries are String and don't have serialization issues.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (ISPN-6395) Unify clustered queries with non clustered queries
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-6395?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-6395:
------------------------------------
Description:
Clustered queries currently have a different method, and they work on top on non-shared indexes.
We should detect (or make it explicitly configurable) the fact that the index is not shared and use clustered query internally, but exposing a single Query method.
We should also expose a new parameter in the Query API to allow doing a query in a single step or two steps (broadcast).
Last, but not least, we should offer the possibility to broadcast Ickle queries apart from LuceneQueries
was:
Clustered queries currently have a different method, and they work on top on non-shared indexes.
We should detect (or make it explicitly configurable) the fact that the index is not shared and use clustered query internally, but exposing a single Query interface.
We should also expose a new parameter in the Query API to allow doing a query in a single step or two steps (broadcast).
Last, but not least, we should offer the possibility to broadcast Ickle queries apart from LuceneQueries
> Unify clustered queries with non clustered queries
> --------------------------------------------------
>
> Key: ISPN-6395
> URL: https://issues.jboss.org/browse/ISPN-6395
> Project: Infinispan
> Issue Type: Feature Request
> Components: Embedded Querying
> Affects Versions: 9.2.0.Beta1
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Fix For: 9.2.0.Final
>
>
> Clustered queries currently have a different method, and they work on top on non-shared indexes.
> We should detect (or make it explicitly configurable) the fact that the index is not shared and use clustered query internally, but exposing a single Query method.
> We should also expose a new parameter in the Query API to allow doing a query in a single step or two steps (broadcast).
> Last, but not least, we should offer the possibility to broadcast Ickle queries apart from LuceneQueries
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (ISPN-6395) Unify clustered queries with non clustered queries
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-6395?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-6395:
------------------------------------
Description:
Clustered queries currently have a different method, and they work on top on non-shared indexes.
We should detect (or make it explicitly configurable) the fact that the index is not shared and use clustered query internally, but exposing a single Query interface.
We should also expose a new parameter in the Query API to allow doing a query in a single step or two steps (broadcast).
Last, but not least, we should offer the possibility to broadcast Ickle queries apart from LuceneQueries
was:
Clustered queries currently have a different API, and they work on top on non-shared indexes.
We should detect (or make it explicitly configurable) the fact that the index is not shared and use clustered query internally, but exposing a single Query interface.
We should also expose a new parameter in the Query API to allow doing a query in a single step or two steps (broadcast).
Last, but not least, we should offer the possibility to broadcast Ickle queries apart from LuceneQueries
> Unify clustered queries with non clustered queries
> --------------------------------------------------
>
> Key: ISPN-6395
> URL: https://issues.jboss.org/browse/ISPN-6395
> Project: Infinispan
> Issue Type: Feature Request
> Components: Embedded Querying
> Affects Versions: 9.2.0.Beta1
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Fix For: 9.2.0.Final
>
>
> Clustered queries currently have a different method, and they work on top on non-shared indexes.
> We should detect (or make it explicitly configurable) the fact that the index is not shared and use clustered query internally, but exposing a single Query interface.
> We should also expose a new parameter in the Query API to allow doing a query in a single step or two steps (broadcast).
> Last, but not least, we should offer the possibility to broadcast Ickle queries apart from LuceneQueries
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (ISPN-8589) Cache @Stop methods should be invoked in privileged block
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-8589?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-8589:
--------------------------------
Summary: Cache @Stop methods should be invoked in privileged block (was: HotRodDigestMd5AuthIT logs SecurityException while stopping server)
> Cache @Stop methods should be invoked in privileged block
> ---------------------------------------------------------
>
> Key: ISPN-8589
> URL: https://issues.jboss.org/browse/ISPN-8589
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Server
> Affects Versions: 9.2.0.Beta1
> Reporter: Dan Berindei
> Assignee: William Burns
> Fix For: 9.2.0.Beta2
>
>
> Also happens in {{HotRodKrbAuthIT}}.
> {noformat}
> 14:54:42,512 WARN [org.infinispan.factories.ComponentRegistry] (MSC service thread 1-1) ISPN000189: While stopping a cache or cache manager, one of its components failed to stop: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.stream.impl.IteratorHandler.stop() on object of type IteratorHandler
> at org.infinispan.commons.util.SecurityActions.lambda$invokeAccessibly$0(SecurityActions.java:83)
> at org.infinispan.commons.util.SecurityActions.doPrivileged(SecurityActions.java:71)
> at org.infinispan.commons.util.SecurityActions.invokeAccessibly(SecurityActions.java:76)
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:165)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:883)
> at org.infinispan.factories.AbstractComponentRegistry.internalStop(AbstractComponentRegistry.java:684)
> at org.infinispan.factories.AbstractComponentRegistry.stop(AbstractComponentRegistry.java:583)
> at org.infinispan.factories.ComponentRegistry.stop(ComponentRegistry.java:259)
> at org.infinispan.cache.impl.CacheImpl.performImmediateShutdown(CacheImpl.java:1046)
> at org.infinispan.cache.impl.CacheImpl.stop(CacheImpl.java:1010)
> at org.infinispan.cache.impl.AbstractDelegatingCache.stop(AbstractDelegatingCache.java:420)
> at org.infinispan.registry.impl.InternalCacheRegistryImpl.unregisterInternalCache(InternalCacheRegistryImpl.java:79)
> at org.infinispan.server.hotrod.HotRodServer.stop(HotRodServer.java:485)
> at org.infinispan.server.endpoint.subsystem.ProtocolServerService.doStop(ProtocolServerService.java:216)
> at org.infinispan.server.endpoint.subsystem.ProtocolServerService.stop(ProtocolServerService.java:206)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017)
> 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.lang.SecurityException: ISPN000287: Unauthorized access: subject 'null' lacks 'LISTEN' permission
> at org.infinispan.security.impl.AuthorizationHelper.checkPermission(AuthorizationHelper.java:87)
> at org.infinispan.security.impl.AuthorizationHelper.checkPermission(AuthorizationHelper.java:57)
> at org.infinispan.manager.DefaultCacheManager.removeListener(DefaultCacheManager.java:749)
> at org.infinispan.stream.impl.IteratorHandler.stop(IteratorHandler.java:92)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.infinispan.commons.util.SecurityActions.lambda$invokeAccessibly$0(SecurityActions.java:79)
> ... 19 more
> {noformat}
--
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 Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-8516?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-8516:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> 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