November 2014 - infinispan-issues

[JBoss JIRA] (ISPN-4874) Cross-site replication - allow defining custom backup cache name

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4874?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4874: ----------------------------------------------- Matej Čimbora <mcimbora(a)redhat.com> changed the Status of [bug 1156088|https://bugzilla.redhat.com/show_bug.cgi?id=1156088] from ON_QA to VERIFIED > Cross-site replication - allow defining custom backup cache name > ---------------------------------------------------------------- > > Key: ISPN-4874 > URL: https://issues.jboss.org/browse/ISPN-4874 > Project: Infinispan > Issue Type: Bug > Components: Cross-Site Replication, Server > Affects Versions: 7.0.0.CR2 > Reporter: Matej Čimbora > Assignee: Pedro Ruivo > Fix For: 7.0.0.Final > > > Using client-server mode, it's currently not possible to specify custom name for backup cache (different from the name of the main cache), as "backup-for" setting is missing. The issue can be workarounded by using the same name for the main & backup cache. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4679) OsgiClassLoader needs null check when iterating bundles

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4679?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-4679: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1161349 > OsgiClassLoader needs null check when iterating bundles > ------------------------------------------------------- > > Key: ISPN-4679 > URL: https://issues.jboss.org/browse/ISPN-4679 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.0.0.Beta1 > Reporter: Niels Bertram > Assignee: Dan Berindei > Priority: Minor > Fix For: 7.0.0.Beta2, 7.0.0.Final > > > {{org.infinispan.commons.util.OsgiClassLoader}} requires a null check when the bundle is retrieved from a WeakReference. > {code:java} > for (WeakReference<Bundle> ref : bundles) { > final Bundle bundle = ref.get(); > // BUG: we may not get a bundle back from the weak reference, eg. if uninstalled or deactivated > if (bundle.getState() == Bundle.ACTIVE) { > try { > final Class clazz = bundle.loadClass(name); > if (clazz != null) { > classCache.put(name, clazz); > return clazz; > } > } catch (Exception ignore) { > } > } > } > {code} > I am running 7.0.0.Beta1 on servicemix 5.1.1 and can't load this simple infinispan.xml: > {code:xml} > <infinispan xmlns="urn:infinispan:config:7.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="urn:infinispan:config:7.0 http://infinispan.org/schemas/infinispan-config-7.0.xsd"> > <cache-container default-cache="default" name="TestContainer"> > <jmx domain="TestDomain" mbean-server-lookup="org.infinispan.jmx.PerThreadMBeanServerLookup" duplicate-domains="true"/> >  > <local-cache name="default" statistics="false"> > <locking concurrency-level="100" acquire-timeout="1000"/> > <transaction mode="NONE" complete-timeout="3123" reaper-interval="123"/> > </local-cache> > </cache-container> > </infinispan> > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4951) Entry Retriever iterator should rethrow caused exception

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4951?page=com.atlassian.jira.plugin.... ] Work on ISPN-4951 started by William Burns. ------------------------------------------- > Entry Retriever iterator should rethrow caused exception > -------------------------------------------------------- > > Key: ISPN-4951 > URL: https://issues.jboss.org/browse/ISPN-4951 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 7.0.0.Final > Reporter: William Burns > Assignee: William Burns > Fix For: 7.1.0.Alpha1 > > > Now that we have a way to propagate an Exception to the iterator for partitions, we should also do this if an exception is found in any thread that processes data for the iterator. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4951) Entry Retriever iterator should rethrow caused exception

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4951?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-4951: -------------------------------- Status: Open (was: New) > Entry Retriever iterator should rethrow caused exception > -------------------------------------------------------- > > Key: ISPN-4951 > URL: https://issues.jboss.org/browse/ISPN-4951 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 7.0.0.Final > Reporter: William Burns > Assignee: William Burns > Fix For: 7.1.0.Alpha1 > > > Now that we have a way to propagate an Exception to the iterator for partitions, we should also do this if an exception is found in any thread that processes data for the iterator. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4951) Entry Retriever iterator should rethrow caused exception

by William Burns (JIRA)

