August 2014 - infinispan-issues - Jboss List Archives

[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: ----------------------------------------------- Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1128808|https://bugzilla.redhat.com/show_bug.cgi?id=1128808] from MODIFIED to ON_QA > 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, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4559) Replace fails with cache loader

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4559?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4559: ----------------------------------------------- Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1122269|https://bugzilla.redhat.com/show_bug.cgi?id=1122269] from POST to ON_QA > Replace fails with cache loader > ------------------------------- > > Key: ISPN-4559 > URL: https://issues.jboss.org/browse/ISPN-4559 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Loaders and Stores > Affects Versions: 7.0.0.Alpha5 > Reporter: Dennis Reed > Assignee: Pedro Ruivo > Priority: Critical > Fix For: 7.0.0.Beta2 > > > cache.replace(key, oldValue, newValue) compares the current value in the cache to oldValue, and if they differ it turns into a no-op. > However, CacheLoaderInterceptor does not load entries for a ReplaceCommand. > If the entry only exists in the loader and not in memory, this causes the replace to fail. > CacheLoaderInterceptor must always load the value for a ReplaceCommand. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4640) Enhance distributed iterator to allow filter and converter to be executed in the same step/invocation

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4640?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4640: ----------------------------------------------- Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1130648|https://bugzilla.redhat.com/show_bug.cgi?id=1130648] from MODIFIED to ON_QA > Enhance distributed iterator to allow filter and converter to be executed in the same step/invocation > ----------------------------------------------------------------------------------------------------- > > Key: ISPN-4640 > URL: https://issues.jboss.org/browse/ISPN-4640 > Project: Infinispan > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Core > Affects Versions: 7.0.0.Alpha1 > Reporter: Adrian Nistor > Assignee: William Burns > Fix For: 7.0.0.Beta2 > > > This enhancement is needed for performance and should make FilterAndConverter class obsolete. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 7 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: ----------------------------------------------- Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1128741|https://bugzilla.redhat.com/show_bug.cgi?id=1128741] from MODIFIED to ON_QA > 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.Beta2 > > > 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, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4635) Query DSL should check against mixing objects created by different factories or builders

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4635?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4635: ----------------------------------------------- Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1129586|https://bugzilla.redhat.com/show_bug.cgi?id=1129586] from MODIFIED to ON_QA > Query DSL should check against mixing objects created by different factories or builders > ---------------------------------------------------------------------------------------- > > Key: ISPN-4635 > URL: https://issues.jboss.org/browse/ISPN-4635 > Project: Infinispan > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Embedded Querying > Affects Versions: 7.0.0.Beta1 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 7.0.0.Beta2 > > > Methods FilterConditionBeginContext.not(..), QueryFactory.not(..), FilterConditionContext.and(..), FilterConditionContext.or(..) should check that the argument was created by the same factory and is not already owned by another builder. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4618) Map/Reduce jobs should not timeout by default

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4618?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4618: ----------------------------------------------- Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1128791|https://bugzilla.redhat.com/show_bug.cgi?id=1128791] from POST to ON_QA > Map/Reduce jobs should not timeout by default > --------------------------------------------- > > Key: ISPN-4618 > URL: https://issues.jboss.org/browse/ISPN-4618 > Project: Infinispan > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Distributed Execution and Map/Reduce > Reporter: Sanne Grinovero > Assignee: Vladimir Blagojevic > Fix For: 7.0.0.Beta1 > > > It seems the fault of the jobs today is to timeout at the same timeout of replication commands. > The default should be to not timeout, and allow the user to optionially set a timeout. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4654) AND over range queries does not work (indexless query)

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-4654?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-4654: ------------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > AND over range queries does not work (indexless query) > ------------------------------------------------------ > > Key: ISPN-4654 > URL: https://issues.jboss.org/browse/ISPN-4654 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Embedded Querying, Remote Querying > Affects Versions: 6.0.2.Final, 7.0.0.Beta1 > Reporter: Radim Vansa > Assignee: Adrian Nistor > > Check this in QueryDslConditionsTest: > {code} > public void testAnd5() throws Exception { > QueryFactory qf = getQueryFactory(); > // range queries use different code > Query q = qf.from(getModelFactory().getUserImplClass()) > .having("id").lt(1000) > .and().having("age").lt(1000) > .toBuilder().build(); > List<User> list = q.list(); > assertEquals(3, list.size()); > } > {code} > The problem is that some subscription gets suspended and the second LT does not fire the second predicate update (and then neither the AND reevaluation). -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4654) AND over range queries does not work (indexless query)

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4654?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4654: ----------------------------------------------- Adrian Nistor <anistor(a)redhat.com> changed the Status of [bug 1132121|https://bugzilla.redhat.com/show_bug.cgi?id=1132121] from NEW to MODIFIED > AND over range queries does not work (indexless query) > ------------------------------------------------------ > > Key: ISPN-4654 > URL: https://issues.jboss.org/browse/ISPN-4654 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Embedded Querying, Remote Querying > Affects Versions: 6.0.2.Final, 7.0.0.Beta1 > Reporter: Radim Vansa > Assignee: Adrian Nistor > > Check this in QueryDslConditionsTest: > {code} > public void testAnd5() throws Exception { > QueryFactory qf = getQueryFactory(); > // range queries use different code > Query q = qf.from(getModelFactory().getUserImplClass()) > .having("id").lt(1000) > .and().having("age").lt(1000) > .toBuilder().build(); > List<User> list = q.list(); > assertEquals(3, list.size()); > } > {code} > The problem is that some subscription gets suspended and the second LT does not fire the second predicate update (and then neither the AND reevaluation). -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4650) MassIndexer should not use UpdateDocument when adding to Lucene

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-4650?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-4650: ------------------------------------ Description: The MassIndexer currently causes a Delete plus and Add operation to hibernate search backend. Lucene buffers those deletes queries and during merge it tries to 'apply' those deletes wasting a massive amount of time doing seeks and queries unnecessarily. Since the mass indexer wipes the index at the beginning, it should simply issue an add operation (or at least rely on Lucene atomic IndexWriter.updateDocument). Performance wise this make a huge difference: * indexing 50k documents brings down the indexing time from 195s to 33s * indexing 200k documents brings down the indexing time from 600s to 55s was: The MassIndexer currently issues a Delete plus and Add operation to hibernate search backend. Lucene buffers those deletes queries and during merge it tries to 'apply' those deletes wasting a massive amount of time doing seeks and queries unnecessarily. Since the mass indexer wipes the index at the beginning, it should simply issue an add operation (or at least rely on Lucene atomic IndexWriter.updateDocument). Performance wise this make a huge difference: * indexing 50k documents brings down the indexing time from 195s to 33s * indexing 200k documents brings down the indexing time from 600s to 55s > MassIndexer should not use UpdateDocument when adding to Lucene > --------------------------------------------------------------- > > Key: ISPN-4650 > URL: https://issues.jboss.org/browse/ISPN-4650 > Project: Infinispan > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Embedded Querying > Affects Versions: 7.0.0.Beta1 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Fix For: 7.0.0.Beta2 > > > The MassIndexer currently causes a Delete plus and Add operation to hibernate search backend. > Lucene buffers those deletes queries and during merge it tries to 'apply' those deletes wasting a massive amount of time doing seeks and queries unnecessarily. > Since the mass indexer wipes the index at the beginning, it should simply issue an add operation (or at least rely on Lucene atomic IndexWriter.updateDocument). Performance wise this make a huge difference: > * indexing 50k documents brings down the indexing time from 195s to 33s > * indexing 200k documents brings down the indexing time from 600s to 55s -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4650) MassIndexer should not use UpdateDocument when adding to Lucene

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-4650?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-4650: ------------------------------------ Description: The MassIndexer currently issues a Delete plus and Add operation to hibernate search backend. Lucene buffers those deletes queries and during merge it tries to 'apply' those deletes wasting a massive amount of time doing seeks and queries unnecessarily. Since the mass indexer wipes the index at the beginning, it should simply issue an add operation (or at least rely on Lucene atomic IndexWriter.updateDocument). Performance wise this make a huge difference: * indexing 50k documents brings down the indexing time from 195s to 33s * indexing 200k documents brings down the indexing time from 600s to 55s was: The MassIndexer currently issues a Delete plus and Add operation to hibernate search backend. Lucene buffers those deletes queries and during merge it tries to 'apply' those deletes wasting a massive amount of time doing seeks and queries unnecessarily. Since the mass indexer wipes the index at the beginning, it should simply issue an add operation. Performance wise this make a huge difference: * indexing 50k documents brings down the indexing time from 195s to 33s * indexing 200k documents brings down the indexing time from 600s to 55s > MassIndexer should not use UpdateDocument when adding to Lucene > --------------------------------------------------------------- > > Key: ISPN-4650 > URL: https://issues.jboss.org/browse/ISPN-4650 > Project: Infinispan > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Embedded Querying > Affects Versions: 7.0.0.Beta1 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Fix For: 7.0.0.Beta2 > > > The MassIndexer currently issues a Delete plus and Add operation to hibernate search backend. > Lucene buffers those deletes queries and during merge it tries to 'apply' those deletes wasting a massive amount of time doing seeks and queries unnecessarily. > Since the mass indexer wipes the index at the beginning, it should simply issue an add operation (or at least rely on Lucene atomic IndexWriter.updateDocument). Performance wise this make a huge difference: > * indexing 50k documents brings down the indexing time from 195s to 33s > * indexing 200k documents brings down the indexing time from 600s to 55s -- This message was sent by Atlassian JIRA (v6.2.6#6264)

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