August 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4652) Passivation with shared CacheLoader is not working properly

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-4652?page=com.atlassian.jira.plugin.... ] Work on ISPN-4652 started by Pedro Ruivo. ----------------------------------------- > Passivation with shared CacheLoader is not working properly > ----------------------------------------------------------- > > Key: ISPN-4652 > URL: https://issues.jboss.org/browse/ISPN-4652 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 7.0.0.Beta1 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 7.0.0.Beta2 > > > The activation does not interact with the shared cache store. This creates a problem for the RemoveCommand (at least) since the value is never removed (similar to https://issues.jboss.org/browse/ISPN-4649) > Unfortunately, this will need a little more thinking how to solve it since only the primary owner should activate (i.e. remove it) from the shared store. > Tests in LocalConditionalCommandTest and ClusteredConditionalCommandTest are disabled to because they are hitting this issue. > (ps to myself: don't forget to re-enabled them) -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 7 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 commented on ISPN-4583: ----------------------------------------------- Alan Field <afield(a)redhat.com> changed the Status of [bug 1128808|https://bugzilla.redhat.com/show_bug.cgi?id=1128808] from ON_QA to VERIFIED > 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.3.1#6329)

11 years, 7 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 commented on ISPN-4376: ----------------------------------------------- Alan Field <afield(a)redhat.com> changed the Status of [bug 1128808|https://bugzilla.redhat.com/show_bug.cgi?id=1128808] from ON_QA to VERIFIED > 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.3.1#6329)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4664) Consider passing command retries flag to remote events

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-4664: -------------------------------------- Summary: Consider passing command retries flag to remote events Key: ISPN-4664 URL: https://issues.jboss.org/browse/ISPN-4664 Project: Infinispan Issue Type: Enhancement Security Level: Public (Everyone can see) Components: Remote Protocols Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 7.0.0.Beta2 Cluster listeners have the ability to check whether an event is the result of a retried command. Even though HR clients are notified of failovers via the @ClientCacheFailover annotation, passing on this information could signal that an event is a duplicate or that another event was dropped and replaced (e.g. modified event replaced a created one). -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4663) Support JSR 107 keyType/valueType in Infinispan xml config

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4663?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-4663: ----------------------------------- Labels: hackathon (was: ) > Support JSR 107 keyType/valueType in Infinispan xml config > ---------------------------------------------------------- > > Key: ISPN-4663 > URL: https://issues.jboss.org/browse/ISPN-4663 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Ryan Dunckel > Assignee: Mircea Markus > Labels: hackathon > > There currently isn't an attribute/element on the infinispan xml config that can be used to set the expected keyType and valueType for type-safe caching. While this issue is being opened in the context of supporting JSR 107 type safe caches, it seems like a logical feature to support in infinispan core as well. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4065) Refuse to store an index on an ASYNC Cache

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4065?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-4065: ----------------------------------- Labels: 64QueryBlockers hackathon (was: 64QueryBlockers hack-idea) > Refuse to store an index on an ASYNC Cache > ------------------------------------------ > > Key: ISPN-4065 > URL: https://issues.jboss.org/browse/ISPN-4065 > Project: Infinispan > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Lucene Directory > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Priority: Minor > Labels: 64QueryBlockers, hackathon > Fix For: 7.0.0.Beta2, 7.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4663) Support JSR 107 keyType/valueType in Infinispan xml config

by Ryan Dunckel (JIRA)

Ryan Dunckel created ISPN-4663: ---------------------------------- Summary: Support JSR 107 keyType/valueType in Infinispan xml config Key: ISPN-4663 URL: https://issues.jboss.org/browse/ISPN-4663 Project: Infinispan Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Ryan Dunckel Assignee: Mircea Markus There currently isn't an attribute/element on the infinispan xml config that can be used to set the expected keyType and valueType for type-safe caching. While this issue is being opened in the context of supporting JSR 107 type safe caches, it seems like a logical feature to support in infinispan core as well. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4662) Support JSR 107 readThrough option on Infinispan xml config

by Ryan Dunckel (JIRA)

Ryan Dunckel created ISPN-4662: ---------------------------------- Summary: Support JSR 107 readThrough option on Infinispan xml config Key: ISPN-4662 URL: https://issues.jboss.org/browse/ISPN-4662 Project: Infinispan Issue Type: Bug Security Level: Public (Everyone can see) Components: JCache Reporter: Ryan Dunckel Assignee: Mircea Markus Currently, while Infinispan supports "read through" caches via the JSR 107 (JCache) programmatic config, it doesn't offer a read-through option to be set through the infinispan config xml. At the same time, Infinispan supports the JCache spec of checking to see if a cache is read-through (which defaults to false in JCache) before invoking a cache loader. This means that cache loaders don't get invoked for missing entries for JCache caches configured with infinispan's xml. There is no work-around to set the read-through option after the fact, because JCache configurations are immutable once the caches are created. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4661) TreeNode putIfAbsent implementation is different from what promised

by Berkes Adam (JIRA)

[ https://issues.jboss.org/browse/ISPN-4661?page=com.atlassian.jira.plugin.... ] Berkes Adam updated ISPN-4661: ------------------------------ Description: In infinispan tree API (infinispan-tree, 6.0.2.Final) the TreeNode implementation's putIfAbsent method always return null which is different from the promise document for the method signature. It should return the value for the given key if exists. (was: In infinispan tree API the TreeNode implementation's putIfAbsent method always return null which is different from the promise document for the method signature. It should return the value for the given key if exists.) Environment: JDK 1.7.0_60, Maven 3.2.2 (was: JDK 1.7.0_60) > TreeNode putIfAbsent implementation is different from what promised > ------------------------------------------------------------------- > > Key: ISPN-4661 > URL: https://issues.jboss.org/browse/ISPN-4661 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Core > Affects Versions: 6.0.2.Final > Environment: JDK 1.7.0_60, Maven 3.2.2 > Reporter: Berkes Adam > Assignee: Dan Berindei > > In infinispan tree API (infinispan-tree, 6.0.2.Final) the TreeNode implementation's putIfAbsent method always return null which is different from the promise document for the method signature. It should return the value for the given key if exists. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4661) TreeNode putIfAbsent implementation is different from what promised

by Berkes Adam (JIRA)

Berkes Adam created ISPN-4661: --------------------------------- Summary: TreeNode putIfAbsent implementation is different from what promised Key: ISPN-4661 URL: https://issues.jboss.org/browse/ISPN-4661 Project: Infinispan Issue Type: Bug Security Level: Public (Everyone can see) Components: Core Affects Versions: 6.0.2.Final Environment: JDK 1.7.0_60 Reporter: Berkes Adam Assignee: Dan Berindei In infinispan tree API the TreeNode implementation's putIfAbsent method always return null which is different from the promise document for the method signature. It should return the value for the given key if exists. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 7 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