October 2017 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-8457) Use jboss-logging in ProtobufMetadataManagerInterceptor

by Adrian Nistor (JIRA)

Adrian Nistor created ISPN-8457: ----------------------------------- Summary: Use jboss-logging in ProtobufMetadataManagerInterceptor Key: ISPN-8457 URL: https://issues.jboss.org/browse/ISPN-8457 Project: Infinispan Issue Type: Enhancement Reporter: Adrian Nistor Assignee: Adrian Nistor Fix For: 9.2.0.Beta1 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8457) Use jboss-logging in ProtobufMetadataManagerInterceptor

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-8457?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-8457: -------------------------------- Status: Open (was: New) > Use jboss-logging in ProtobufMetadataManagerInterceptor > ------------------------------------------------------- > > Key: ISPN-8457 > URL: https://issues.jboss.org/browse/ISPN-8457 > Project: Infinispan > Issue Type: Enhancement > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 9.2.0.Beta1 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 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: 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)

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

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

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

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

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

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

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

8 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues October 2017