April 2017 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-6250) The keys/values in TaskContext.getCache() are serialized in Server Task

by Michał Szynkiewicz (JIRA)

[ https://issues.jboss.org/browse/ISPN-6250?page=com.atlassian.jira.plugin.... ] Michał Szynkiewicz commented on ISPN-6250: ------------------------------------------ Is this issue still there? I didn't have more ideas to pursue on it and then I forgot about it... > The keys/values in TaskContext.getCache() are serialized in Server Task > ----------------------------------------------------------------------- > > Key: ISPN-6250 > URL: https://issues.jboss.org/browse/ISPN-6250 > Project: Infinispan > Issue Type: Bug > Components: Server, Test Suite - Server > Reporter: Anna Manukyan > Assignee: Michał Szynkiewicz > Attachments: LocalServerTaskIT.java, LocalTestServerTask.java > > > While trying to access cache entries in Server task, marshaller is required for unmarshalling them. > The test is running on the https://github.com/infinispan/infinispan/blob/master/server/integration/t... configuration. > Please find the sources attached. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7683) Hot Rod server does not unregister the topology cache on stop

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-7683?page=com.atlassian.jira.plugin.... ] Ryan Emerson resolved ISPN-7683. -------------------------------- Fix Version/s: 9.1.0.Final (was: 9.0.1.Final) Resolution: Done > Hot Rod server does not unregister the topology cache on stop > ------------------------------------------------------------- > > Key: ISPN-7683 > URL: https://issues.jboss.org/browse/ISPN-7683 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 9.0.0.CR3 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 9.1.0.Final > > > The Hot Rod server does not unregister the internal topology cache when stopped. This prevents a restart of the server when the endpoint config is modified at runtime. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7732) StringBasedStoreMultinodeIT.testFetchState fails

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-7732?page=com.atlassian.jira.plugin.... ] Ryan Emerson resolved ISPN-7732. -------------------------------- Resolution: Done > StringBasedStoreMultinodeIT.testFetchState fails > ------------------------------------------------ > > Key: ISPN-7732 > URL: https://issues.jboss.org/browse/ISPN-7732 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Server > Affects Versions: 9.0.0.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 9.1.0.Final, 9.0.1.Final > > > [TestSuiteProgress] Test failed: StringBasedStoreMultinodeIT.testFetchState > 08:29:34.582 [main] ERROR org.infinispan.commons.test.TestSuiteProgress - Test failed: StringBasedStoreMultinodeIT.testFetchState > java.lang.AssertionError: expected:<2> but was:<3> > at org.junit.Assert.fail(Assert.java:88) ~[junit-4.11.jar:?] > at org.junit.Assert.failNotEquals(Assert.java:743) ~[junit-4.11.jar:?] > at org.junit.Assert.assertEquals(Assert.java:118) ~[junit-4.11.jar:?] > at org.junit.Assert.assertEquals(Assert.java:555) ~[junit-4.11.jar:?] > at org.junit.Assert.assertEquals(Assert.java:542) ~[junit-4.11.jar:?] > at org.infinispan.server.test.cs.jdbc.multinode.StringBasedStoreMultinodeIT.testFetchState(StringBasedStoreMultinodeIT.java:57) ~[test-classes/:?] -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7732) StringBasedStoreMultinodeIT.testFetchState fails

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-7732?page=com.atlassian.jira.plugin.... ] Ryan Emerson updated ISPN-7732: ------------------------------- Status: Open (was: New) > StringBasedStoreMultinodeIT.testFetchState fails > ------------------------------------------------ > > Key: ISPN-7732 > URL: https://issues.jboss.org/browse/ISPN-7732 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Server > Affects Versions: 9.0.0.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 9.1.0.Final, 9.0.1.Final > > > [TestSuiteProgress] Test failed: StringBasedStoreMultinodeIT.testFetchState > 08:29:34.582 [main] ERROR org.infinispan.commons.test.TestSuiteProgress - Test failed: StringBasedStoreMultinodeIT.testFetchState > java.lang.AssertionError: expected:<2> but was:<3> > at org.junit.Assert.fail(Assert.java:88) ~[junit-4.11.jar:?] > at org.junit.Assert.failNotEquals(Assert.java:743) ~[junit-4.11.jar:?] > at org.junit.Assert.assertEquals(Assert.java:118) ~[junit-4.11.jar:?] > at org.junit.Assert.assertEquals(Assert.java:555) ~[junit-4.11.jar:?] > at org.junit.Assert.assertEquals(Assert.java:542) ~[junit-4.11.jar:?] > at org.infinispan.server.test.cs.jdbc.multinode.StringBasedStoreMultinodeIT.testFetchState(StringBasedStoreMultinodeIT.java:57) ~[test-classes/:?] -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7732) StringBasedStoreMultinodeIT.testFetchState fails

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-7732?page=com.atlassian.jira.plugin.... ] Ryan Emerson updated ISPN-7732: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/5093 > StringBasedStoreMultinodeIT.testFetchState fails > ------------------------------------------------ > > Key: ISPN-7732 > URL: https://issues.jboss.org/browse/ISPN-7732 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Server > Affects Versions: 9.0.0.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 9.1.0.Final, 9.0.1.Final > > > [TestSuiteProgress] Test failed: StringBasedStoreMultinodeIT.testFetchState > 08:29:34.582 [main] ERROR org.infinispan.commons.test.TestSuiteProgress - Test failed: StringBasedStoreMultinodeIT.testFetchState > java.lang.AssertionError: expected:<2> but was:<3> > at org.junit.Assert.fail(Assert.java:88) ~[junit-4.11.jar:?] > at org.junit.Assert.failNotEquals(Assert.java:743) ~[junit-4.11.jar:?] > at org.junit.Assert.assertEquals(Assert.java:118) ~[junit-4.11.jar:?] > at org.junit.Assert.assertEquals(Assert.java:555) ~[junit-4.11.jar:?] > at org.junit.Assert.assertEquals(Assert.java:542) ~[junit-4.11.jar:?] > at org.infinispan.server.test.cs.jdbc.multinode.StringBasedStoreMultinodeIT.testFetchState(StringBasedStoreMultinodeIT.java:57) ~[test-classes/:?] -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7461) Cache is not rebalanced on merge

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-7461?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-7461: ------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 5.2.21.Final Resolution: Done > Cache is not rebalanced on merge > -------------------------------- > > Key: ISPN-7461 > URL: https://issues.jboss.org/browse/ISPN-7461 > Project: Infinispan > Issue Type: Bug > Components: State Transfer > Affects Versions: 5.2.7.Final > Reporter: Dennis Reed > Assignee: Petr Jurak > Fix For: 5.2.21.Final > > > After a cluster split and merge, the consistent hash is not balanced between the members. > For example in a 2-member cluster, after the merge one node will be primary owner of every segment. In In a larger cluster, some nodes will not own any data. > DefaultConsistentHash{numSegments=60, numOwners=2, members=[RehashAfterPartitionMergeTest-NodeB-49100, RehashAfterPartitionMergeTest-NodeA-11552]} -- 0: 0 1, 1: 0 1, 2: 0 1, 3: 0 1, 4: 0 1, 5: 0 1, 6: 0 1, 7: 0 1, 8: 0 1, 9: 0 1, 10: 0 1, 11: 0 1, 12: 0 1, 13: 0 1, 14: 0 1, 15: 0 1, 16: 0 1, 17: 0 1, 18: 0 1, 19: 0 1, 20: 0 1, 21: 0 1, 22: 0 1, 23: 0 1, 24: 0 1, 25: 0 1, 26: 0 1, 27: 0 1, 28: 0 1, 29: 0 1, 30: 0 1, 31: 0 1, 32: 0 1, 33: 0 1, 34: 0 1, 35: 0 1, 36: 0 1, 37: 0 1, 38: 0 1, 39: 0 1, 40: 0 1, 41: 0 1, 42: 0 1, 43: 0 1, 44: 0 1, 45: 0 1, 46: 0 1, 47: 0 1, 48: 0 1, 49: 0 1, 50: 0 1, 51: 0 1, 52: 0 1, 53: 0 1, 54: 0 1, 55: 0 1, 56: 0 1, 57: 0 1, 58: 0 1, 59: 0 1 > This is triggered consistently by the RehashAfterPartitionMergeTest test case, but is not caught because it does not sufficiently check the consistent hash. (it checks RebalancePolicy.isBalanced, which merely makes sure each segment has the correct number of owners, not that it's evenly distributed). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7732) StringBasedStoreMultinodeIT.testFetchState fails

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-7732: ------------------------------------- Summary: StringBasedStoreMultinodeIT.testFetchState fails Key: ISPN-7732 URL: https://issues.jboss.org/browse/ISPN-7732 Project: Infinispan Issue Type: Bug Components: Test Suite - Server Affects Versions: 9.0.0.Final Reporter: Tristan Tarrant Assignee: Tristan Tarrant Fix For: 9.1.0.Final, 9.0.1.Final [TestSuiteProgress] Test failed: StringBasedStoreMultinodeIT.testFetchState 08:29:34.582 [main] ERROR org.infinispan.commons.test.TestSuiteProgress - Test failed: StringBasedStoreMultinodeIT.testFetchState java.lang.AssertionError: expected:<2> but was:<3> at org.junit.Assert.fail(Assert.java:88) ~[junit-4.11.jar:?] at org.junit.Assert.failNotEquals(Assert.java:743) ~[junit-4.11.jar:?] at org.junit.Assert.assertEquals(Assert.java:118) ~[junit-4.11.jar:?] at org.junit.Assert.assertEquals(Assert.java:555) ~[junit-4.11.jar:?] at org.junit.Assert.assertEquals(Assert.java:542) ~[junit-4.11.jar:?] at org.infinispan.server.test.cs.jdbc.multinode.StringBasedStoreMultinodeIT.testFetchState(StringBasedStoreMultinodeIT.java:57) ~[test-classes/:?] -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7461) Cache is not rebalanced on merge

