[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"/>
> <!-- definitions of the caches -->
> <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
[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
[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
[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
[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
[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
[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