January 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-2574) Segment transfer not restarted if the owner fails

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2574?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-2574: ----------------------------------------------- Michal Linhard <mlinhard(a)redhat.com> made a comment on [bug 882162|https://bugzilla.redhat.com/show_bug.cgi?id=882162] This is fine in ER6 but this functionality has changed and might not be fine in ER8.... > Segment transfer not restarted if the owner fails > ------------------------------------------------- > > Key: ISPN-2574 > URL: https://issues.jboss.org/browse/ISPN-2574 > Project: Infinispan > Issue Type: Bug > Components: State transfer > Affects Versions: 5.2.0.Beta4 > Reporter: Radim Vansa > Assignee: Adrian Nistor > Priority: Critical > Fix For: 5.2.0.CR1 > > > Imagine this situation in distributed cache with 3 owners: > 1) The segment X is owned by nodes A, B, C > 2) Node B fails -> CH_UPDATE and then REBALANCE_START are broadcasted > 3) Node D starts transfer of segment X from C > 4) Node C fails -> another CH_UPDATE is broadcasted > 5) D handes the CH_UPDATE and removes the transfer of segment X from C, but does not start another transfer from A > The {{addedSegments}} does not contain the restarted transfer, because all transfers from write consistent hash are removed from it in the beginning - the segment is considered received here although the transfer is still in progress. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2574) Segment transfer not restarted if the owner fails

by Michal Linhard (JIRA)

[ https://issues.jboss.org/browse/ISPN-2574?page=com.atlassian.jira.plugin.... ] Michal Linhard commented on ISPN-2574: -------------------------------------- On current master this test crashes on this line: {code} final Cache<Object, Object> c2 = cache(2); {code} but when catch the exception (by replacing it with): {code} Cache<Object, Object> aCache = null; while (aCache == null) { try { aCache = cache(2); } catch (Exception e) { log.error("Problem obtaining cache: ", e); } } final Cache<Object, Object> c2 = aCache; {code} i still can't see the StateRequestCommand being sent from C to A (after B is killed) > Segment transfer not restarted if the owner fails > ------------------------------------------------- > > Key: ISPN-2574 > URL: https://issues.jboss.org/browse/ISPN-2574 > Project: Infinispan > Issue Type: Bug > Components: State transfer > Affects Versions: 5.2.0.Beta4 > Reporter: Radim Vansa > Assignee: Adrian Nistor > Priority: Critical > Fix For: 5.2.0.CR1 > > > Imagine this situation in distributed cache with 3 owners: > 1) The segment X is owned by nodes A, B, C > 2) Node B fails -> CH_UPDATE and then REBALANCE_START are broadcasted > 3) Node D starts transfer of segment X from C > 4) Node C fails -> another CH_UPDATE is broadcasted > 5) D handes the CH_UPDATE and removes the transfer of segment X from C, but does not start another transfer from A > The {{addedSegments}} does not contain the restarted transfer, because all transfers from write consistent hash are removed from it in the beginning - the segment is considered received here although the transfer is still in progress. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2574) Segment transfer not restarted if the owner fails

by Michal Linhard (JIRA)

[ https://issues.jboss.org/browse/ISPN-2574?page=com.atlassian.jira.plugin.... ] Michal Linhard reopened ISPN-2574: ---------------------------------- Adrian please check out my test case: https://github.com/mlinhard/infinispan/commit/8681c35c95aeba128ae28a1c2ab... it doesn't work for current master. the test scenario is a more simple one: config: distribution, num owners 2 1. create cluster {A,B}, fill 1000 entries 2. join C 3. when B is about to send StateResponseCommand to C, fail B, never send the command 4. C should restart the state transfer and ask the same segments from A 5. cluster {A, C} will form with all segments properly backed up on both A and C Beta4 didn't restart the state transfer which meant some entries weren't properly transfered to C Beta6 did this alright current master again fails to restart the state transfer from A > Segment transfer not restarted if the owner fails > ------------------------------------------------- > > Key: ISPN-2574 > URL: https://issues.jboss.org/browse/ISPN-2574 > Project: Infinispan > Issue Type: Bug > Components: State transfer > Affects Versions: 5.2.0.Beta4 > Reporter: Radim Vansa > Assignee: Adrian Nistor > Priority: Critical > Fix For: 5.2.0.CR1 > > > Imagine this situation in distributed cache with 3 owners: > 1) The segment X is owned by nodes A, B, C > 2) Node B fails -> CH_UPDATE and then REBALANCE_START are broadcasted > 3) Node D starts transfer of segment X from C > 4) Node C fails -> another CH_UPDATE is broadcasted > 5) D handes the CH_UPDATE and removes the transfer of segment X from C, but does not start another transfer from A > The {{addedSegments}} does not contain the restarted transfer, because all transfers from write consistent hash are removed from it in the beginning - the segment is considered received here although the transfer is still in progress. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2632) Uneven request balancing after node crash

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2632?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-2632: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 886549|https://bugzilla.redhat.com/show_bug.cgi?id=886549] from ASSIGNED to MODIFIED > Uneven request balancing after node crash > ----------------------------------------- > > Key: ISPN-2632 > URL: https://issues.jboss.org/browse/ISPN-2632 > Project: Infinispan > Issue Type: Bug > Components: Remote protocols > Affects Versions: 5.2.0.CR1 > Reporter: Michal Linhard > Assignee: Galder Zamarreño > Priority: Blocker > Fix For: 5.2.0.CR2, 5.2.0.Final > > > This is a new manifestation of ISPN-1995, but in this case this happens after killing only one node: the hot rod requests aren't very well balanced. > these runs still manifest also ISPN-2550 and it may be cause of this bug. > The uneven balancing of requests can be seen here: > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EDG6/view/EDG-REPOR... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2517) org.infinispan.statetransfer.StateTransferFileCacheLoaderFunctionalTest.testConcurrentStateTransfer fails randomly

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-2517?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-2517: ---------------------------------- Fix Version/s: 5.2.0.Final > org.infinispan.statetransfer.StateTransferFileCacheLoaderFunctionalTest.testConcurrentStateTransfer fails randomly > ------------------------------------------------------------------------------------------------------------------ > > Key: ISPN-2517 > URL: https://issues.jboss.org/browse/ISPN-2517 > Project: Infinispan > Issue Type: Bug > Components: Test Suite > Affects Versions: 5.2.0.Beta5 > Reporter: Anna Manukyan > Assignee: Mircea Markus > Labels: testsuite_stability > Fix For: 5.2.0.Final > > > The failure takes place in case of JDG test suire run on env: RHEL6_x86, IBM JDK6 > You can find the log here: > http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/edg-60-ispn-testsuite... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2671) clear() does not purge synchronously

by Thomas Fromm (JIRA)

[ https://issues.jboss.org/browse/ISPN-2671?page=com.atlassian.jira.plugin.... ] Thomas Fromm commented on ISPN-2671: ------------------------------------ Sorry missing details, I thought I find time to create test for that. However, here is short description: I've wrapped the Cache API to include for size(), keySet() and so on also the entries present in cache store or remote nodes. So if cache store is present I access the cache store and read the keys present there. When remove(..) single entries and access after the FileCacheStore with loadKeys, the removed keys are not included (expected behaviour wehn purge sync is active). When accessing after clean() the FileCacheStore, the keys are still present. My workaround is to remove(..) inside clean() all single entries one by one. > clear() does not purge synchronously > ------------------------------------ > > Key: ISPN-2671 > URL: https://issues.jboss.org/browse/ISPN-2671 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 5.2.0.Beta6 > Reporter: Thomas Fromm > Assignee: Mircea Markus > Fix For: 5.3.0.Final > > > When using a FileCacheStore with enables sync. purge and call clear(), the entries inside the store are not purged syncronously. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2318) Reimplement a Topology-Aware Consistent Hash

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2318?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-2318: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 868832|https://bugzilla.redhat.com/show_bug.cgi?id=868832] from ON_DEV to ASSIGNED > Reimplement a Topology-Aware Consistent Hash > -------------------------------------------- > > Key: ISPN-2318 > URL: https://issues.jboss.org/browse/ISPN-2318 > Project: Infinispan > Issue Type: Task > Components: Core API, Distributed Cache > Affects Versions: 5.2.0.Alpha3 > Reporter: Erik Salter > Assignee: Dan Berindei > Priority: Blocker > Fix For: 5.2.0.Beta3 > > > Even with the advent of x-site replication, the TACH is useful to stripe key ownership across machines and/or racks for resiliency. This feature should be refactored from the 5.1 impl. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2566) TopologyAwareConsistentHashFactory rebalance doesn't redistribute data properly

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2566?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-2566: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 868832|https://bugzilla.redhat.com/show_bug.cgi?id=868832] from ON_DEV to ASSIGNED > TopologyAwareConsistentHashFactory rebalance doesn't redistribute data properly > ------------------------------------------------------------------------------- > > Key: ISPN-2566 > URL: https://issues.jboss.org/browse/ISPN-2566 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 5.2.0.Beta4 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Fix For: 5.2.0.Beta6, 5.2.0.Final > > > Say we have a topology-aware cache with numOwners = 2 and two nodes: A(machine=m1) and B(machine=m1). When node C(machine=m2) joins, it should own every key, either as a primary or as a backup owner. This doesn't happen, node C owns just as many segments as nodes A and B. > Example: > {noformat} > 19:21:17,295 TRACE [org.infinispan.topology.ClusterTopologyManagerImpl] (undefined) Updating cache topology topology for rebalance: > CacheTopology{id=3, currentCH=DefaultConsistentHash{numSegments=80, numOwners=2, > members=[node0/default(primary), node1/default(primary)], > owners={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: 1 0, 41: 1 0, 42: 1 0, 43: 1 0, 44: 1 0, 45: 1 0, 46: 1 0, 47: 1 0, > 48: 1 0, 49: 1 0, 50: 1 0, 51: 1 0, 52: 1 0, 53: 1 0, 54: 1 0, 55: 1 0, > 56: 1 0, 57: 1 0, 58: 1 0, 59: 1 0, 60: 1 0, 61: 1 0, 62: 1 0, 63: 1 0, > 64: 1 0, 65: 1 0, 66: 1 0, 67: 1 0, 68: 1 0, 69: 1 0, 70: 1 0, 71: 1 0, > 72: 1 0, 73: 1 0, 74: 1 0, 75: 1 0, 76: 1 0, 77: 1 0, 78: 1 0, 79: 1 0}, > pendingCH=DefaultConsistentHash{numSegments=80, numOwners=2, > members=[node0/default(primary), node1/default(primary), node2/default(secondary)], > owners={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: 2 0, 28: 2 0, 29: 2 0, 30: 2 0, 31: 2 0, > 32: 2 0, 33: 2 0, 34: 2 0, 35: 2 0, 36: 2 0, 37: 2 0, 38: 2 0, 39: 2 0, > 40: 1 0, 41: 1 0, 42: 1 0, 43: 1 0, 44: 1 0, 45: 1 0, 46: 1 0, 47: 1 0, > 48: 1 0, 49: 1 0, 50: 1 0, 51: 1 0, 52: 1 0, 53: 1 0, 54: 1 0, 55: 1 0, > 56: 1 0, 57: 1 0, 58: 1 0, 59: 1 0, 60: 1 0, 61: 1 0, 62: 1 0, 63: 1 0, > 64: 1 0, 65: 1 0, 66: 1 0, 67: 2 1, 68: 2 1, 69: 2 1, 70: 2 1, 71: 2 1, > 72: 2 1, 73: 2 1, 74: 2 1, 75: 2 1, 76: 2 1, 77: 2 1, 78: 2 1, 79: 2 1}} > {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2703) The "machine" attribute of server hinting does not work

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2703?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-2703: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 868832|https://bugzilla.redhat.com/show_bug.cgi?id=868832] from ON_DEV to ASSIGNED > The "machine" attribute of server hinting does not work > ------------------------------------------------------- > > Key: ISPN-2703 > URL: https://issues.jboss.org/browse/ISPN-2703 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.2.0.Beta6 > Reporter: Martin Gencur > Assignee: Dan Berindei > Fix For: 5.2.0.CR2, 5.2.0.Final > > Attachments: trace_log_machine_attribute_failing.txt > > > The rack and site attributes already work correctly. I'm creating this one issue just for the remaining "machine" attribute. > Will attach trace logs -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2624) JDG: Storage-only example: HotRodDecoder: NSEE: key not found: node1/clustered

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2624?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-2624: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 875151|https://bugzilla.redhat.com/show_bug.cgi?id=875151] from ASSIGNED to MODIFIED > JDG: Storage-only example: HotRodDecoder: NSEE: key not found: node1/clustered > ------------------------------------------------------------------------------ > > Key: ISPN-2624 > URL: https://issues.jboss.org/browse/ISPN-2624 > Project: Infinispan > Issue Type: Bug > Components: Remote protocols > Reporter: Tomas Sykora > Assignee: Galder Zamarreño > Fix For: 5.2.0.CR1 > > Attachments: standalone-ha.xml, standalone-storage-only.xml, storageOnlyTraceMainNode.txt, storageOnlyTraceStorageOnlyNode.txt > > > This is issue to distinguish from https://issues.jboss.org/browse/ISPN-2550. > For logs and more info see related BZ: https://bugzilla.redhat.com/show_bug.cgi?id=875151 > This issue was found during running JDG functional test suite for configuration examples provided with JDG. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 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 January 2013