by Petr Jurak (JIRA)

[ https://issues.jboss.org/browse/ISPN-7461?page=com.atlassian.jira.plugin.... ] Petr Jurak updated ISPN-7461: ----------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/5015 > Cache is not rebalanced on merge > -------------------------------- > > Key: ISPN-7461 > URL: https://issues.jboss.org/browse/ISPN-7461 > Project: Infinispan > Issue Type: Bug > Components: State Transfer > Affects Versions: 5.2.7.Final > Reporter: Dennis Reed > Assignee: Petr Jurak > > After a cluster split and merge, the consistent hash is not balanced between the members. > For example in a 2-member cluster, after the merge one node will be primary owner of every segment. In In a larger cluster, some nodes will not own any data. > DefaultConsistentHash{numSegments=60, numOwners=2, members=[RehashAfterPartitionMergeTest-NodeB-49100, RehashAfterPartitionMergeTest-NodeA-11552]} -- 0: 0 1, 1: 0 1, 2: 0 1, 3: 0 1, 4: 0 1, 5: 0 1, 6: 0 1, 7: 0 1, 8: 0 1, 9: 0 1, 10: 0 1, 11: 0 1, 12: 0 1, 13: 0 1, 14: 0 1, 15: 0 1, 16: 0 1, 17: 0 1, 18: 0 1, 19: 0 1, 20: 0 1, 21: 0 1, 22: 0 1, 23: 0 1, 24: 0 1, 25: 0 1, 26: 0 1, 27: 0 1, 28: 0 1, 29: 0 1, 30: 0 1, 31: 0 1, 32: 0 1, 33: 0 1, 34: 0 1, 35: 0 1, 36: 0 1, 37: 0 1, 38: 0 1, 39: 0 1, 40: 0 1, 41: 0 1, 42: 0 1, 43: 0 1, 44: 0 1, 45: 0 1, 46: 0 1, 47: 0 1, 48: 0 1, 49: 0 1, 50: 0 1, 51: 0 1, 52: 0 1, 53: 0 1, 54: 0 1, 55: 0 1, 56: 0 1, 57: 0 1, 58: 0 1, 59: 0 1 > This is triggered consistently by the RehashAfterPartitionMergeTest test case, but is not caught because it does not sufficiently check the consistent hash. (it checks RebalancePolicy.isBalanced, which merely makes sure each segment has the correct number of owners, not that it's evenly distributed). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7461) Cache is not rebalanced on merge

by Petr Jurak (JIRA)

[ https://issues.jboss.org/browse/ISPN-7461?page=com.atlassian.jira.plugin.... ] Petr Jurak updated ISPN-7461: ----------------------------- Status: Open (was: New) > Cache is not rebalanced on merge > -------------------------------- > > Key: ISPN-7461 > URL: https://issues.jboss.org/browse/ISPN-7461 > Project: Infinispan > Issue Type: Bug > Components: State Transfer > Affects Versions: 5.2.7.Final > Reporter: Dennis Reed > Assignee: Petr Jurak > > After a cluster split and merge, the consistent hash is not balanced between the members. > For example in a 2-member cluster, after the merge one node will be primary owner of every segment. In In a larger cluster, some nodes will not own any data. > DefaultConsistentHash{numSegments=60, numOwners=2, members=[RehashAfterPartitionMergeTest-NodeB-49100, RehashAfterPartitionMergeTest-NodeA-11552]} -- 0: 0 1, 1: 0 1, 2: 0 1, 3: 0 1, 4: 0 1, 5: 0 1, 6: 0 1, 7: 0 1, 8: 0 1, 9: 0 1, 10: 0 1, 11: 0 1, 12: 0 1, 13: 0 1, 14: 0 1, 15: 0 1, 16: 0 1, 17: 0 1, 18: 0 1, 19: 0 1, 20: 0 1, 21: 0 1, 22: 0 1, 23: 0 1, 24: 0 1, 25: 0 1, 26: 0 1, 27: 0 1, 28: 0 1, 29: 0 1, 30: 0 1, 31: 0 1, 32: 0 1, 33: 0 1, 34: 0 1, 35: 0 1, 36: 0 1, 37: 0 1, 38: 0 1, 39: 0 1, 40: 0 1, 41: 0 1, 42: 0 1, 43: 0 1, 44: 0 1, 45: 0 1, 46: 0 1, 47: 0 1, 48: 0 1, 49: 0 1, 50: 0 1, 51: 0 1, 52: 0 1, 53: 0 1, 54: 0 1, 55: 0 1, 56: 0 1, 57: 0 1, 58: 0 1, 59: 0 1 > This is triggered consistently by the RehashAfterPartitionMergeTest test case, but is not caught because it does not sufficiently check the consistent hash. (it checks RebalancePolicy.isBalanced, which merely makes sure each segment has the correct number of owners, not that it's evenly distributed). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7461) Cache is not rebalanced on merge

by Petr Jurak (JIRA)

[ https://issues.jboss.org/browse/ISPN-7461?page=com.atlassian.jira.plugin.... ] Work on ISPN-7461 started by Petr Jurak. ---------------------------------------- > Cache is not rebalanced on merge > -------------------------------- > > Key: ISPN-7461 > URL: https://issues.jboss.org/browse/ISPN-7461 > Project: Infinispan > Issue Type: Bug > Components: State Transfer > Affects Versions: 5.2.7.Final > Reporter: Dennis Reed > Assignee: Petr Jurak > > After a cluster split and merge, the consistent hash is not balanced between the members. > For example in a 2-member cluster, after the merge one node will be primary owner of every segment. In In a larger cluster, some nodes will not own any data. > DefaultConsistentHash{numSegments=60, numOwners=2, members=[RehashAfterPartitionMergeTest-NodeB-49100, RehashAfterPartitionMergeTest-NodeA-11552]} -- 0: 0 1, 1: 0 1, 2: 0 1, 3: 0 1, 4: 0 1, 5: 0 1, 6: 0 1, 7: 0 1, 8: 0 1, 9: 0 1, 10: 0 1, 11: 0 1, 12: 0 1, 13: 0 1, 14: 0 1, 15: 0 1, 16: 0 1, 17: 0 1, 18: 0 1, 19: 0 1, 20: 0 1, 21: 0 1, 22: 0 1, 23: 0 1, 24: 0 1, 25: 0 1, 26: 0 1, 27: 0 1, 28: 0 1, 29: 0 1, 30: 0 1, 31: 0 1, 32: 0 1, 33: 0 1, 34: 0 1, 35: 0 1, 36: 0 1, 37: 0 1, 38: 0 1, 39: 0 1, 40: 0 1, 41: 0 1, 42: 0 1, 43: 0 1, 44: 0 1, 45: 0 1, 46: 0 1, 47: 0 1, 48: 0 1, 49: 0 1, 50: 0 1, 51: 0 1, 52: 0 1, 53: 0 1, 54: 0 1, 55: 0 1, 56: 0 1, 57: 0 1, 58: 0 1, 59: 0 1 > This is triggered consistently by the RehashAfterPartitionMergeTest test case, but is not caught because it does not sufficiently check the consistent hash. (it checks RebalancePolicy.isBalanced, which merely makes sure each segment has the correct number of owners, not that it's evenly distributed). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 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 April 2017