[JBoss JIRA] (ISPN-4322) AS Remote Client Module Integration Tests module fails with IBM JDK
by Vitalii Chepeliuk (JIRA)
[ https://issues.jboss.org/browse/ISPN-4322?page=com.atlassian.jira.plugin.... ]
Vitalii Chepeliuk reassigned ISPN-4322:
---------------------------------------
Assignee: Vitalii Chepeliuk
> AS Remote Client Module Integration Tests module fails with IBM JDK
> -------------------------------------------------------------------
>
> Key: ISPN-4322
> URL: https://issues.jboss.org/browse/ISPN-4322
> Project: Infinispan
> Issue Type: Bug
> Components: Integration
> Affects Versions: 7.0.0.Alpha2, 7.0.0.Alpha3, 7.0.0.Alpha4
> Environment: IBM JDK, RHEL
> Reporter: Vitalii Chepeliuk
> Assignee: Vitalii Chepeliuk
> Labels: testsuite_stability
>
> {noformat}
> [INFO] ------------------------------------------------------------------------
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Infinispan BOM .................................... SUCCESS [10.419s]
> [INFO] Infinispan Common Parent .......................... SUCCESS [16.691s]
> [INFO] Infinispan Commons ................................ SUCCESS [30.414s]
> [INFO] Infinispan Core ................................... SUCCESS [1:20:24.345s]
> [INFO] Parent pom for server modules ..................... SUCCESS [2.764s]
> [INFO] Infinispan Server - Core Components ............... SUCCESS [1:39.998s]
> [INFO] Infinispan Query DSL API .......................... SUCCESS [3.182s]
> [INFO] Parent pom for cachestore modules ................. SUCCESS [1.421s]
> [INFO] Infinispan JDBC CacheStore ........................ SUCCESS [7:13.024s]
> [INFO] Parent pom for the Lucene integration modules ..... SUCCESS [1.302s]
> [INFO] Infinispan integration with Lucene v.3.x .......... SUCCESS [1:22.270s]
> [INFO] Infinispan Lucene Directory Implementation ........ SUCCESS [5.801s]
> [INFO] Infinispan Query API .............................. SUCCESS [16:27.946s]
> [INFO] Infinispan Tools .................................. SUCCESS [12.958s]
> [INFO] Infinispan Remote Query Client .................... SUCCESS [3.958s]
> [INFO] Infinispan Remote Query Server .................... SUCCESS [16.646s]
> [INFO] Infinispan JPA CacheStore ......................... SUCCESS [54.680s]
> [INFO] Infinispan Hot Rod Server ......................... SUCCESS [6:13.951s]
> [INFO] Infinispan Hot Rod Client ......................... SUCCESS [9:17.450s]
> [INFO] Parent pom for compatibility modules .............. SUCCESS [0.876s]
> [INFO] infinispan-custom52x-store ........................ SUCCESS [33.084s]
> [INFO] infinispan-adaptor52x ............................. SUCCESS [4:05.587s]
> [INFO] Infinispan remote CacheStore ...................... SUCCESS [53.506s]
> [INFO] Infinispan LevelDB CacheStore ..................... SUCCESS [1:19.592s]
> [INFO] Infinispan REST Server ............................ SUCCESS [2:08.409s]
> [INFO] Infinispan REST CacheStore ........................ SUCCESS [16.715s]
> [INFO] Infinispan Memcached Server ....................... SUCCESS [2:22.394s]
> [INFO] Infinispan RHQ Plugin ............................. SUCCESS [42.140s]
> [INFO] Infinispan CLI Server ............................. SUCCESS [48.143s]
> [INFO] Infinispan CLI Client ............................. SUCCESS [16.878s]
> [INFO] Infinispan CDI support ............................ SUCCESS [1:24.550s]
> [INFO] Infinispan AS/EAP modules for library ............. SUCCESS [18.319s]
> [INFO] Infinispan AS/EAP modules for remote client ....... SUCCESS [2.329s]
> [INFO] Integration tests: Security Tests ................. SUCCESS [2:11.936s]
> [INFO] Integration tests: SecurityManager tests .......... SUCCESS [13.313s]
> [INFO] Integration tests: AS Module Integration Tests .... SUCCESS [1:10.370s]
> [INFO] Integration tests: AS Remote Client Module Integration Tests FAILURE [57.162s]
> [INFO] Integration tests: Lucene Directory with Infinispan Query SUCCESS [23.074s]
> [INFO] Integration tests: Infinispan compatibility mode .. SUCCESS [35.351s]
> [INFO] Infinispan Distribution ........................... SUCCESS [1.090s]
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 2:26:30.994s
> [INFO] Finished at: Fri May 23 21:38:55 EDT 2014
> [INFO] Final Memory: 227M/542M
> [INFO] ------------------------------------------------------------------------
> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-antrun-plugin:1.7:run (infinispan-server-shutdown) on project infinispan-as-module-remote-client-integrationtests: An Ant BuildException has occured: Execute failed: java.io.IOException: Cannot run program "/qa/tools/opt/amd64/ibm-java-70/bin/jps" (in directory "/mnt/hudson_workspace/workspace/edg-60-ispn-testsuite-rhel/7e5d4f04/infinispan/integrationtests/as-integration-remote-client"): error=2, No such file or directory
> [ERROR] around Ant part ...<exec executable="/qa/tools/opt/amd64/ibm-java-70/bin/jps" output="jps.pid" osfamily="unix"/>... @ 4:96 in /mnt/hudson_workspace/workspace/edg-60-ispn-testsuite-rhel/7e5d4f04/infinispan/integrationtests/as-integration-remote-client/target/antrun/build-main.xml
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please read the following articles:
> [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the command
> [ERROR] mvn <goals> -rf :infinispan-as-module-remote-client-integrationtests
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (ISPN-5131) Deploy custom cache store to Infinispan Server
by Sebastian Łaskawiec (JIRA)
[ https://issues.jboss.org/browse/ISPN-5131?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec commented on ISPN-5131:
-------------------------------------------
{quote}
Indeed you don't want to limit users deploying instances of AdvancedLoadWriteStore only. You want to support deploying AdvancedCacheLoader, CacheLoader, AdvancedCacheWriter, CacheWriter and ExternalStore as well. This should be tested to make sure it works as expected. Ideally, you'd make sure you can support all of these with the least amount of internal changes. It will require though supporting multiple META-INF/services/xxx definitions based on which interface the user decides to implement.
{quote}
I would like to propose slightly different approach. Let's create new interface called CacheStoreFactory:
{code}
public interface CacheStoreFacory {
public CacheLoader createCacheLoader();
public CacheWriter createCacheWriter();
}
{code}
This interface will need to be implemented in deployable cache store. {{PersistenceManagerImpl}} would use such factories to obtain {{CacheLoader}} and {{CacheWriter}} instances. I think the biggest advantage of this approach is that we have only one service responsible for deployable Cache stores. The client has also the same level of flexibility (one might implement only one {{ExternalStore}} and return the same instance in both methods. The biggest drawback is slightly bigger refactoring in core (but on the other hand we guarded by a lot of unit/interaction tests there)
Does it sound reasonable or would you still vote for multiple services?
> Deploy custom cache store to Infinispan Server
> ----------------------------------------------
>
> Key: ISPN-5131
> URL: https://issues.jboss.org/browse/ISPN-5131
> Project: Infinispan
> Issue Type: Feature Request
> Components: Loaders and Stores, Server
> Reporter: Tristan Tarrant
> Assignee: Sebastian Łaskawiec
> Fix For: 7.2.0.Final
>
>
> h2. Overview
> Support the deployment and configuration of a custom cache store.
> h2. Client Perspective
> In order to create a deployable Cache Store the client will have to implement {{AdvancedLoadWriteStoreFactory}} (which will contain factory methods for creating {{AdvancedLoadWriteStore}}). Next, the factory will have to be annotated with {{@NamedFactory}} and placed into a jar together with proper entry of {{META-INF/services/org.infinispan.persistence.AdvancedLoadWriteStoreFactory}}. The last activity is to deploy given jar into Hotrod server.
> h2. Implementation overview
> The implementation is based on Deployable Filters and Converters.
> Currently all writers and loaders are instantiated in {{PersistenceManagerImpl#createLoadersAndWriters}}. This implementation will be modified to use {{LoadWriteStoreRegistry}}, which will contain a list of {{AdvancedLoadWriteStoreFactories}}. One of the factories will be added by default - the local one (which will the same mechanism as we do now - {{Util.getInstance(classAnnotation)}}. Other {{AdvancedLoadWriteStoreFactories}} will be added after deployment scanning.
> h2. Implementation doubts and questions:
> * Should we expose a factory for {{AdvancedLoadWriteStore}} or should we include also {{ExternalStore}} (or even separate factory for {{CacheLoader}} and {{CacheWriter}}?
> * How to ensure that deployment scanning has finished before creating instantiating {{AdvancedLoadWriteStore}}?
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (ISPN-5131) Deploy custom cache store to Infinispan Server
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-5131?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño commented on ISPN-5131:
----------------------------------------
Indeed you don't want to limit users deploying instances of AdvancedLoadWriteStore only. You want to support deploying AdvancedCacheLoader, CacheLoader, AdvancedCacheWriter, CacheWriter and ExternalStore as well. This should be tested to make sure it works as expected. Ideally, you'd make sure you can support all of these with the least amount of internal changes. It will require though supporting multiple META-INF/services/xxx definitions based on which interface the user decides to implement.
org.infinispan.server.endpoint.subsystem.EndpointSubsystemAdd defines at which point the processors run, by defining the phase at which to run. That's what makes sure that filters and converters are processed after they've been deployed and not earlier.
Looks good otherwise! Indeed, use filter/converters deployment work as template for this :)
> Deploy custom cache store to Infinispan Server
> ----------------------------------------------
>
> Key: ISPN-5131
> URL: https://issues.jboss.org/browse/ISPN-5131
> Project: Infinispan
> Issue Type: Feature Request
> Components: Loaders and Stores, Server
> Reporter: Tristan Tarrant
> Assignee: Sebastian Łaskawiec
> Fix For: 7.2.0.Final
>
>
> h2. Overview
> Support the deployment and configuration of a custom cache store.
> h2. Client Perspective
> In order to create a deployable Cache Store the client will have to implement {{AdvancedLoadWriteStoreFactory}} (which will contain factory methods for creating {{AdvancedLoadWriteStore}}). Next, the factory will have to be annotated with {{@NamedFactory}} and placed into a jar together with proper entry of {{META-INF/services/org.infinispan.persistence.AdvancedLoadWriteStoreFactory}}. The last activity is to deploy given jar into Hotrod server.
> h2. Implementation overview
> The implementation is based on Deployable Filters and Converters.
> Currently all writers and loaders are instantiated in {{PersistenceManagerImpl#createLoadersAndWriters}}. This implementation will be modified to use {{LoadWriteStoreRegistry}}, which will contain a list of {{AdvancedLoadWriteStoreFactories}}. One of the factories will be added by default - the local one (which will the same mechanism as we do now - {{Util.getInstance(classAnnotation)}}. Other {{AdvancedLoadWriteStoreFactories}} will be added after deployment scanning.
> h2. Implementation doubts and questions:
> * Should we expose a factory for {{AdvancedLoadWriteStore}} or should we include also {{ExternalStore}} (or even separate factory for {{CacheLoader}} and {{CacheWriter}}?
> * How to ensure that deployment scanning has finished before creating instantiating {{AdvancedLoadWriteStore}}?
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (ISPN-5208) Avoid invalid topology
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-5208?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-5208:
----------------------------------
Fix Version/s: 7.2.0.Final
> Avoid invalid topology
> ----------------------
>
> Key: ISPN-5208
> URL: https://issues.jboss.org/browse/ISPN-5208
> Project: Infinispan
> Issue Type: Enhancement
> Components: Server
> Reporter: Takayoshi Kimura
> Assignee: Galder Zamarreño
> Labels: jdg641
> Fix For: 7.2.0.Final
>
>
> We've seen some invalid topology propagated to client and it causes ArrayIndexOutOfBoundsException:
> {noformat}
> Caused by: java.lang.ArrayIndexOutOfBoundsException: 0
> at org.infinispan.client.hotrod.impl.transport.tcp.RoundRobinBalancingStrategy.getServerByIndex(RoundRobinBalancingStrategy.java:68) [infinispan-client-hotrod-6.1.0.Final-redhat-4.jar:6.1.0.Final-redhat-4]
> at org.infinispan.client.hotrod.impl.transport.tcp.RoundRobinBalancingStrategy.nextServer(RoundRobinBalancingStrategy.java:44) [infinispan-client-hotrod-6.1.0.Final-redhat-4.jar:6.1.0.Final-redhat-4]
> at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory.nextServer(TcpTransportFactory.java:220) [infinispan-client-hotrod-6.1.0.Final-redhat-4.jar:6.1.0.Final-redhat-4]
> at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory.getTransport(TcpTransportFactory.java:194) [infinispan-client-hotrod-6.1.0.Final-redhat-4.jar:6.1.0.Final-redhat-4]
> at org.infinispan.client.hotrod.impl.operations.FaultTolerantPingOperation.getTransport(FaultTolerantPingOperation.java:27) [infinispan-client-hotrod-6.1.0.Final-redhat-4.jar:6.1.0.Final-redhat-4]
> at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:48) [infinispan-client-hotrod-6.1.0.Final-redhat-4.jar:6.1.0.Final-redhat-4]
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.ping(RemoteCacheImpl.java:535) [infinispan-client-hotrod-6.1.0.Final-redhat-4.jar:6.1.0.Final-redhat-4]
> at org.infinispan.client.hotrod.RemoteCacheManager.ping(RemoteCacheManager.java:635) [infinispan-client-hotrod-6.1.0.Final-redhat-4.jar:6.1.0.Final-redhat-4]
> at org.infinispan.client.hotrod.RemoteCacheManager.createRemoteCache(RemoteCacheManager.java:616) [infinispan-client-hotrod-6.1.0.Final-redhat-4.jar:6.1.0.Final-redhat-4]
> at org.infinispan.client.hotrod.RemoteCacheManager.getCache(RemoteCacheManager.java:527) [infinispan-client-hotrod-6.1.0.Final-redhat-4.jar:6.1.0.Final-redhat-4]
> at org.infinispan.client.hotrod.RemoteCacheManager.getCache(RemoteCacheManager.java:523) [infinispan-client-hotrod-6.1.0.Final-redhat-4.jar:6.1.0.Final-redhat-4]
> {noformat}
> {noformat}
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 0
> at org.infinispan.client.hotrod.impl.consistenthash.SegmentConsistentHash.getServer(SegmentConsistentHash.java:33)
> at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory.getTransport(TcpTransportFactory.java:204)
> at org.infinispan.client.hotrod.impl.operations.AbstractKeyOperation.getTransport(AbstractKeyOperation.java:40)
> at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:48)
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.put(RemoteCacheImpl.java:237)
> at org.infinispan.client.hotrod.impl.RemoteCacheSupport.put(RemoteCacheSupport.java:79)
> at sample.Main.main(Main.java:16)
> {noformat}
> It happens on both Hot Rod 2 and 1.3 clients.
> It's really hard to reproduce this state and we don't have a consistent way to reproduce it. However when this happens there is always view change happening so it's related to view change.
> Judging from the stack trace, the client receives numOwners=0 or numSegments=0 topology from the server.
> Also we are unable to find to recover this situation. Rebooting random nodes don't help and keep getting this exceptions on client side.
> Until we can find the root cause, I think it's better to add a guard to avoid this kind invalid topology stored in the server side and propagated to the clients.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (ISPN-5208) Avoid invalid topology
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-5208?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-5208:
----------------------------------
Labels: jdg641 (was: )
> Avoid invalid topology
> ----------------------
>
> Key: ISPN-5208
> URL: https://issues.jboss.org/browse/ISPN-5208
> Project: Infinispan
> Issue Type: Enhancement
> Components: Server
> Reporter: Takayoshi Kimura
> Assignee: Galder Zamarreño
> Labels: jdg641
>
> We've seen some invalid topology propagated to client and it causes ArrayIndexOutOfBoundsException:
> {noformat}
> Caused by: java.lang.ArrayIndexOutOfBoundsException: 0
> at org.infinispan.client.hotrod.impl.transport.tcp.RoundRobinBalancingStrategy.getServerByIndex(RoundRobinBalancingStrategy.java:68) [infinispan-client-hotrod-6.1.0.Final-redhat-4.jar:6.1.0.Final-redhat-4]
> at org.infinispan.client.hotrod.impl.transport.tcp.RoundRobinBalancingStrategy.nextServer(RoundRobinBalancingStrategy.java:44) [infinispan-client-hotrod-6.1.0.Final-redhat-4.jar:6.1.0.Final-redhat-4]
> at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory.nextServer(TcpTransportFactory.java:220) [infinispan-client-hotrod-6.1.0.Final-redhat-4.jar:6.1.0.Final-redhat-4]
> at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory.getTransport(TcpTransportFactory.java:194) [infinispan-client-hotrod-6.1.0.Final-redhat-4.jar:6.1.0.Final-redhat-4]
> at org.infinispan.client.hotrod.impl.operations.FaultTolerantPingOperation.getTransport(FaultTolerantPingOperation.java:27) [infinispan-client-hotrod-6.1.0.Final-redhat-4.jar:6.1.0.Final-redhat-4]
> at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:48) [infinispan-client-hotrod-6.1.0.Final-redhat-4.jar:6.1.0.Final-redhat-4]
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.ping(RemoteCacheImpl.java:535) [infinispan-client-hotrod-6.1.0.Final-redhat-4.jar:6.1.0.Final-redhat-4]
> at org.infinispan.client.hotrod.RemoteCacheManager.ping(RemoteCacheManager.java:635) [infinispan-client-hotrod-6.1.0.Final-redhat-4.jar:6.1.0.Final-redhat-4]
> at org.infinispan.client.hotrod.RemoteCacheManager.createRemoteCache(RemoteCacheManager.java:616) [infinispan-client-hotrod-6.1.0.Final-redhat-4.jar:6.1.0.Final-redhat-4]
> at org.infinispan.client.hotrod.RemoteCacheManager.getCache(RemoteCacheManager.java:527) [infinispan-client-hotrod-6.1.0.Final-redhat-4.jar:6.1.0.Final-redhat-4]
> at org.infinispan.client.hotrod.RemoteCacheManager.getCache(RemoteCacheManager.java:523) [infinispan-client-hotrod-6.1.0.Final-redhat-4.jar:6.1.0.Final-redhat-4]
> {noformat}
> {noformat}
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 0
> at org.infinispan.client.hotrod.impl.consistenthash.SegmentConsistentHash.getServer(SegmentConsistentHash.java:33)
> at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory.getTransport(TcpTransportFactory.java:204)
> at org.infinispan.client.hotrod.impl.operations.AbstractKeyOperation.getTransport(AbstractKeyOperation.java:40)
> at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:48)
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.put(RemoteCacheImpl.java:237)
> at org.infinispan.client.hotrod.impl.RemoteCacheSupport.put(RemoteCacheSupport.java:79)
> at sample.Main.main(Main.java:16)
> {noformat}
> It happens on both Hot Rod 2 and 1.3 clients.
> It's really hard to reproduce this state and we don't have a consistent way to reproduce it. However when this happens there is always view change happening so it's related to view change.
> Judging from the stack trace, the client receives numOwners=0 or numSegments=0 topology from the server.
> Also we are unable to find to recover this situation. Rebooting random nodes don't help and keep getting this exceptions on client side.
> Until we can find the root cause, I think it's better to add a guard to avoid this kind invalid topology stored in the server side and propagated to the clients.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (ISPN-5208) Avoid invalid topology
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-5208?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant reassigned ISPN-5208:
-------------------------------------
Assignee: Galder Zamarreño
> Avoid invalid topology
> ----------------------
>
> Key: ISPN-5208
> URL: https://issues.jboss.org/browse/ISPN-5208
> Project: Infinispan
> Issue Type: Enhancement
> Components: Server
> Reporter: Takayoshi Kimura
> Assignee: Galder Zamarreño
> Labels: jdg641
>
> We've seen some invalid topology propagated to client and it causes ArrayIndexOutOfBoundsException:
> {noformat}
> Caused by: java.lang.ArrayIndexOutOfBoundsException: 0
> at org.infinispan.client.hotrod.impl.transport.tcp.RoundRobinBalancingStrategy.getServerByIndex(RoundRobinBalancingStrategy.java:68) [infinispan-client-hotrod-6.1.0.Final-redhat-4.jar:6.1.0.Final-redhat-4]
> at org.infinispan.client.hotrod.impl.transport.tcp.RoundRobinBalancingStrategy.nextServer(RoundRobinBalancingStrategy.java:44) [infinispan-client-hotrod-6.1.0.Final-redhat-4.jar:6.1.0.Final-redhat-4]
> at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory.nextServer(TcpTransportFactory.java:220) [infinispan-client-hotrod-6.1.0.Final-redhat-4.jar:6.1.0.Final-redhat-4]
> at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory.getTransport(TcpTransportFactory.java:194) [infinispan-client-hotrod-6.1.0.Final-redhat-4.jar:6.1.0.Final-redhat-4]
> at org.infinispan.client.hotrod.impl.operations.FaultTolerantPingOperation.getTransport(FaultTolerantPingOperation.java:27) [infinispan-client-hotrod-6.1.0.Final-redhat-4.jar:6.1.0.Final-redhat-4]
> at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:48) [infinispan-client-hotrod-6.1.0.Final-redhat-4.jar:6.1.0.Final-redhat-4]
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.ping(RemoteCacheImpl.java:535) [infinispan-client-hotrod-6.1.0.Final-redhat-4.jar:6.1.0.Final-redhat-4]
> at org.infinispan.client.hotrod.RemoteCacheManager.ping(RemoteCacheManager.java:635) [infinispan-client-hotrod-6.1.0.Final-redhat-4.jar:6.1.0.Final-redhat-4]
> at org.infinispan.client.hotrod.RemoteCacheManager.createRemoteCache(RemoteCacheManager.java:616) [infinispan-client-hotrod-6.1.0.Final-redhat-4.jar:6.1.0.Final-redhat-4]
> at org.infinispan.client.hotrod.RemoteCacheManager.getCache(RemoteCacheManager.java:527) [infinispan-client-hotrod-6.1.0.Final-redhat-4.jar:6.1.0.Final-redhat-4]
> at org.infinispan.client.hotrod.RemoteCacheManager.getCache(RemoteCacheManager.java:523) [infinispan-client-hotrod-6.1.0.Final-redhat-4.jar:6.1.0.Final-redhat-4]
> {noformat}
> {noformat}
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 0
> at org.infinispan.client.hotrod.impl.consistenthash.SegmentConsistentHash.getServer(SegmentConsistentHash.java:33)
> at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory.getTransport(TcpTransportFactory.java:204)
> at org.infinispan.client.hotrod.impl.operations.AbstractKeyOperation.getTransport(AbstractKeyOperation.java:40)
> at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:48)
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.put(RemoteCacheImpl.java:237)
> at org.infinispan.client.hotrod.impl.RemoteCacheSupport.put(RemoteCacheSupport.java:79)
> at sample.Main.main(Main.java:16)
> {noformat}
> It happens on both Hot Rod 2 and 1.3 clients.
> It's really hard to reproduce this state and we don't have a consistent way to reproduce it. However when this happens there is always view change happening so it's related to view change.
> Judging from the stack trace, the client receives numOwners=0 or numSegments=0 topology from the server.
> Also we are unable to find to recover this situation. Rebooting random nodes don't help and keep getting this exceptions on client side.
> Until we can find the root cause, I think it's better to add a guard to avoid this kind invalid topology stored in the server side and propagated to the clients.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month