William Burns created ISPN-4951: ----------------------------------- Summary: Entry Retriever iterator should rethrow caused exception Key: ISPN-4951 URL: https://issues.jboss.org/browse/ISPN-4951 Project: Infinispan Issue Type: Enhancement Components: Core Affects Versions: 7.0.0.Final Reporter: William Burns Assignee: William Burns Fix For: 7.1.0.Alpha1 Now that we have a way to propagate an Exception to the iterator for partitions, we should also do this if an exception is found in any thread that processes data for the iterator. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4837) @CacheEntryActivated events received for keys not matching KeyFilter

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4837?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4837: ----------------------------------------------- William Burns <wburns(a)redhat.com> changed the Status of [bug 1155107|https://bugzilla.redhat.com/show_bug.cgi?id=1155107] from ASSIGNED to POST > @CacheEntryActivated events received for keys not matching KeyFilter > -------------------------------------------------------------------- > > Key: ISPN-4837 > URL: https://issues.jboss.org/browse/ISPN-4837 > Project: Infinispan > Issue Type: Bug > Components: Listeners > Affects Versions: 7.0.0.CR1 > Reporter: Paul Ferraro > Assignee: William Burns > Priority: Critical > Fix For: 7.0.0.CR2 > > > I have a local-mode Cache<Object, ?>, for which I register a cache listener using the following KeyFilter: > {noformat} > class MyFIlter implements KeyFilter<Object> { > @Override > public boolean accept(Object key) { > return key instanceof String; > } > } > {noformat} > However, my listener method still receives events for keys that does not match the filter with which my listener was registered. > e.g. > {noformat} > @CacheEntryActivated > public void activated(CacheEntryActivatedEvent<String, ?> event) { > String id = event.getKey(); // Throws a ClassCastException > // ... > } > {noformat} > I have not validated which other event types might exhibit the same issue. > Since this is a behavior regression, I'm filing this as critical. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 5 months

1
0
0 / 0

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

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-4949?page=com.atlassian.jira.plugin.... ] Radim Vansa commented on ISPN-4949: ----------------------------------- As commented on IRC by [~dan.berindei], the problem is deeper. When the cluster ABCD can break into views ABC, CDB, it's possible that both (active) parts will modify an entry. It seems the nodes need to achieve consensus about view membership - C must not be part of two views at any moment. That requires a modification in JGroups, not in Infinispan, and may prove troublesome even from theoretical perspective. > 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 > 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, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4950) Expiration settings not applied to entries stored via CLI

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4950?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-4950: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1158098 > Expiration settings not applied to entries stored via CLI > --------------------------------------------------------- > > Key: ISPN-4950 > URL: https://issues.jboss.org/browse/ISPN-4950 > Project: Infinispan > Issue Type: Bug > Components: CLI, Remote Protocols, Server > Affects Versions: 7.0.0.Final > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.1.0.Alpha1, 7.1.0.Final > > > Data stored via CLI does not seem to get container expiration settings applied. E.g. > For a server side configuration like this: > {code} > <local-cache name="shay" start="EAGER"> > <expiration lifespan="1000" max-idle="1000"/> > </local-cache> > {code} > Storing it and retrieving it always returns the entry, no matter how long it's waited: > {code} > [disconnected /] connect > [standalone@localhost:9990 /] cd subsystem=infinispan/cache-container=local > [standalone@localhost:9990 cache-container=local] cache shay > [standalone@localhost:9990 local-cache=shay] put a a1 > [standalone@localhost:9990 local-cache=shay] get a > a1 > ... > [standalone@localhost:9990 local-cache=shay] get a > a1 > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4950) Expiration settings not applied to entries stored via CLI

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-4950: -------------------------------------- Summary: Expiration settings not applied to entries stored via CLI Key: ISPN-4950 URL: https://issues.jboss.org/browse/ISPN-4950 Project: Infinispan Issue Type: Bug Components: CLI, Remote Protocols, Server Affects Versions: 7.0.0.Final Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 7.1.0.Alpha1, 7.1.0.Final Data stored via CLI does not seem to get container expiration settings applied. E.g. For a server side configuration like this: {code} <local-cache name="shay" start="EAGER"> <expiration lifespan="1000" max-idle="1000"/> </local-cache> {code} Storing it and retrieving it always returns the entry, no matter how long it's waited: {code} [disconnected /] connect [standalone@localhost:9990 /] cd subsystem=infinispan/cache-container=local [standalone@localhost:9990 cache-container=local] cache shay [standalone@localhost:9990 local-cache=shay] put a a1 [standalone@localhost:9990 local-cache=shay] get a a1 ... [standalone@localhost:9990 local-cache=shay] get a a1 {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 5 months

1
0
0 / 0

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

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-4949?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-4949: ------------------------------ Description: 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 was: 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 oldest stable topology has CH [A, B, C, D] - 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 > 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 > 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, 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 November 2014