August 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4587) Re-add old owners in the pending CH when a node leaves during rebalance

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4587?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-4587: -------------------------------- Fix Version/s: 7.0.0.Beta2 (was: 7.0.0.Beta1) > Re-add old owners in the pending CH when a node leaves during rebalance > ----------------------------------------------------------------------- > > Key: ISPN-4587 > URL: https://issues.jboss.org/browse/ISPN-4587 > Project: Infinispan > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Core, State Transfer > Affects Versions: 7.0.0.Alpha5 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Minor > Fix For: 7.0.0.Beta2 > > > Say we have a distributed cache \[A, B\] with {{numSegments = 1}} and {{numOwners = 2}}. The initial topology is _T_: currentCH = \{0: A B\}, pendingCH = null > C joins, and A starts a rebalance. The topology is now _T + 1_: currentCH = \{0: A B\}, pendingCH = \{0: A C\} > C now leaves, A updates the consistent hashes to remove it with a new topology _T + 2: currentCH = \{0: A B\}, pendingCH = \{0: A\} > A doesn't need to receive any data, so the rebalance ends and the pending CH is installed as the current CH in topology _T + 3_: currentCH = \{0: A\}, pendingCH = null > This algorithm is relatively easy to follow and implement, but it does result in reduced availability of the cache data. It would be better if topology _T + 2_ could re-add B as an owner in the pending CH. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4603) Introduce an Externalizer for Infinispan's ConcurrentHashSet

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4603?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-4603: -------------------------------- Fix Version/s: 7.0.0.Beta2 (was: 7.0.0.Beta1) > Introduce an Externalizer for Infinispan's ConcurrentHashSet > ------------------------------------------------------------ > > Key: ISPN-4603 > URL: https://issues.jboss.org/browse/ISPN-4603 > Project: Infinispan > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Core > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Priority: Minor > Fix For: 7.0.0.Beta2 > > > The ConcurrentHashSet is quite expensive to marshall when using fallback serialization -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4596) Avoid index cleanup operations on putIfAbsent

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4596?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-4596: -------------------------------- Fix Version/s: 7.0.0.Beta2 (was: 7.0.0.Beta1) > Avoid index cleanup operations on putIfAbsent > --------------------------------------------- > > Key: ISPN-4596 > URL: https://issues.jboss.org/browse/ISPN-4596 > Project: Infinispan > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Embedded Querying > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Fix For: 7.0.0.Beta2 > > > when doing a putIfAbsent() operation we can relax some of the internal cleanup operations, such as automatically enabling the Flag.SKIP_INDEX_CLEANUP -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4593) Expose a method to remove all instances of a type from the indexes

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4593?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-4593: -------------------------------- Fix Version/s: 7.0.0.Beta2 (was: 7.0.0.Beta1) > Expose a method to remove all instances of a type from the indexes > ------------------------------------------------------------------ > > Key: ISPN-4593 > URL: https://issues.jboss.org/browse/ISPN-4593 > Project: Infinispan > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Embedded Querying > Reporter: Sanne Grinovero > Assignee: Gustavo Fernandes > Fix For: 7.0.0.Beta2 > > > In Hibernate Search we have a method "purgeAll( type )", it seems Infinispan Query is missing this operation. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4626) Race condition in the LocalEntryRetriever between iterator() and hasNext()

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4626?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4626: ----------------------------------------------- Adrian Nistor <anistor(a)redhat.com> changed the Status of [bug 1128817|https://bugzilla.redhat.com/show_bug.cgi?id=1128817] from NEW to MODIFIED > Race condition in the LocalEntryRetriever between iterator() and hasNext() > -------------------------------------------------------------------------- > > Key: ISPN-4626 > URL: https://issues.jboss.org/browse/ISPN-4626 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Core > Affects Versions: 7.0.0.Alpha5 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Fix For: 7.0.0.Beta1 > > > The LocalEntryRetriver sometimes will erroneously return false for hasNext right after creation of the iterator, because initial retrieval is done on a separate thread and it may not finish on time. > This is causing intermittent failures in the index-less query tests. See ISPN-4594 -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4626) Race condition in the LocalEntryRetriever between iterator() and hasNext()

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4626?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-4626: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1128817 > Race condition in the LocalEntryRetriever between iterator() and hasNext() > -------------------------------------------------------------------------- > > Key: ISPN-4626 > URL: https://issues.jboss.org/browse/ISPN-4626 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Core > Affects Versions: 7.0.0.Alpha5 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Fix For: 7.0.0.Beta1 > > > The LocalEntryRetriver sometimes will erroneously return false for hasNext right after creation of the iterator, because initial retrieval is done on a separate thread and it may not finish on time. > This is causing intermittent failures in the index-less query tests. See ISPN-4594 -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4602) Verify EntryIterator works with MarshalledValues

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4602?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-4602: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1128811 > Verify EntryIterator works with MarshalledValues > ------------------------------------------------ > > Key: ISPN-4602 > URL: https://issues.jboss.org/browse/ISPN-4602 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Marshalling > Affects Versions: 7.0.0.Alpha5 > Reporter: William Burns > Assignee: William Burns > Fix For: 7.0.0.Beta1 > > > The EntryIterator currently doesn't deserialize MarshalledValues as needed which would cause filter failures and the incorrect values to be returned. > This also means each key/value pair would need to be deserialized when applied to filter which will be slower and should be noted in documentation, but sent across as MarshalledValues?. The only other way is to use some sort of proxy for each object to force lazy deserialization on referencing a field when applying filter, but this seems overkill. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4376) AdvancedCache.filterEntries(...) does not respect configured cache flags

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4376?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-4376: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1128808 > AdvancedCache.filterEntries(...) does not respect configured cache flags > ------------------------------------------------------------------------ > > Key: ISPN-4376 > URL: https://issues.jboss.org/browse/ISPN-4376 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Core > Affects Versions: 7.0.0.Alpha4 > Reporter: Paul Ferraro > Assignee: William Burns > Fix For: 7.0.0.Beta1 > > > Consider the following: > {code} > Cache<K, V> cache = ...; > KeyValueFilter<K, V> filter = ...; > EntryIterator<K, V> entries = cache.getAdvancedCache().withFlags(Flag.CACHE_MODE_LOCAL, Flag.SKIP_CACHE_LOAD).filterEntries(filter); > {code} > One would expect this to return only local, in-memory entries, but it instead returns both entries from remote nodes and from a cache loader, effectively ignoring the configured flags. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4583) Distributed iterator throws ClassCastException when loader contains values that pass filter

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4583?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-4583: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1128808 > Distributed iterator throws ClassCastException when loader contains values that pass filter > ------------------------------------------------------------------------------------------- > > Key: ISPN-4583 > URL: https://issues.jboss.org/browse/ISPN-4583 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Core > Affects Versions: 7.0.0.Alpha5 > Reporter: Alan Field > Assignee: William Burns > Fix For: 7.0.0.Beta1 > > Attachments: repl-udp-no-tx-leveldb-jni.xml > > > This code will iterate over all of the entries in a cache to get the total size: > {code:java} > public int getTotalSize() { > log.info(getClass().getName() + ".getTotalSize() for cache " + cache.getName()); > int totalSize = 0; > EntryIterable entryIterator = null; > try { > entryIterator = cache.filterEntries(new AllEntriesFilter()); > CloseableIterable ci = entryIterator.converter(new AllEntriesConverter()); > Iterator iter = ci.iterator(); > while (iter.hasNext()) { > iter.next(); > totalSize++; > } > return totalSize; > } finally { > if (entryIterator != null) { > try { > entryIterator.close(); > } catch (Exception e) { > log.error("Failed to close EntryIterable", e); > } > } > } > } > {code} > I wanted to verify that this code would also work when I was using passivation and a cachestore. The repl-udp-no-tx-leveldb-jni.xml file defines the configuration that I am using. I run a test that puts random data into the cache then checks the size of the cache, but I am getting a bunch of ClassCastException exceptions during the iteration: > {noformat} > java.lang.ClassCastException: java.lang.String cannot be cast to org.infinispan.container.entries.InternalCacheEntry > at org.infinispan.iteration.impl.LocalEntryRetriever$MapAction.apply(LocalEntryRetriever.java:251) > at org.infinispan.iteration.impl.LocalEntryRetriever$KeyValueActionForCacheLoaderTask.processEntry(LocalEntryRetriever.java:154) > at org.infinispan.persistence.leveldb.LevelDBStore$1.call(LevelDBStore.java:297) > at org.infinispan.persistence.leveldb.LevelDBStore$1.call(LevelDBStore.java:285) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:22) > at java.util.concurrent.ExecutorCompletionService.submit(ExecutorCompletionService.java:181) > at org.infinispan.executors.ExecutorAllCompletionService.submit(ExecutorAllCompletionService.java:31) > at org.infinispan.persistence.leveldb.LevelDBStore.submitProcessTask(LevelDBStore.java:285) > at org.infinispan.persistence.leveldb.LevelDBStore.process(LevelDBStore.java:260) > at org.infinispan.persistence.manager.PersistenceManagerImpl.processOnAllStores(PersistenceManagerImpl.java:438) > at org.infinispan.persistence.manager.PersistenceManagerImpl.processOnAllStores(PersistenceManagerImpl.java:420) > at org.infinispan.iteration.impl.LocalEntryRetriever$1.run(LocalEntryRetriever.java:217) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) > {noformat} -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4630) DistributedEntryRetriever throws NPE if iterator is closed before processing all responses

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4630?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4630: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1128741|https://bugzilla.redhat.com/show_bug.cgi?id=1128741] from POST to MODIFIED > DistributedEntryRetriever throws NPE if iterator is closed before processing all responses > ------------------------------------------------------------------------------------------ > > Key: ISPN-4630 > URL: https://issues.jboss.org/browse/ISPN-4630 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Core > Affects Versions: 7.0.0.Alpha5 > Reporter: William Burns > Assignee: William Burns > Fix For: 7.0.0.Beta1 > > > DistributedEntryRetriever itrerator needs to ignore responses from nodes if a iterator is closed early or if a rehash occurs causing some redundant requests to be sent. > This was covered in a previous version but refactoring lost it somehow and instead the code is using variables that cannot be null. > {code} > } else if (log.isTraceEnabled()) { > log.tracef("Ignoring values as identifier %s was marked as complete", identifier); > } > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 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 August 2014