October 2017 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-8376) Add DMR cluster counters management

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-8376?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic updated ISPN-8376: -------------------------------------- Status: Open (was: New) > Add DMR cluster counters management > ----------------------------------- > > Key: ISPN-8376 > URL: https://issues.jboss.org/browse/ISPN-8376 > Project: Infinispan > Issue Type: Enhancement > Components: Clustered Counter, JMX, reporting and management > Reporter: Tristan Tarrant > Assignee: Vladimir Blagojevic > > We need DMR ops/attributes to manage counters. At the very least: > - list existing counters > - inspect a counter's value > - set/reset a counter value -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8376) Add DMR cluster counters management

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-8376?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic updated ISPN-8376: -------------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/5554 > Add DMR cluster counters management > ----------------------------------- > > Key: ISPN-8376 > URL: https://issues.jboss.org/browse/ISPN-8376 > Project: Infinispan > Issue Type: Enhancement > Components: Clustered Counter, JMX, reporting and management > Reporter: Tristan Tarrant > Assignee: Vladimir Blagojevic > > We need DMR ops/attributes to manage counters. At the very least: > - list existing counters > - inspect a counter's value > - set/reset a counter value -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8456) Regression in rest reads performance on 24. October

by Jakub Markos (JIRA)

Jakub Markos created ISPN-8456: ---------------------------------- Summary: Regression in rest reads performance on 24. October Key: ISPN-8456 URL: https://issues.jboss.org/browse/ISPN-8456 Project: Infinispan Issue Type: Bug Reporter: Jakub Markos Assignee: Gustavo Fernandes -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 5 months

1
0
0 / 0

[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)

6 years, 5 months

1
0
0 / 0

[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)

6 years, 5 months

1
0
0 / 0

[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)

6 years, 5 months

1
0
0 / 0

[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)

6 years, 5 months

1
0
0 / 0

[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)

6 years, 5 months

1
0
0 / 0

[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)

6 years, 5 months

1
0
0 / 0

[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)

6 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues October 2017