[JBoss JIRA] (ISPN-6857) OutdatedTopologyException in clustered invalidation cache because StateTransferInterceptor not in the chain
by Marek Posolda (JIRA)
Marek Posolda created ISPN-6857:
-----------------------------------
Summary: OutdatedTopologyException in clustered invalidation cache because StateTransferInterceptor not in the chain
Key: ISPN-6857
URL: https://issues.jboss.org/browse/ISPN-6857
Project: Infinispan
Issue Type: Bug
Affects Versions: 8.1.0.Final
Reporter: Marek Posolda
I have the following setup:
- 2 nodes in cluster with mode INVALIDATION_SYNC. No-transaction cache.
- Node1 is started
- Called "cache.remove" on some key on node1. At the same time, node2 is starting, which is causing topology change.
- The "cache.remove" call on node1 is throwing OutdatedTopologyException.
I found the cause is that StateTransferInterceptor is not added in InterceptorChain during INVALIDATION mode. It's just available during REPLICATION or DISTRIBUTED modes - https://github.com/infinispan/infinispan/blob/master/core/src/main/java/o...
Indeed when I manually added StateTransferInterceptor to my invalidation cache:
{code}
invalidationConfigBuilder.customInterceptors()
.addInterceptor()
.before(NonTransactionalLockingInterceptor.class)
.interceptorClass(StateTransferInterceptor.class);
{code}
I can see that issue is gone as OutdatedTopologyException is catched and command is retried with new topology.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (ISPN-6856) Testsuite: replace inheritance with @Factory
by Radim Vansa (JIRA)
Radim Vansa created ISPN-6856:
---------------------------------
Summary: Testsuite: replace inheritance with @Factory
Key: ISPN-6856
URL: https://issues.jboss.org/browse/ISPN-6856
Project: Infinispan
Issue Type: Enhancement
Components: Test Suite - Core
Reporter: Radim Vansa
Assignee: Radim Vansa
Testsuite often uses inheritance with overloaded methods to specify test parameters. A better approach is using TestNG @Factory to create multiple instances of the test with different parameters.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (ISPN-6855) [8.1.x] CacheManagerTest.testExceptionOnCacheManagerStop fails
by Jiří Bílek (JIRA)
Jiří Bílek created ISPN-6855:
--------------------------------
Summary: [8.1.x] CacheManagerTest.testExceptionOnCacheManagerStop fails
Key: ISPN-6855
URL: https://issues.jboss.org/browse/ISPN-6855
Project: Infinispan
Issue Type: Bug
Components: Test Suite - Core
Affects Versions: 8.1.4.Final
Reporter: Jiří Bílek
Assignee: Dan Berindei
Fix For: 8.1.5.Final
The ISPN-6099 backport for 8.1.x included some changes to {{CacheManagerTest}}, but those require additional changes in {{DefaultCacheManager}} startup that were not backported.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (ISPN-6854) org.infinispan.manager.CacheManagerTest.testCacheManagerRestartReusingConfigurations fails randomly
by Jiří Bílek (JIRA)
Jiří Bílek created ISPN-6854:
--------------------------------
Summary: org.infinispan.manager.CacheManagerTest.testCacheManagerRestartReusingConfigurations fails randomly
Key: ISPN-6854
URL: https://issues.jboss.org/browse/ISPN-6854
Project: Infinispan
Issue Type: Bug
Components: Test Suite - Core
Affects Versions: 5.2.10.Final, 7.0.0.Final
Reporter: Jiří Bílek
org.infinispan.manager.CacheManagerTest.testCacheManagerRestartReusingConfigurations fails, so far, I've seen it on Windows (seems random there) and on RHEL7 (seems consistent - every JDK).
Error Message
{code}
Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.InterruptedException on object of type StateTransferManagerImpl
Stacktrace
org.infinispan.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.InterruptedException on object of type StateTransferManagerImpl
at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:205)
at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:886)
at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:657)
at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:646)
at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:549)
at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:217)
at org.infinispan.CacheImpl.start(CacheImpl.java:582)
at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:686)
at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:649)
at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:545)
at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:518)
at org.infinispan.manager.CacheManagerTest$4$1.call(CacheManagerTest.java:374)
at org.infinispan.test.TestingUtil.withCacheManager(TestingUtil.java:1237)
at org.infinispan.manager.CacheManagerTest$4.call(CacheManagerTest.java:370)
at org.infinispan.test.TestingUtil.withCacheManagers(TestingUtil.java:1252)
at org.infinispan.manager.CacheManagerTest.testCacheManagerRestartReusingConfigurations(CacheManagerTest.java:356)
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)
Caused by: org.infinispan.CacheException: Initial state transfer timed out for cache ___defaultcache on CacheManagerTest-NodeA-49570
at org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete(StateTransferManagerImpl.java:216)
at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:203)
... 36 more
... Removed 19 stack frames
{code}
Unrelated to https://issues.jboss.org/browse/ISPN-3963.
Jenkins job link:
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-manu-infinisp...
Downstream BZ was: https://bugzilla.redhat.com/show_bug.cgi?id=1102058
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (ISPN-6853) ClientAsymmetricClusterTest.testAsymmetricCluster random failures
by Jiří Bílek (JIRA)
Jiří Bílek created ISPN-6853:
--------------------------------
Summary: ClientAsymmetricClusterTest.testAsymmetricCluster random failures
Key: ISPN-6853
URL: https://issues.jboss.org/browse/ISPN-6853
Project: Infinispan
Issue Type: Bug
Components: Remote Protocols, Test Suite - Server
Reporter: Jiří Bílek
Assignee: Galder Zamarreño
Priority: Minor
Fix For: 9.0.0.Alpha4
{{ClientAsymmetricClusterTest.testAsymmetricCluster}} is failing since the ISPN-5981 fix, which enabled {{pingOnStartup}} by default, and now returns {{null}} if the first server to be pinged doesn't have the cache defined.
{noformat}
10:23:07,862 WARN (testng-ClientAsymmetricClusterTest:) [Codec21] ISPN004005: Error received from the server: org.infinispan.server.hotrod.CacheNotFoundException: Cache with name 'asymmetricCache' not found amongst the configured caches
10:23:07,862 ERROR (testng-ClientAsymmetricClusterTest:) [UnitTestTestNGListener] Test testAsymmetricCluster(org.infinispan.client.hotrod.ClientAsymmetricClusterTest) failed.
java.lang.NullPointerException
at org.infinispan.client.hotrod.ClientAsymmetricClusterTest.testAsymmetricCluster(ClientAsymmetricClusterTest.java:38) ~[test-classes/:?]
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (ISPN-6852) ClientAsymmetricClusterTest.testAsymmetricCluster random failures
by Jiří Bílek (JIRA)
[ https://issues.jboss.org/browse/ISPN-6852?page=com.atlassian.jira.plugin.... ]
Jiří Bílek deleted ISPN-6852:
-----------------------------
> ClientAsymmetricClusterTest.testAsymmetricCluster random failures
> -----------------------------------------------------------------
>
> Key: ISPN-6852
> URL: https://issues.jboss.org/browse/ISPN-6852
> Project: Infinispan
> Issue Type: Bug
> Reporter: Jiří Bílek
> Assignee: Galder Zamarreño
> Priority: Minor
> Labels: testsuite_stability
>
> {{ClientAsymmetricClusterTest.testAsymmetricCluster}} is failing since the ISPN-5981 fix, which enabled {{pingOnStartup}} by default, and now returns {{null}} if the first server to be pinged doesn't have the cache defined.
> {noformat}
> 10:23:07,862 WARN (testng-ClientAsymmetricClusterTest:) [Codec21] ISPN004005: Error received from the server: org.infinispan.server.hotrod.CacheNotFoundException: Cache with name 'asymmetricCache' not found amongst the configured caches
> 10:23:07,862 ERROR (testng-ClientAsymmetricClusterTest:) [UnitTestTestNGListener] Test testAsymmetricCluster(org.infinispan.client.hotrod.ClientAsymmetricClusterTest) failed.
> java.lang.NullPointerException
> at org.infinispan.client.hotrod.ClientAsymmetricClusterTest.testAsymmetricCluster(ClientAsymmetricClusterTest.java:38) ~[test-classes/:?]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (ISPN-6852) ClientAsymmetricClusterTest.testAsymmetricCluster random failures
by Jiří Bílek (JIRA)
Jiří Bílek created ISPN-6852:
--------------------------------
Summary: ClientAsymmetricClusterTest.testAsymmetricCluster random failures
Key: ISPN-6852
URL: https://issues.jboss.org/browse/ISPN-6852
Project: Infinispan
Issue Type: Bug
Components: Remote Protocols, Test Suite - Server
Reporter: Jiří Bílek
Assignee: Galder Zamarreño
Priority: Minor
Fix For: 9.0.0.Alpha4
{{ClientAsymmetricClusterTest.testAsymmetricCluster}} is failing since the ISPN-5981 fix, which enabled {{pingOnStartup}} by default, and now returns {{null}} if the first server to be pinged doesn't have the cache defined.
{noformat}
10:23:07,862 WARN (testng-ClientAsymmetricClusterTest:) [Codec21] ISPN004005: Error received from the server: org.infinispan.server.hotrod.CacheNotFoundException: Cache with name 'asymmetricCache' not found amongst the configured caches
10:23:07,862 ERROR (testng-ClientAsymmetricClusterTest:) [UnitTestTestNGListener] Test testAsymmetricCluster(org.infinispan.client.hotrod.ClientAsymmetricClusterTest) failed.
java.lang.NullPointerException
at org.infinispan.client.hotrod.ClientAsymmetricClusterTest.testAsymmetricCluster(ClientAsymmetricClusterTest.java:38) ~[test-classes/:?]
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (ISPN-6840) Consider using Dogen
by Sebastian Łaskawiec (JIRA)
[ https://issues.jboss.org/browse/ISPN-6840?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec edited comment on ISPN-6840 at 7/13/16 7:37 AM:
--------------------------------------------------------------------
Since this issue is related to the upstream project as well as JDG, please restrict your comments to Red Hat Employees!
h2. Building JDG images
JBoss Data Grid OpenShift images are built using tool called [Dogen|https://github.com/jboss-dockerfiles/dogen]. It is responsible for generating Dockerfiles based on YAML specification and a bunch of scripts. For JDG there are two repositories - [the first one|https://gitlab.mw.lab.eng.bos.redhat.com/cloudenablement/jboss-datagr...] is a standalone image with no OSE enhancements whereas [the second one|https://gitlab.mw.lab.eng.bos.redhat.com/cloudenablement/jboss-docker...] contains full OSE support. The images are created using [generate.sh script|https://gitlab.mw.lab.eng.bos.redhat.com/cloudenablement/jboss-doc...].
h2. [JDG 7.1 Roadmap|https://docs.google.com/spreadsheets/d/1wS6g5x-CohhV3n3rFeh7ANAYC...]
# Client/Server mode with OSE
# Library mode with OSE
# Deploying the same image on prem
# Multicast within the same OSE project
# Adding nodes dynamically
# Autoscaling
# Graceful shutdown
# Rolling updates
h2. [Infinispan 9 Roadmap|https://docs.google.com/document/d/1uxe4V0OgHen4Ki-JHPdeKVARo5tPF...]
# JGroups discovery
# SNI support
# Using HTTP/2 upgrade for HotRod protocol
# Multi-tenancy
# Configuration management
# Rolling updates
# Autoscaling
# Health and readiness monitoring using REST
h2. Things Infinispan can reuse from JDG (in terms of OpenShift integration)
# KUBE_PING integration. However in the upstream (as well as in JDG 7.1) will also need to support library mode. This means that KUBE_PING needs to be present at least in Infinispan [Uber Jar|https://github.com/infinispan/infinispan/tree/master/all/embedded].
# Liveness and Readiness probe. However we would like to expose more functionality over HTTP. This means that we will need to abandon bash script approach and embrace newly created REST endpoints. See [this JIRA for details|https://issues.jboss.org/browse/ISPN-6679].
# (Optional/not decided yet) Jolokia for collecting metrics, however both Kubernetes and OpenShift collect metrics differently (see comments in [this JIRA|https://issues.jboss.org/browse/ISPN-6489]). Since we will need a unified approach, we probably have to develop some adapters or use some common format (maybe Prometheus?)
h2. Additional arguments for using Dogen approach and porting product bits into the upstream
* Similar code base between Project and Product. Less bugs, less overall maintenance.
* Some of the things will be available out of the box (like Jolokia)
h2. Additional arguments against using Dogen approach and sticking with pure Dockerfile as we do now
* Much easier to consume by the community (easier to read, less complicated, no Dogen knowledge required)
* Almost all features will be implemented the other way around in the community (and possibly should be backported to the product later)
was (Author: sebastian.laskawiec):
Since this issue is related to the upstream project as well as JDG, please restrict your comments to Red Hat Employees!
h3. Building JDG images
JBoss Data Grid OpenShift images are built using tool called [Dogen|https://github.com/jboss-dockerfiles/dogen]. It is responsible for generating Dockerfiles based on YAML specification and a bunch of scripts. For JDG there are two repositories used - [the first one|https://gitlab.mw.lab.eng.bos.redhat.com/cloudenablement/jboss-datagr...] is a standalone image with no OSE enhancements whereas [the second one|https://gitlab.mw.lab.eng.bos.redhat.com/cloudenablement/jboss-docker...] contains full OSE support. The images are created using [generate.sh script|https://gitlab.mw.lab.eng.bos.redhat.com/cloudenablement/jboss-doc...].
h3. [JDG 7.1 Roadmap|https://docs.google.com/spreadsheets/d/1wS6g5x-CohhV3n3rFeh7ANAYC...]
# Client/Server mode with OSE
# Library mode with OSE
# Deploying the same image on prem
# Multicast within the same OSE project
# Adding nodes dynamically
# Autoscaling
# Graceful shutdown
# Rolling updates
h3. [Infinispan 9 Roadmap|https://docs.google.com/document/d/1uxe4V0OgHen4Ki-JHPdeKVARo5tPF...]
# JGroups discovery
# SNI support
# Using HTTP/2 upgrade for HotRod protocol
# Multi-tenancy
# Configuration management
# Rolling updates
# Autoscaling
# Health and readiness monitoring using REST
h3. Things Infinispan can reuse from JDG (in terms of OpenShift integration)
# KUBE_PING integration. However in the upstream (as well as in JDG 7.1) we also need to support library mode. This means that KUBE_PING needs to be present in at least in Infinispan [Uber Jar|https://github.com/infinispan/infinispan/tree/master/all/embedded].
# Liveness and Readiness probe. However we would like to expose more functionality over HTTP. This means that we will need to abandon bash script approach for this and embrace newly created REST endpoints. See [this JIRA for details|https://issues.jboss.org/browse/ISPN-6679].
# (Optional/not decided yet) Jolokia for collecting metrics, however both Kubernetes and OpenShift do this differently (see comments in [this JIRA|https://issues.jboss.org/browse/ISPN-6489]). Since we will need a unified approach, we probably have to develop some adapters or use some common format (maybe Prometheus?)
h3. Additional arguments for using Dogen approach and porting product bits into the upstream
* Similar code base between Project and Product. Less bugs, less overall maintenance.
* Some of the things will be available out of the box (like Jolokia)
h3. Additional arguments against using Dogen approach (sticking with pure Dockerfile as we do now)
* Much easier to consume by the community (easier to read, less complicated, no Dogen knowledge required)
* Almost all features will be implemented the other way around in the community (and possibly should be backported to the product later)
> Consider using Dogen
> --------------------
>
> Key: ISPN-6840
> URL: https://issues.jboss.org/browse/ISPN-6840
> Project: Infinispan
> Issue Type: Sub-task
> Components: Cloud Integrations
> Reporter: Sebastian Łaskawiec
> Assignee: Sebastian Łaskawiec
>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months