March 2017 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-7557) List Hibernate OGM among the possible APIs and Integrations

by Sanne Grinovero (JIRA)

Sanne Grinovero created ISPN-7557: ------------------------------------- Summary: List Hibernate OGM among the possible APIs and Integrations Key: ISPN-7557 URL: https://issues.jboss.org/browse/ISPN-7557 Project: Infinispan Issue Type: Task Components: Documentation-Servers, Integration Reporter: Sanne Grinovero Assignee: Sanne Grinovero -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7556) Decoder2x.readOptionalParams should not call markReaderIndex()

by Dan Berindei (JIRA)

Dan Berindei created ISPN-7556: ---------------------------------- Summary: Decoder2x.readOptionalParams should not call markReaderIndex() Key: ISPN-7556 URL: https://issues.jboss.org/browse/ISPN-7556 Project: Infinispan Issue Type: Bug Components: Server Affects Versions: 9.0.0.CR2 Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 9.0.0.Final {{Decoder2x.readOptionalParams()}} calls {{buffer.markReaderIndex()}} after reading each parameter, but doesn't save the parameters anywhere. That means if the buffer doesn't contain all the parameters, the decode pass ends unsuccessfully, and the next decode pass doesn't see the parameters read by the previous pass. Higher-level methods like {{Decoder2x.readMaybeNamedFactory()}} also call {{readOptionalParams()}} without saving their own state first, meaning their state can be lost as well. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6040) FunctionalNonTxBackupOwnerBecomingPrimaryOwnerTest.testPrimaryOwnerChangingDuringRemove random failures

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-6040?page=com.atlassian.jira.plugin.... ] Pedro Ruivo commented on ISPN-6040: ----------------------------------- I think Radim's changes to the entry wrapping interceptor may fixed this test. I enabled again in https://github.com/infinispan/infinispan/pull/4934 > FunctionalNonTxBackupOwnerBecomingPrimaryOwnerTest.testPrimaryOwnerChangingDuringRemove random failures > ------------------------------------------------------------------------------------------------------- > > Key: ISPN-6040 > URL: https://issues.jboss.org/browse/ISPN-6040 > Project: Infinispan > Issue Type: Bug > Components: Core, Test Suite - Core > Affects Versions: 8.1.0.Final > Reporter: Dan Berindei > Assignee: Galder Zamarreño > Priority: Blocker > Labels: testsuite_stability > Fix For: 9.0.0.Final > > > Similar to ISPN-6039, the test failure is caused by the state transfer put happening after the test's remove. > In this case, the command types are different, so blocking works correctly. However, when the {{ReadWriteKeyValueCommand}} executes before the state transfer put, it doesn't find any value, and it doesn't commit the entry. This means the key is not added to {{CommitManager}}'s {{tracker}} map, and the state transfer put is allowed to write to it - effectively undoing the remove. > {noformat} > java.lang.AssertionError: expected:<null> but was:<v0> > at org.testng.AssertJUnit.fail(AssertJUnit.java:59) > at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364) > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80) > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:88) > at org.infinispan.distribution.rehash.NonTxBackupOwnerBecomingPrimaryOwnerTest.doTest(NonTxBackupOwnerBecomingPrimaryOwnerTest.java:194) > at org.infinispan.functional.distribution.rehash.FunctionalNonTxBackupOwnerBecomingPrimaryOwnerTest.testPrimaryOwnerChangingDuringRemove(FunctionalNonTxBackupOwnerBecomingPrimaryOwnerTest.java:103) > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6039) NonTxBackupOwnerBecomingPrimaryOwnerTest.testPrimaryOwnerChangingDuringPutOverwrite random failures

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-6039?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-6039: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/4934 > NonTxBackupOwnerBecomingPrimaryOwnerTest.testPrimaryOwnerChangingDuringPutOverwrite random failures > --------------------------------------------------------------------------------------------------- > > Key: ISPN-6039 > URL: https://issues.jboss.org/browse/ISPN-6039 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 8.1.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Blocker > Labels: testsuite_stability > Fix For: 9.0.0.Final > > > The problem is that the state transfer write can happen after we started the regular put, and is blocked by the {{BlockingInterceptor}}. The test then unblocks the state transfer put, but never unblocks the regular put, which eventually times out. > {noformat} > java.util.concurrent.TimeoutException > at java.util.concurrent.FutureTask.get(FutureTask.java:205) > at org.infinispan.distribution.rehash.NonTxBackupOwnerBecomingPrimaryOwnerTest.doTest(NonTxBackupOwnerBecomingPrimaryOwnerTest.java:193) > at org.infinispan.distribution.rehash.NonTxBackupOwnerBecomingPrimaryOwnerTest.testPrimaryOwnerChangingDuringPutOverwrite(NonTxBackupOwnerBecomingPrimaryOwnerTest.java:75) > {noformat} > The test should be more explicit about the state transfer put - ideally it should have 2 cases, one with the state transfer put happening before the regular put, and one after. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6039) NonTxBackupOwnerBecomingPrimaryOwnerTest.testPrimaryOwnerChangingDuringPutOverwrite random failures

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-6039?page=com.atlassian.jira.plugin.... ] Pedro Ruivo reassigned ISPN-6039: --------------------------------- Assignee: Pedro Ruivo (was: Dan Berindei) > NonTxBackupOwnerBecomingPrimaryOwnerTest.testPrimaryOwnerChangingDuringPutOverwrite random failures > --------------------------------------------------------------------------------------------------- > > Key: ISPN-6039 > URL: https://issues.jboss.org/browse/ISPN-6039 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 8.1.0.Final > Reporter: Dan Berindei > Assignee: Pedro Ruivo > Priority: Blocker > Labels: testsuite_stability > Fix For: 9.0.0.Final > > > The problem is that the state transfer write can happen after we started the regular put, and is blocked by the {{BlockingInterceptor}}. The test then unblocks the state transfer put, but never unblocks the regular put, which eventually times out. > {noformat} > java.util.concurrent.TimeoutException > at java.util.concurrent.FutureTask.get(FutureTask.java:205) > at org.infinispan.distribution.rehash.NonTxBackupOwnerBecomingPrimaryOwnerTest.doTest(NonTxBackupOwnerBecomingPrimaryOwnerTest.java:193) > at org.infinispan.distribution.rehash.NonTxBackupOwnerBecomingPrimaryOwnerTest.testPrimaryOwnerChangingDuringPutOverwrite(NonTxBackupOwnerBecomingPrimaryOwnerTest.java:75) > {noformat} > The test should be more explicit about the state transfer put - ideally it should have 2 cases, one with the state transfer put happening before the regular put, and one after. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5021) Nodes that finish the rebalance later can see outdated values

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/ISPN-5021?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated ISPN-5021: --------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/4862 (was: https://github.com/infinispan/infinispan/pull/4827, https://github.com/infinispan/infinispan/pull/4862) > Nodes that finish the rebalance later can see outdated values > ------------------------------------------------------------- > > Key: ISPN-5021 > URL: https://issues.jboss.org/browse/ISPN-5021 > Project: Infinispan > Issue Type: Bug > Components: Core, State Transfer > Affects Versions: 7.0.2.Final > Reporter: Dan Berindei > Assignee: Pedro Ruivo > Priority: Critical > Labels: consistency, testsuite_stability > Fix For: 9.0.0.Final > > > Copied from [ISPN-4444|https://issues.jboss.org/browse/ISPN-4444?focusedCommentId=1302...] > If the CH_UPDATE command is delayed on the old owner, the new owners might update the key without the old owner knowing, and a locality check on the old owner won't help. > I remember one thing that struck me when reading the Raft algorithm was that they install configuration changes symmetrically, in 3 phases. We might need to do the same for our rebalance: > 1. T0: read_ch=old, write_ch=old > 2. start a rebalance > 3. T1: read_ch=old, write_ch=old+new > 4. new owners have all the data > 5. T2: read_ch=new, write_ch=old+new > 6. remove old cache entries and ignore further writes > 7. T3: read_ch=new, write_ch=new -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5021) Nodes that finish the rebalance later can see outdated values

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/ISPN-5021?page=com.atlassian.jira.plugin.... ] Paul Ferraro commented on ISPN-5021: ------------------------------------ FYI - we are running into this bug on EAP 7.1. Please backport this fix to 8.2.x. > Nodes that finish the rebalance later can see outdated values > ------------------------------------------------------------- > > Key: ISPN-5021 > URL: https://issues.jboss.org/browse/ISPN-5021 > Project: Infinispan > Issue Type: Bug > Components: Core, State Transfer > Affects Versions: 7.0.2.Final > Reporter: Dan Berindei > Assignee: Pedro Ruivo > Priority: Critical > Labels: consistency, testsuite_stability > Fix For: 9.0.0.Final > > > Copied from [ISPN-4444|https://issues.jboss.org/browse/ISPN-4444?focusedCommentId=1302...] > If the CH_UPDATE command is delayed on the old owner, the new owners might update the key without the old owner knowing, and a locality check on the old owner won't help. > I remember one thing that struck me when reading the Raft algorithm was that they install configuration changes symmetrically, in 3 phases. We might need to do the same for our rebalance: > 1. T0: read_ch=old, write_ch=old > 2. start a rebalance > 3. T1: read_ch=old, write_ch=old+new > 4. new owners have all the data > 5. T2: read_ch=new, write_ch=old+new > 6. remove old cache entries and ignore further writes > 7. T3: read_ch=new, write_ch=new -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7555) Originator node in launch new task dialog is not displayed correctly in standalone mode

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-7555?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic reassigned ISPN-7555: ----------------------------------------- Assignee: Vladimir Blagojevic > Originator node in launch new task dialog is not displayed correctly in standalone mode > --------------------------------------------------------------------------------------- > > Key: ISPN-7555 > URL: https://issues.jboss.org/browse/ISPN-7555 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management > Affects Versions: 9.0.0.CR2 > Reporter: Roman Macor > Assignee: Vladimir Blagojevic > Priority: Minor > > - start server in standalone clustered mode - bin/standalone.sh -c clustered.xml > - click on cache container - Tasks execution tab -> Launch new task -> click on Originator node > result: the node is displayed like this: terminator:terminator, if we set the server name, e.g. server-one, it's displayed like this: server-one:server-one ("terminator" is hostname from /etc/hostname) > expected result: host-name:server-name (same as in domain mode) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7555) Originator node in launch new task dialog is not displayed correctly in standalone mode

