November 2014 - infinispan-issues

[JBoss JIRA] (ISPN-4948) Package embedded CLI as uberjar

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4948?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4948: ---------------------------------- Status: Open (was: New) > Package embedded CLI as uberjar > ------------------------------- > > Key: ISPN-4948 > URL: https://issues.jboss.org/browse/ISPN-4948 > Project: Infinispan > Issue Type: Feature Request > Components: CLI > Affects Versions: 7.0.0.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 7.1.0.Alpha1 > > > The embedded mode CLI depends on a plethora of jars. It can be packaged in a single jar with a proper main class manifest -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4948) Package embedded CLI as uberjar

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4948?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4948: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3052 > Package embedded CLI as uberjar > ------------------------------- > > Key: ISPN-4948 > URL: https://issues.jboss.org/browse/ISPN-4948 > Project: Infinispan > Issue Type: Feature Request > Components: CLI > Affects Versions: 7.0.0.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 7.1.0.Alpha1 > > > The embedded mode CLI depends on a plethora of jars. It can be packaged in a single jar with a proper main class manifest -- 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 ON_QA to ASSIGNED > @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 updated ISPN-4949: ------------------------------ Issue Type: Bug (was: Feature Request) > 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 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 -- 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: ------------------------------ Summary: Split brain: inconsistent data after merge (was: Split brain: data updated in degraded mode) > Split brain: inconsistent data after merge > ------------------------------------------ > > Key: ISPN-4949 > URL: https://issues.jboss.org/browse/ISPN-4949 > Project: Infinispan > Issue Type: Feature Request > 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 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 -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4850) Allow for filter and conversion to be done in one step for cache listeners

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4850?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4850: ----------------------------------------------- William Burns <wburns(a)redhat.com> changed the Status of [bug 1154044|https://bugzilla.redhat.com/show_bug.cgi?id=1154044] from ON_QA to ASSIGNED > Allow for filter and conversion to be done in one step for cache listeners > -------------------------------------------------------------------------- > > Key: ISPN-4850 > URL: https://issues.jboss.org/browse/ISPN-4850 > Project: Infinispan > Issue Type: Enhancement > Components: Listeners > Affects Versions: 7.0.0.CR1 > Reporter: William Burns > Assignee: William Burns > Fix For: 7.0.0.Final > > > Currently the cache listeners can install a CacheEventFilter and CacheEventConverter to be used. However each one requires separate invocations. It would be desireable to have this done as a single invocation akin to what we did for ISPN-4640. -- 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: data updated in degraded mode

by Radim Vansa (JIRA)

Radim Vansa created ISPN-4949: --------------------------------- Summary: Split brain: data updated in degraded mode Key: ISPN-4949 URL: https://issues.jboss.org/browse/ISPN-4949 Project: Infinispan Issue Type: Feature Request 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 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 -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4643) Make sure EntryIterator doesn't return expired entries

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4643?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4643: ----------------------------------------------- William Burns <wburns(a)redhat.com> changed the Status of [bug 1151056|https://bugzilla.redhat.com/show_bug.cgi?id=1151056] from MODIFIED to ON_QA > Make sure EntryIterator doesn't return expired entries > ------------------------------------------------------ > > Key: ISPN-4643 > URL: https://issues.jboss.org/browse/ISPN-4643 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.0.0.Beta1 > Reporter: William Burns > Assignee: William Burns > Fix For: 7.0.0.CR2 > > > We should make sure that the entry iterator doesn't return entries that have expired. Since entries can sit in the data container while expired we need to make sure to ignore those. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4389) Tests for suppressing state transfer with jmx fail

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4389?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4389: ----------------------------------------------- William Burns <wburns(a)redhat.com> changed the Status of [bug 1108035|https://bugzilla.redhat.com/show_bug.cgi?id=1108035] from MODIFIED to ON_QA > Tests for suppressing state transfer with jmx fail > -------------------------------------------------- > > Key: ISPN-4389 > URL: https://issues.jboss.org/browse/ISPN-4389 > Project: Infinispan > Issue Type: Bug > Components: Server, State Transfer > Reporter: William Burns > Assignee: William Burns > Fix For: 7.0.0.Alpha5 > > Attachments: server-full-trace.tar.gz > > > http://ci.infinispan.org/viewLog.html?buildId=8736&buildTypeId=bt8&tab=bu... > {code} > 12:00:43,839 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.infinispan.clustered.default: org.jboss.msc.service.StartException in service jboss.infinispan.clustered.default: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1767) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_06] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_06] > at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_06] > Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.InterruptedException on object of type StateTransferManagerImpl > at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:170) > at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869) > at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638) > at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627) > at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530) > at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:216) > at org.infinispan.CacheImpl.start(CacheImpl.java:696) > at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:574) > at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:529) > at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:409) > at org.infinispan.registry.ClusterRegistryImpl.startRegistryCache(ClusterRegistryImpl.java:136) > at org.infinispan.registry.ClusterRegistryImpl.addListener(ClusterRegistryImpl.java:97) > at org.infinispan.query.remote.ProtobufMetadataManager.ensureInit(ProtobufMetadataManager.java:65) > at org.infinispan.query.remote.ProtobufMetadataManager.getSerializationContext(ProtobufMetadataManager.java:132) > at org.infinispan.query.remote.LifecycleManager.cacheStarting(LifecycleManager.java:114) > at org.infinispan.factories.ComponentRegistry.notifyCacheStarting(ComponentRegistry.java:228) > at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:214) > at org.infinispan.CacheImpl.start(CacheImpl.java:696) > at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:574) > at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:529) > at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:409) > at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:423) > at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:89) > at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:80) > at org.jboss.as.clustering.infinispan.subsystem.SecurityActions$5.run(SecurityActions.java:101) > at org.jboss.as.clustering.infinispan.subsystem.SecurityActions$5.run(SecurityActions.java:98) > at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_06] > at org.jboss.as.clustering.infinispan.subsystem.SecurityActions.startCache(SecurityActions.java:109) > at org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:78) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1] > ... 3 more > Caused by: org.infinispan.commons.CacheException: Initial state transfer timed out for cache __cluster_registry_cache__ on node2/clustered > at org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete(StateTransferManagerImpl.java:209) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_06] > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_06] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_06] > at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_06] > at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168) > ... 33 more > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4745) Cluster Listener TX Batch incorrect when sending multiple events

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4745?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4745: ----------------------------------------------- William Burns <wburns(a)redhat.com> changed the Status of [bug 1144579|https://bugzilla.redhat.com/show_bug.cgi?id=1144579] from NEW to ON_QA > Cluster Listener TX Batch incorrect when sending multiple events > ---------------------------------------------------------------- > > Key: ISPN-4745 > URL: https://issues.jboss.org/browse/ISPN-4745 > Project: Infinispan > Issue Type: Bug > Components: Listeners > Affects Versions: 7.0.0.Beta2 > Reporter: William Burns > Assignee: William Burns > Priority: Critical > Fix For: 7.0.0.CR1 > > > While glancing through the code I noticed that the RemoteListener incorrectly sends the events after each event while looping on them this causes (n * (n + 1)) / 2 as many events in the batch, which is incorrect when n > 1. We just need to move the submit outside of the for loop. -- 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