[JBoss JIRA] (ISPN-8455) PushTransferTest.testNodeJoin random failure
by Radim Vansa (JIRA)
Radim Vansa created ISPN-8455:
---------------------------------
Summary: PushTransferTest.testNodeJoin random failure
Key: ISPN-8455
URL: https://issues.jboss.org/browse/ISPN-8455
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 9.2.0.Alpha2
Reporter: Radim Vansa
Assignee: Radim Vansa
http://ci.infinispan.org/job/Infinispan/job/PR-5549/1/testReport/junit/or...
{code}
java.lang.AssertionError: Key MagicKey#key0{E01/1F11243A/3@PushTransferTest-NodeA-3984} has incorrect number of copies expected:<2> but was:<3>
at org.infinispan.scattered.statetransfer.PushTransferTest.testNodeJoin(PushTransferTest.java:93)
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)
{code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 2 months
[JBoss JIRA] (ISPN-7806) QueryInterceptor should not load entries from DC but context
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-7806?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-7806:
------------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> QueryInterceptor should not load entries from DC but context
> ------------------------------------------------------------
>
> Key: ISPN-7806
> URL: https://issues.jboss.org/browse/ISPN-7806
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying
> Affects Versions: 9.0.0.Final
> Reporter: Radim Vansa
> Assignee: Gustavo Fernandes
>
> Currently in {{visitPrepareCommand}} the query interceptor is loading data directly from data container. That's wrong - if the entry is passivated/evicted, the previous value is incorrect.
> As the data is not loaded (from DC/persistence) at current QI position, we should move QueryInterceptor after EntryWrappingInterceptor, CacheLoaderInterceptor -and xDistributionInterceptor (which may load the data from remote node),- and load the previous entry from context instead. The same approach should be taken for non-tx command, rather than relying on their return value.
> **EDIT**: we should not move it below xDistributionInterceptor because on backup owner (which may be write-owner but not a read-owner) we would retrieve the updated value (affected by the current command), not the previous one.
> There will still be issues if the command has SKIP_CACHE_LOAD flag: I suggest warning message if it doesn't have SKIP_INDEXING flag as well.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 2 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:
-------------------------------
Git Pull Request: https://github.com/infinispan/infinispan/pull/5551, https://github.com/infinispan/infinispan/pull/5553 (was: https://github.com/infinispan/infinispan/pull/5551)
> 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)
7 years, 2 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:
-------------------------------
Status: Open (was: New)
> 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)
7 years, 2 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:
-------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/5551
> 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)
7 years, 2 months
[JBoss JIRA] (ISPN-8454) Off Heap can crash when using JMH test
by William Burns (JIRA)
William Burns created ISPN-8454:
-----------------------------------
Summary: Off Heap can crash when using JMH test
Key: ISPN-8454
URL: https://issues.jboss.org/browse/ISPN-8454
Project: Infinispan
Issue Type: Bug
Components: Off Heap
Reporter: William Burns
Assignee: William Burns
Fix For: 9.2.0.Beta1
I have a jmh branch from our benchmarks that always can crash off heap when not using tracing. For whatever reason I can't seem to reliably produce it with tracing. This JIRA is to handle this issue.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 2 months
[JBoss JIRA] (ISPN-8453) Commit should fail if cache is in degraded mode
by Dan Berindei (JIRA)
Dan Berindei created ISPN-8453:
----------------------------------
Summary: Commit should fail if cache is in degraded mode
Key: ISPN-8453
URL: https://issues.jboss.org/browse/ISPN-8453
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 9.2.0.Alpha2, 9.1.2.Final, 8.2.8.Final, 8.1.9.Final
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 9.2.0.Beta1
When the originator receives a {{CacheNotFoundResponse}} and the cache is in degraded mode, the transaction is marked as partially completed, but the commit completes successfully.
I believe that is not correct, because the originator could crash after the commit but before the merge, and in that case the transaction will not be applied on all the owners. The transaction manager will ignore any commit exception in {{NON_XA}}/{{useSynchronization}} mode, but at least in {{FULL_XA}}/{{NON_DURABLE_XA}} mode we can signal to the user that the transaction may be lost.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 2 months