by Roman Macor (JIRA)

Roman Macor created ISPN-7555: --------------------------------- Summary: Originator node in launch new task dialog is not displayed correctly in standalone mode Key: ISPN-7555 URL: https://issues.jboss.org/browse/ISPN-7555 Project: Infinispan Issue Type: Bug Components: JMX, reporting and management Affects Versions: 9.0.0.CR2 Reporter: Roman Macor Priority: Minor - start server in standalone clustered mode - bin/standalone.sh -c clustered.xml - click on cache container - Tasks execution tab -> Launch new task -> click on Originator node result: the node is displayed like this: terminator:terminator, if we set the server name, e.g. server-one, it's displayed like this: server-one:server-one ("terminator" is hostname from /etc/hostname) expected result: host-name:server-name (same as in domain mode) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPRK-14) Push down predicate support for SQL

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPRK-14?page=com.atlassian.jira.plugin.s... ] Gustavo Fernandes updated ISPRK-14: ----------------------------------- Status: Open (was: New) > Push down predicate support for SQL > ----------------------------------- > > Key: ISPRK-14 > URL: https://issues.jboss.org/browse/ISPRK-14 > Project: Infinispan Spark > Issue Type: Enhancement > Components: SQL > Affects Versions: 0.1 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Fix For: 0.5 > > > Currently, using Spark SQL will cause iteration of each Infinispan partition, an optimization would be to use the so called "push down" of predicates, so that parts of the SQL would be translated to a Infinispan query and data would be filtered at the source. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 11 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2017