November 2014 - infinispan-issues

[JBoss JIRA] (ISPN-4949) Split brain: inconsistent data after merge

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4949?page=com.atlassian.jira.plugin.... ] Dan Berindei reassigned ISPN-4949: ---------------------------------- Assignee: Dan Berindei > Split brain: inconsistent data after merge > ------------------------------------------ > > Key: ISPN-4949 > URL: https://issues.jboss.org/browse/ISPN-4949 > Project: Infinispan > Issue Type: Bug > Components: State Transfer > Affects Versions: 7.0.0.Final > Reporter: Radim Vansa > Assignee: Dan Berindei > Priority: Critical > > 1) cluster A, B, C, D splits into 2 parts: > A, B (coord A) finds this out immediately and enters degraded mode with CH [A, B, C, D] > C, D (coord D) first detects that B is lost, gets view A, C, D and starts rebalance with CH [A, C, D]. Segment X is primary owned by C (it had backup on B but this got lost) > 2) D detects that A was lost as well, therefore enters degraded mode with CH [A, C, D] > 3) C inserts entry into X: all owners (only C) is present, therefore the modification is allowed > 4) cluster is merged and coordinator finds out that the max stable topology has CH [A, B, C, D] (it is the older of the two partitions' topologies, got from A, B) - logs 'No active or unavailable partitions, so all the partitions must be in degraded mode' (yes, all partitions are in degraded mode, but write has happened in the meantime) > 5) The old CH is broadcast in newest topology, no rebalance happens > 6) Inconsistency: read in X may miss the update -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3982) TransactionTable leaks memory when JTS is activated

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3982?page=com.atlassian.jira.plugin.... ] Work on ISPN-3982 started by Pedro Ruivo. ----------------------------------------- > TransactionTable leaks memory when JTS is activated > --------------------------------------------------- > > Key: ISPN-3982 > URL: https://issues.jboss.org/browse/ISPN-3982 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 5.2.7.Final > Reporter: Andrey Smirnov > Assignee: Pedro Ruivo > Fix For: 5.2.11.Final > > Attachments: 0001-ISPN-3982-fixed.patch.gz > > > JBoss EAP 6.2 uses jbossjts-jacorb as it's JTS implementation. In this component com.arjuna.ats.internal.jta.transaction.jts.TransactionImple class has unstable hashCode behaviour. > This causes mem-leak in TransactionTable when activating JTS. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3982) TransactionTable leaks memory when JTS is activated

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3982?page=com.atlassian.jira.plugin.... ] Pedro Ruivo commented on ISPN-3982: ----------------------------------- hi [~cheezzario]. Can you confirm if this solution works? https://github.com/pruivo/infinispan/compare/ISPN-3982/tx_leak > TransactionTable leaks memory when JTS is activated > --------------------------------------------------- > > Key: ISPN-3982 > URL: https://issues.jboss.org/browse/ISPN-3982 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 5.2.7.Final > Reporter: Andrey Smirnov > Assignee: Pedro Ruivo > Fix For: 5.2.11.Final > > Attachments: 0001-ISPN-3982-fixed.patch.gz > > > JBoss EAP 6.2 uses jbossjts-jacorb as it's JTS implementation. In this component com.arjuna.ats.internal.jta.transaction.jts.TransactionImple class has unstable hashCode behaviour. > This causes mem-leak in TransactionTable when activating JTS. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4890) Entry iterator should throw AvailabilityException in degraded mode

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4890?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4890: ----------------------------------------------- Sebastian Łaskawiec <slaskawi(a)redhat.com> changed the Status of [bug 1161783|https://bugzilla.redhat.com/show_bug.cgi?id=1161783] from POST to MODIFIED > Entry iterator should throw AvailabilityException in degraded mode > ------------------------------------------------------------------ > > Key: ISPN-4890 > URL: https://issues.jboss.org/browse/ISPN-4890 > Project: Infinispan > Issue Type: Bug > Components: Core, Test Suite - Core > Affects Versions: 7.0.0.CR2 > Reporter: Dan Berindei > Assignee: William Burns > Priority: Blocker > Labels: testsuite_stability > Fix For: 7.0.0.Final > > > When the distributed entry iterator gets a suspect exception, it assumes that the CH will be soon updated to remove the leaver, and retries to contact the primary owner of the segment. > But if the cache is in degraded mode, the consistent hash is no longer updated, and the entry iterator enters an infinite loop. > {noformat} > 11:58:35,622 TRACE (testng-DelayedAvailabilityUpdateTest:) [DistributedEntryRetriever] Request to NodeC-51013=[50, 51, 20, 52, 21, 53, 22, 54, 23, 24, 25, 26, 27, 28, 29] for cd886604-960b-431a-81a0-efbb51eed57f was suspect, must resend to a new node! > 11:58:35,622 TRACE (testng-DelayedAvailabilityUpdateTest:) [DistributedEntryRetriever] Request to NodeC-51013=[50, 51, 20, 52, 21, 53, 22, 54, 23, 24, 25, 26, 27, 28, 29] for cd886604-960b-431a-81a0-efbb51eed57f was suspect, must resend to a new node! > 11:58:35,622 TRACE (testng-DelayedAvailabilityUpdateTest:) [DistributedEntryRetriever] Request to NodeC-51013=[50, 51, 20, 52, 21, 53, 22, 54, 23, 24, 25, 26, 27, 28, 29] for cd886604-960b-431a-81a0-efbb51eed57f was suspect, must resend to a new node! > ... > {noformat} > This is visible when running the partition handling tests (e.g. DelayedAvailabilityUpdateTest) with trace logging enabled, as {{TestingUtil.killCaches()}} logs the cache contents at trace level. As an aside, {{TestingUtil.killCaches()}} should probably use {{Flag.CACHE_MODE_LOCAL}} to print only the entries on each node. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4904) PartitionHandlingInterceptor should not do checks when Flag.CACHE_MODE_LOCAL is supplied

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4904?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4904: ----------------------------------------------- Sebastian Łaskawiec <slaskawi(a)redhat.com> changed the Status of [bug 1161783|https://bugzilla.redhat.com/show_bug.cgi?id=1161783] from POST to MODIFIED > PartitionHandlingInterceptor should not do checks when Flag.CACHE_MODE_LOCAL is supplied > ---------------------------------------------------------------------------------------- > > Key: ISPN-4904 > URL: https://issues.jboss.org/browse/ISPN-4904 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.0.0.CR2 > Reporter: William Burns > Assignee: William Burns > Fix For: 7.0.0.Final > > > The PartitionHandlingInterceptor currently checks every key irrespective of flags. Since CACHE_MODE_LOCAL flag doesn't involve other nodes we should ignore these checks as the user must know what they are doing. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4985) Allow JCache TCK to be run exclusively with the main jar

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4985?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4985: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Allow JCache TCK to be run exclusively with the main jar > -------------------------------------------------------- > > Key: ISPN-4985 > URL: https://issues.jboss.org/browse/ISPN-4985 > Project: Infinispan > Issue Type: Bug > Components: JCache > Affects Versions: 7.0.0.Final > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.0.1.Final > > > For TCK certification, we need the main production infinispan-jcache jar to include everything needed to run the TCK. This includes org.infinispan.jcache.test.tck.TckMbeanServerBuilder which currently is only available in the TCK runner project. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4919) Configuration templates

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4919?page=com.atlassian.jira.plugin.... ] Tristan Tarrant edited comment on ISPN-4919 at 11/17/14 4:37 AM: ----------------------------------------------------------------- Revising the above, I don't think we need to specify the type of cache in the multicache declaration, so a simple {code} <caches template="eviction-template" names="mycache ..." /> {code} should suffice was (Author: nadirx): Revising the above, I don't think we need to specify the type of cache in the multicache declaration, so a simple [code:xml] <caches template="eviction-template" names="mycache ..." /> [code] should suffice > Configuration templates > ----------------------- > > Key: ISPN-4919 > URL: https://issues.jboss.org/browse/ISPN-4919 > Project: Infinispan > Issue Type: Feature Request > Components: Configuration > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 7.1.0.Alpha1 > > > Currently there is a 1:1 relationship between configuration and named caches. While the programmatic API does have the ability to .read() an existing configuration to create a new one, the declarative config does not. > We should introduce the concept of configuration inheritance, e.g.: > {code} > <local-cache name="eviction-cache"> > <eviction strategy="LIRS" maxEntries="10000"/> > </local-cache> > <local-cache name="mycache" template="eviction-cache" /> > {code} > Possibly, cache templates should be made "abstract" so that they cannot be instantiated as named caches directly, e.g.: > {code} > <local-cache name="eviction-cache" abstract="true"> > ... > </local-cache> > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4919) Configuration templates

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4919?page=com.atlassian.jira.plugin.... ] Tristan Tarrant commented on ISPN-4919: --------------------------------------- Revising the above, I don't think we need to specify the type of cache in the multicache declaration, so a simple [code:xml] <caches template="eviction-template" names="mycache ..." /> [code] should suffice > Configuration templates > ----------------------- > > Key: ISPN-4919 > URL: https://issues.jboss.org/browse/ISPN-4919 > Project: Infinispan > Issue Type: Feature Request > Components: Configuration > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 7.1.0.Alpha1 > > > Currently there is a 1:1 relationship between configuration and named caches. While the programmatic API does have the ability to .read() an existing configuration to create a new one, the declarative config does not. > We should introduce the concept of configuration inheritance, e.g.: > {code} > <local-cache name="eviction-cache"> > <eviction strategy="LIRS" maxEntries="10000"/> > </local-cache> > <local-cache name="mycache" template="eviction-cache" /> > {code} > Possibly, cache templates should be made "abstract" so that they cannot be instantiated as named caches directly, e.g.: > {code} > <local-cache name="eviction-cache" abstract="true"> > ... > </local-cache> > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4985) Allow JCache TCK to be run exclusively with the main jar

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4985?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-4985: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3079 > Allow JCache TCK to be run exclusively with the main jar > -------------------------------------------------------- > > Key: ISPN-4985 > URL: https://issues.jboss.org/browse/ISPN-4985 > Project: Infinispan > Issue Type: Bug > Components: JCache > Affects Versions: 7.0.0.Final > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.0.1.Final > > > For TCK certification, we need the main production infinispan-jcache jar to include everything needed to run the TCK. This includes org.infinispan.jcache.test.tck.TckMbeanServerBuilder which currently is only available in the TCK runner project. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4985) Allow JCache TCK to be run exclusively with the main jar

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4985?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-4985: ----------------------------------- Status: Open (was: New) > Allow JCache TCK to be run exclusively with the main jar > -------------------------------------------------------- > > Key: ISPN-4985 > URL: https://issues.jboss.org/browse/ISPN-4985 > Project: Infinispan > Issue Type: Bug > Components: JCache > Affects Versions: 7.0.0.Final > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.0.1.Final > > > For TCK certification, we need the main production infinispan-jcache jar to include everything needed to run the TCK. This includes org.infinispan.jcache.test.tck.TckMbeanServerBuilder which currently is only available in the TCK runner project. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 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 November 2014