[Red Hat JIRA] (ISPN-12669) Tests failing due to relying on published images
by Ryan Emerson (Jira)
[ https://issues.redhat.com/browse/ISPN-12669?page=com.atlassian.jira.plugi... ]
Ryan Emerson updated ISPN-12669:
--------------------------------
Affects Version/s: 12.0.0.Final
> Tests failing due to relying on published images
> ------------------------------------------------
>
> Key: ISPN-12669
> URL: https://issues.redhat.com/browse/ISPN-12669
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 12.0.0.Final
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
>
> The following tests are pulling the server image from remote instead of utilising the local server build to create a container for testing. This results in the testsuite failing when we transition to a new major/minor that does not have a published image yet. We should update the relevant poms to ensure that the local server dist is always used.
> {code:java}
> org.infinispan.server.test.junit5.InfinispanServerExtensionContainerTest.(?)
> test.org.infinispan.spring.starter.remote.actuator.RemoteCacheMetricBinderTest.(?)
> {code}
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 3 months
[Red Hat JIRA] (ISPN-12669) Tests failing due to relying on published images
by Ryan Emerson (Jira)
[ https://issues.redhat.com/browse/ISPN-12669?page=com.atlassian.jira.plugi... ]
Ryan Emerson updated ISPN-12669:
--------------------------------
Fix Version/s: 12.1.0.Final
12.0.1.Final
> Tests failing due to relying on published images
> ------------------------------------------------
>
> Key: ISPN-12669
> URL: https://issues.redhat.com/browse/ISPN-12669
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 12.0.0.Final
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
> Fix For: 12.1.0.Final, 12.0.1.Final
>
>
> The following tests are pulling the server image from remote instead of utilising the local server build to create a container for testing. This results in the testsuite failing when we transition to a new major/minor that does not have a published image yet. We should update the relevant poms to ensure that the local server dist is always used.
> {code:java}
> org.infinispan.server.test.junit5.InfinispanServerExtensionContainerTest.(?)
> test.org.infinispan.spring.starter.remote.actuator.RemoteCacheMetricBinderTest.(?)
> {code}
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 3 months
[Red Hat JIRA] (ISPN-12669) Tests failing due to relying on published images
by Ryan Emerson (Jira)
[ https://issues.redhat.com/browse/ISPN-12669?page=com.atlassian.jira.plugi... ]
Ryan Emerson updated ISPN-12669:
--------------------------------
Status: Open (was: New)
> Tests failing due to relying on published images
> ------------------------------------------------
>
> Key: ISPN-12669
> URL: https://issues.redhat.com/browse/ISPN-12669
> Project: Infinispan
> Issue Type: Bug
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
>
> The following tests are pulling the server image from remote instead of utilising the local server build to create a container for testing. This results in the testsuite failing when we transition to a new major/minor that does not have a published image yet. We should update the relevant poms to ensure that the local server dist is always used.
> {code:java}
> org.infinispan.server.test.junit5.InfinispanServerExtensionContainerTest.(?)
> test.org.infinispan.spring.starter.remote.actuator.RemoteCacheMetricBinderTest.(?)
> {code}
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 3 months
[Red Hat JIRA] (ISPN-12652) Cluster is broken after one node is down
by Dmitry Kruglikov (Jira)
[ https://issues.redhat.com/browse/ISPN-12652?page=com.atlassian.jira.plugi... ]
Dmitry Kruglikov updated ISPN-12652:
------------------------------------
Description:
We have 3 nodes in cluster: app1, app2 and app3. App1 was shut down not gracefully because of some hardware issue. After that app2 and app3 started to fail with something like
{{{{ERROR [org.infinispan.interceptors.impl.InvocationContextInterceptor] (timeout-thread--p23-t1) ISPN000136: Error executing command RemoveCommand on Cache 'fs.war', writing keys [SessionCreationMetaDataKey(PGARVVdjGKfifzrVfyd7HAllbrwaRG7wLhKha1On)]: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 422657 from app1}}}}
{{ \{{ at org.infinispan@9.4.14.Final//org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167)}}}}
{{ \{{ at org.infinispan@9.4.14.Final//org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87)}}}}
{{ \{{ at org.infinispan@9.4.14.Final//org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22)}}}}
{{ \{{ at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)}}}}
{{ \{{ at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)}}}}
{{ \{{ at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)}}}}
{{ \{{ at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)}}}}
{{ \{{ at java.base/java.lang.Thread.run(Thread.java:834)}}}}
So these 2 nodes (app2 and app3) could not serve user requests anymore until app1 recovered. My question is... Is it ok? Should not Infinispan identify that one of nodes is down, remove it from cluster and notify app2 and app3 about it? I know that there is something like VERIFY_SUSPECT but it didn't happen.
was:
We have 3 nodes in cluster: app1, app2 and app3. App1 was shut down not gracefully because of some hardware issue. After that app2 and app3 started to fail with something like
{{ERROR [org.infinispan.interceptors.impl.InvocationContextInterceptor] (timeout-thread--p23-t1) ISPN000136: Error executing command RemoveCommand on Cache 'fs.war', writing keys [SessionCreationMetaDataKey(PGARVVdjGKfifzrVfyd7HAllbrwaRG7wLhKha1On)]: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 422657 from app1}}
{{ at org.infinispan@9.4.14.Final//org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167)}}
{{ at org.infinispan@9.4.14.Final//org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87)}}
{{ at org.infinispan@9.4.14.Final//org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22)}}
{{ at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)}}
{{ at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)}}
{{ at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)}}
{{ at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)}}
{{ at java.base/java.lang.Thread.run(Thread.java:834)}}
So these 2 nodes (app2 and app3) could not serve user requests anymore until app1 recovered. My question is... Is it ok? Should not Infinispan identify that one of nodes is down, remove it from cluster and notify app2 and app3 about it? I know that there is something like VERIFY_SUSPECT but it didn't happen.
> Cluster is broken after one node is down
> ----------------------------------------
>
> Key: ISPN-12652
> URL: https://issues.redhat.com/browse/ISPN-12652
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 9.4.14.Final
> Reporter: Dmitry Kruglikov
> Priority: Blocker
>
> We have 3 nodes in cluster: app1, app2 and app3. App1 was shut down not gracefully because of some hardware issue. After that app2 and app3 started to fail with something like
>
> {{{{ERROR [org.infinispan.interceptors.impl.InvocationContextInterceptor] (timeout-thread--p23-t1) ISPN000136: Error executing command RemoveCommand on Cache 'fs.war', writing keys [SessionCreationMetaDataKey(PGARVVdjGKfifzrVfyd7HAllbrwaRG7wLhKha1On)]: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 422657 from app1}}}}
> {{ \{{ at org.infinispan@9.4.14.Final//org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167)}}}}
> {{ \{{ at org.infinispan@9.4.14.Final//org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87)}}}}
> {{ \{{ at org.infinispan@9.4.14.Final//org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22)}}}}
> {{ \{{ at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)}}}}
> {{ \{{ at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)}}}}
> {{ \{{ at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)}}}}
> {{ \{{ at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)}}}}
> {{ \{{ at java.base/java.lang.Thread.run(Thread.java:834)}}}}
>
> So these 2 nodes (app2 and app3) could not serve user requests anymore until app1 recovered. My question is... Is it ok? Should not Infinispan identify that one of nodes is down, remove it from cluster and notify app2 and app3 about it? I know that there is something like VERIFY_SUSPECT but it didn't happen.
>
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 3 months
[Red Hat JIRA] (ISPN-12652) Cluster is broken after one node is down
by Dmitry Kruglikov (Jira)
[ https://issues.redhat.com/browse/ISPN-12652?page=com.atlassian.jira.plugi... ]
Dmitry Kruglikov updated ISPN-12652:
------------------------------------
Description:
We have 3 nodes in cluster: app1, app2 and app3. App1 was shut down not gracefully because of some hardware issue. After that app2 and app3 started to fail with something like
{{ERROR [org.infinispan.interceptors.impl.InvocationContextInterceptor] (timeout-thread--p23-t1) ISPN000136: Error executing command RemoveCommand on Cache 'fs.war', writing keys [SessionCreationMetaDataKey(PGARVVdjGKfifzrVfyd7HAllbrwaRG7wLhKha1On)]: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 422657 from app1}}
{{ at org.infinispan@9.4.14.Final//org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167)}}
{{ at org.infinispan@9.4.14.Final//org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87)}}
{{ at org.infinispan@9.4.14.Final//org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22)}}
{{ at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)}}
{{ at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)}}
{{ at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)}}
{{ at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)}}
{{ at java.base/java.lang.Thread.run(Thread.java:834)}}
So these 2 nodes (app2 and app3) could not serve user requests anymore until app1 recovered. My question is... Is it ok? Should not Infinispan identify that one of nodes is down, remove it from cluster and notify app2 and app3 about it? I know that there is something like VERIFY_SUSPECT but it didn't happen.
was:
We have 3 nodes in cluster: app1, app2 and app3. App1 was shut down not gracefully because of some hardware issue. After that app2 and app3 started to fail with something like
ERROR [org.infinispan.interceptors.impl.InvocationContextInterceptor] (timeout-thread--p23-t1) ISPN000136: Error executing command RemoveCommand on Cache 'fs.war', writing keys [SessionCreationMetaDataKey(PGARVVdjGKfifzrVfyd7HAllbrwaRG7wLhKha1On)]: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 422657 from app1
at org.infinispan@9.4.14.Final//org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167)
at org.infinispan@9.4.14.Final//org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87)
at org.infinispan@9.4.14.Final//org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
So these 2 nodes (app2 and app3) could not serve user requests anymore until app1 recovered. My question is... Is it ok? Should not Infinispan identify that one of nodes is down, remove it from cluster and notify app2 and app3 about it? I know that there is something like VERIFY_SUSPECT but it didn't happen.
> Cluster is broken after one node is down
> ----------------------------------------
>
> Key: ISPN-12652
> URL: https://issues.redhat.com/browse/ISPN-12652
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 9.4.14.Final
> Reporter: Dmitry Kruglikov
> Priority: Blocker
>
> We have 3 nodes in cluster: app1, app2 and app3. App1 was shut down not gracefully because of some hardware issue. After that app2 and app3 started to fail with something like
>
> {{ERROR [org.infinispan.interceptors.impl.InvocationContextInterceptor] (timeout-thread--p23-t1) ISPN000136: Error executing command RemoveCommand on Cache 'fs.war', writing keys [SessionCreationMetaDataKey(PGARVVdjGKfifzrVfyd7HAllbrwaRG7wLhKha1On)]: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 422657 from app1}}
> {{ at org.infinispan@9.4.14.Final//org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167)}}
> {{ at org.infinispan@9.4.14.Final//org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87)}}
> {{ at org.infinispan@9.4.14.Final//org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22)}}
> {{ at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)}}
> {{ at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)}}
> {{ at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)}}
> {{ at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)}}
> {{ at java.base/java.lang.Thread.run(Thread.java:834)}}
>
> So these 2 nodes (app2 and app3) could not serve user requests anymore until app1 recovered. My question is... Is it ok? Should not Infinispan identify that one of nodes is down, remove it from cluster and notify app2 and app3 about it? I know that there is something like VERIFY_SUSPECT but it didn't happen.
>
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 3 months
[Red Hat JIRA] (ISPN-12666) ReplicationIndexTest random failures
by Gustavo Fernandes (Jira)
[ https://issues.redhat.com/browse/ISPN-12666?page=com.atlassian.jira.plugi... ]
Gustavo Fernandes updated ISPN-12666:
-------------------------------------
Affects Version/s: (was: 11.0.9.Final)
> ReplicationIndexTest random failures
> ------------------------------------
>
> Key: ISPN-12666
> URL: https://issues.redhat.com/browse/ISPN-12666
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 12.0.0.Final
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Priority: Major
>
> {noformat}
> java.lang.AssertionError: expected:<2> but was:<0>
> at org.infinispan.client.hotrod.query.ReplicationIndexTest.assertIndexed(ReplicationIndexTest.java:149)
> at org.infinispan.client.hotrod.query.ReplicationIndexTest.testIndexingDuringStateTransfer(ReplicationIndexTest.java:145)
> at org.infinispan.commons.test.TestNGLongTestsHook.run(TestNGLongTestsHook.java:24)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> ... Removed 23 stack frames
> {noformat}
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 3 months
[Red Hat JIRA] (ISPN-12666) ReplicationIndexTest random failures
by Gustavo Fernandes (Jira)
[ https://issues.redhat.com/browse/ISPN-12666?page=com.atlassian.jira.plugi... ]
Gustavo Fernandes updated ISPN-12666:
-------------------------------------
Affects Version/s: 12.0.0.Final
11.0.9.Final
> ReplicationIndexTest random failures
> ------------------------------------
>
> Key: ISPN-12666
> URL: https://issues.redhat.com/browse/ISPN-12666
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 11.0.9.Final, 12.0.0.Final
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Priority: Major
>
> {noformat}
> java.lang.AssertionError: expected:<2> but was:<0>
> at org.infinispan.client.hotrod.query.ReplicationIndexTest.assertIndexed(ReplicationIndexTest.java:149)
> at org.infinispan.client.hotrod.query.ReplicationIndexTest.testIndexingDuringStateTransfer(ReplicationIndexTest.java:145)
> at org.infinispan.commons.test.TestNGLongTestsHook.run(TestNGLongTestsHook.java:24)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> ... Removed 23 stack frames
> {noformat}
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 3 months
[Red Hat JIRA] (ISPN-12666) ReplicationIndexTest random failures
by Gustavo Fernandes (Jira)
[ https://issues.redhat.com/browse/ISPN-12666?page=com.atlassian.jira.plugi... ]
Gustavo Fernandes updated ISPN-12666:
-------------------------------------
Git Pull Request: https://github.com/infinispan/infinispan/pull/9021
Status: Pull Request Sent (was: Coding In Progress)
> ReplicationIndexTest random failures
> ------------------------------------
>
> Key: ISPN-12666
> URL: https://issues.redhat.com/browse/ISPN-12666
> Project: Infinispan
> Issue Type: Bug
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Priority: Major
>
> {noformat}
> java.lang.AssertionError: expected:<2> but was:<0>
> at org.infinispan.client.hotrod.query.ReplicationIndexTest.assertIndexed(ReplicationIndexTest.java:149)
> at org.infinispan.client.hotrod.query.ReplicationIndexTest.testIndexingDuringStateTransfer(ReplicationIndexTest.java:145)
> at org.infinispan.commons.test.TestNGLongTestsHook.run(TestNGLongTestsHook.java:24)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> ... Removed 23 stack frames
> {noformat}
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 3 months
[Red Hat JIRA] (ISPN-12670) IllegalArgumentException when doing Rolling Upgrades on transactional caches
by Wolf-Dieter Fink (Jira)
Wolf-Dieter Fink created ISPN-12670:
---------------------------------------
Summary: IllegalArgumentException when doing Rolling Upgrades on transactional caches
Key: ISPN-12670
URL: https://issues.redhat.com/browse/ISPN-12670
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 11.0.9.Final
Reporter: Wolf-Dieter Fink
Assignee: Gustavo Fernandes
{noformat}
Caused by: java.lang.IllegalArgumentException: Cannot create a transactional context without a valid Transaction instance.
at org.infinispan.context.impl.TransactionalInvocationContextFactory.createInvocationContext(TransactionalInvocationContextFactory.java:63)
[...]
at org.infinispan.cache.impl.DecoratedCache.putIfAbsent(DecoratedCache.java:688)
at org.infinispan.cache.impl.AbstractDelegatingAdvancedCache.putIfAbsent(AbstractDelegatingAdvancedCache.java:328)
at org.infinispan.cache.impl.EncoderCache.putIfAbsent(EncoderCache.java:450)
at org.infinispan.persistence.remote.upgrade.MigrationTask.lambda$migrateEntriesWithMetadata$0(MigrationTask.java:128)
at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1771)
{noformat}
The migration component that obtains data from the remote cache does not use transactions to write to the destination cache, and since it runs on a separate thread, it cannot see any ongoing transaction and thus fail to write to the cache.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 3 months