June 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4377) Make receiving state for Hot Rod client listeners optional

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-4377: -------------------------------------- Summary: Make receiving state for Hot Rod client listeners optional Key: ISPN-4377 URL: https://issues.jboss.org/browse/ISPN-4377 Project: Infinispan Issue Type: Enhancement Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 7.0.0.Beta1 Receiving state for Hot Rod client listeners has a cost. Some users might not want to incur it, so it should be optional. By default, it should be enabled though for correctness. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4326) Change EntryIterator return type to be CacheEntry

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4326?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-4326: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Change EntryIterator return type to be CacheEntry > ------------------------------------------------- > > Key: ISPN-4326 > URL: https://issues.jboss.org/browse/ISPN-4326 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Reporter: William Burns > Assignee: William Burns > Fix For: 7.0.0.Alpha5 > > > Currently the entry retriever pieces return a Map.Entry. However end users may need the metadata along with that. We need to change this to return CacheEntry instead so the Metadata is available. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4372) Map/Reduce performance is dependent on cache value size

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4372?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-4372: ------------------------------------ Yes, please run the test with {{WordCountMapper}}. I would expect the memory usage of Infinispan 6 to be only slightly worse than {{WordCountMapperEmitPerValue}} with 1k values, especially if there are > 100 unique words. It's true, we don't know whether the performance with {{WordCountMapper}} also depends on the cache value size or not. But that's exactly why I wrote my comment, we've been testing a single M/R job, so we can't really say how a generic M/R job will perform (or even the same job but with a slightly different mapper). > Map/Reduce performance is dependent on cache value size > ------------------------------------------------------- > > Key: ISPN-4372 > URL: https://issues.jboss.org/browse/ISPN-4372 > Project: Infinispan > Issue Type: Feature Request > Components: Distributed Execution and Map/Reduce > Affects Versions: 7.0.0.Alpha4 > Reporter: Alan Field > Assignee: Vladimir Blagojevic > Labels: performance > > Performance testing the Map/Reduce changes has shown that the performance improvements vary based on the size of the values in the cache. [1] Using values from 8kB to 128kB shows a large performance increase over Infinispan 6, but smaller and larger values are the same or slower than Infinispan 6. > http://blog.infinispan.org/2014/06/mapreduce-performance-improvements.html -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4374) <cache-container/> should not require <serialization/> nor <jmx/> elements in XSD

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4374?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-4374: ------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 7.0.0.Alpha5 Resolution: Done > <cache-container/> should not require <serialization/> nor <jmx/> elements in XSD > --------------------------------------------------------------------------------- > > Key: ISPN-4374 > URL: https://issues.jboss.org/browse/ISPN-4374 > Project: Infinispan > Issue Type: Bug > Components: Configuration > Affects Versions: 7.0.0.Alpha4 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 7.0.0.Alpha5 > > > In the 7.0 schema, <cache-container/> currently requires both <serialization/> and <jmx/> elements. Both elements have no required attributes or elements, and thus should not be required. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4291) Poor REPL state transfer performance with cache stores

by Dennis Reed (JIRA)

[ https://issues.jboss.org/browse/ISPN-4291?page=com.atlassian.jira.plugin.... ] Dennis Reed resolved ISPN-4291. ------------------------------- Resolution: Rejected The entire cache store does still have to be iterated through with REPL to delete any stale data, so unfortunately this just takes a very long time with a slow cache store. > Poor REPL state transfer performance with cache stores > ------------------------------------------------------ > > Key: ISPN-4291 > URL: https://issues.jboss.org/browse/ISPN-4291 > Project: Infinispan > Issue Type: Bug > Components: State Transfer > Affects Versions: 6.0.2.Final > Reporter: Dennis Reed > Assignee: Dan Berindei > > During a state transfer every single key is loaded from the cache store to determine whether it's still owned by the local node. > This is an extremely slow operation, and doesn't even make sense for a REPL cache. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 10 months

1
0
0 / 0

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

by Paul Ferraro (JIRA)

Paul Ferraro created ISPN-4376: ---------------------------------- Summary: AdvancedCache.filterEntries(...) does not respect configured cache flags Key: ISPN-4376 URL: https://issues.jboss.org/browse/ISPN-4376 Project: Infinispan Issue Type: Bug Components: Core Affects Versions: 7.0.0.Alpha4 Reporter: Paul Ferraro Assignee: Dan Berindei 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.3#6260)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4367) Base Infinispan Query on Hibernate Search 5

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-4367?page=com.atlassian.jira.plugin.... ] Sanne Grinovero updated ISPN-4367: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Base Infinispan Query on Hibernate Search 5 > ------------------------------------------- > > Key: ISPN-4367 > URL: https://issues.jboss.org/browse/ISPN-4367 > Project: Infinispan > Issue Type: Enhancement > Components: Embedded Querying > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Labels: 64QueryBlockers > Fix For: 7.0.0.Alpha5 > > > And by so doing, drop the need to maintain Lucene V3 related code (the Lucene Directory especially, but also Solr and dependencies) -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4375) EntryIterable need not throw an exception on close()

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/ISPN-4375?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated ISPN-4375: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2622 > EntryIterable need not throw an exception on close() > ---------------------------------------------------- > > Key: ISPN-4375 > URL: https://issues.jboss.org/browse/ISPN-4375 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 7.0.0.Alpha4 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > > Currently, EntryIterable.close() throws an exception, which is inconsistent with the runtime exception conventions in the rest of the infinispan api. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4375) EntryIterable need not throw an exception on close()

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/ISPN-4375?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated ISPN-4375: ------------------------------- Description: Currently, EntryIterable.close() throws an exception, which is inconsistent with the runtime exception conventions in the rest of the infinispan api. (was: Currently, EntryIterable.close() throws an exception, which is inconsistent with the runtime exception conventions in the rest of the API.) > EntryIterable need not throw an exception on close() > ---------------------------------------------------- > > Key: ISPN-4375 > URL: https://issues.jboss.org/browse/ISPN-4375 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 7.0.0.Alpha4 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > > Currently, EntryIterable.close() throws an exception, which is inconsistent with the runtime exception conventions in the rest of the infinispan api. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4375) EntryIterable need not throw an exception on close()

by Paul Ferraro (JIRA)

Paul Ferraro created ISPN-4375: ---------------------------------- Summary: EntryIterable need not throw an exception on close() Key: ISPN-4375 URL: https://issues.jboss.org/browse/ISPN-4375 Project: Infinispan Issue Type: Enhancement Components: Core Affects Versions: 7.0.0.Alpha4 Reporter: Paul Ferraro Assignee: Paul Ferraro Currently, EntryIterable.close() throws an exception, which is inconsistent with the runtime exception conventions in the rest of the API. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 10 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 June 2014