June 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4442) Package remoting jars for the embedded cli client

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-4442: ------------------------------------- Summary: Package remoting jars for the embedded cli client Key: ISPN-4442 URL: https://issues.jboss.org/browse/ISPN-4442 Project: Infinispan Issue Type: Bug Security Level: Public (Everyone can see) Components: CLI Reporter: Tristan Tarrant Assignee: Tristan Tarrant Fix For: 7.0.0.Final -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-4442) Package remoting jars for the embedded cli client

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4442?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-4442: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1106451 > Package remoting jars for the embedded cli client > ------------------------------------------------- > > Key: ISPN-4442 > URL: https://issues.jboss.org/browse/ISPN-4442 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CLI > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 7.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-4437) L1 cache is enabled by default in server

by Martin Gencur (JIRA)

[ https://issues.jboss.org/browse/ISPN-4437?page=com.atlassian.jira.plugin.... ] Martin Gencur updated ISPN-4437: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2673 > L1 cache is enabled by default in server > ---------------------------------------- > > Key: ISPN-4437 > URL: https://issues.jboss.org/browse/ISPN-4437 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Server > Affects Versions: 7.0.0.Alpha4 > Reporter: Martin Gencur > Assignee: Martin Gencur > Fix For: 7.0.0.Alpha5 > > > When a distributed cache is used in the server, L1 cache is enabled and the lifespan is 10 mins even if L1 is not configured in standalone.xml file. > This is not an expected behaviour and should be changed. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-4434) Replace Set<Integer> with BitSet in the ConsistentHash interface

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4434?page=com.atlassian.jira.plugin.... ] William Burns commented on ISPN-4434: ------------------------------------- This would also improve performance slightly for the DistributedIterator since it passes along the Set<Integer>. > Replace Set<Integer> with BitSet in the ConsistentHash interface > ---------------------------------------------------------------- > > Key: ISPN-4434 > URL: https://issues.jboss.org/browse/ISPN-4434 > Project: Infinispan > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Core > Affects Versions: 7.0.0.Alpha4 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Minor > Fix For: 7.0.0.Final > > > Memory-wise, BitSet should be more efficient, and iteration should be about the same. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-4441) Improvements on getCacheEntry() synchronization

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-4441: -------------------------------------- Summary: Improvements on getCacheEntry() synchronization Key: ISPN-4441 URL: https://issues.jboss.org/browse/ISPN-4441 Project: Infinispan Issue Type: Enhancement Security Level: Public (Everyone can see) Components: Core Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 7.0.0.Alpha5 - Separate GetKeyValueCommand into two, GetKeyValueCommand and GetCacheEntryCommand to have good separation and avoid conditional logic in GetKeyValueCommand. - As indicated by Pedro in https://github.com/infinispan/infinispan/pull/2671: {quote} I had something simpler in mind. you could invoke create(cacheEntry) that returns a mutable copy. I think it is ok the copy to be mutable, but it you really want it immutable, you can do immutableInternalCacheEntry(create(cacheEntry)) this way you would avoid all the changes in CoreImmutables {quote} - Finally, sort out TODO in documentation of InternalEntryFactory -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-4414) RequestBalancingStrategy nextServer should be evolved in a backwards compatible way

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4414?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-4414: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > RequestBalancingStrategy nextServer should be evolved in a backwards compatible way > ----------------------------------------------------------------------------------- > > Key: ISPN-4414 > URL: https://issues.jboss.org/browse/ISPN-4414 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Remote Protocols > Affects Versions: 7.0.0.Alpha2 > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.0.0.Alpha5 > > > In ISPN-3942, we changed RequestBalancingStrategy's nextServer() to receive a list of failed servers. This could be problematic for end users. Find a better, backwards compatible way to deal with this. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-4440) Remove setMaxCollectorSize API from MapReduceTask

by Vladimir Blagojevic (JIRA)

Vladimir Blagojevic created ISPN-4440: ----------------------------------------- Summary: Remove setMaxCollectorSize API from MapReduceTask Key: ISPN-4440 URL: https://issues.jboss.org/browse/ISPN-4440 Project: Infinispan Issue Type: Task Security Level: Public (Everyone can see) Components: Distributed Execution and Map/Reduce Affects Versions: 7.0.0.Alpha4 Reporter: Vladimir Blagojevic Assignee: Vladimir Blagojevic Priority: Minor During the refinement of parallel execution of M/R algorithm we introduced an abstraction maxCollectorSize on the level of MapReduceTask. The ideas was that during execution of map/combine phase, number of intermediate keys/values collected in a Collector could potentially become very large. By limiting size of collector, intermediate key/values are transferred to intermediate cache in batches before reduce phase is executed and OutOfMemoryError issues are avoided as well. However, during the extensive performance phase Alan Field, Dan Berindei and I have concluded that maxCollectorSize set to 10000 entries gives the best trade off between performance and memory use. Therefore there is no need to expose this value to MapReduceTask users. Having said that there might be some uses cases where holding 10000 intermediate large memory footprint objects might lead to OOM, and in such cases users should allocate more heap to MapReduceTasks. We might consider introducing again this API should such a need arise. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-4439) enhance asynchronous Hot Rod putAllAsync method

by Wolf-Dieter Fink (JIRA)

[ https://issues.jboss.org/browse/ISPN-4439?page=com.atlassian.jira.plugin.... ] Wolf-Dieter Fink updated ISPN-4439: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2672 There are some concerns - client might be overloaded by having too many parallel threads - server might be overloaded as all put operations are parallel - network traffic as each key/value is send with a single remote invocation the performance might be better if the client analyze which server will be the owner and send the entries in chunk's of 10|100? Also it might be worth to have a list of entries which are not processed. > enhance asynchronous Hot Rod putAllAsync method > ------------------------------------------------ > > Key: ISPN-4439 > URL: https://issues.jboss.org/browse/ISPN-4439 > Project: Infinispan > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 7.0.0.Alpha4 > Reporter: Wolf-Dieter Fink > Assignee: Galder Zamarreño > > The current implementation of the method putAllAsync(...) within the Hot Rod client simple use the putAll(...) method which simple iterate over the given Map and use put(...) for each entry synchrounous. > Therefore it takes a longer time to put all entries into the cache. > A simple loop which calls putAsync for each entry has a significant improvement. > i.e. with 100,000 entries the over all duration is 15 times faster -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-4439) enhance asynchronous Hot Rod putAllAsync method

by Wolf-Dieter Fink (JIRA)

[ https://issues.jboss.org/browse/ISPN-4439?page=com.atlassian.jira.plugin.... ] Wolf-Dieter Fink updated ISPN-4439: ----------------------------------- Priority: Minor (was: Major) > enhance asynchronous Hot Rod putAllAsync method > ------------------------------------------------ > > Key: ISPN-4439 > URL: https://issues.jboss.org/browse/ISPN-4439 > Project: Infinispan > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 7.0.0.Alpha4 > Reporter: Wolf-Dieter Fink > Assignee: Galder Zamarreño > Priority: Minor > > The current implementation of the method putAllAsync(...) within the Hot Rod client simple use the putAll(...) method which simple iterate over the given Map and use put(...) for each entry synchrounous. > Therefore it takes a longer time to put all entries into the cache. > A simple loop which calls putAsync for each entry has a significant improvement. > i.e. with 100,000 entries the over all duration is 15 times faster -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years

1
0
0 / 0

[JBoss JIRA] (ISPN-4439) enhance asynchronous Hot Rod putAllAsync method

by Wolf-Dieter Fink (JIRA)

[ https://issues.jboss.org/browse/ISPN-4439?page=com.atlassian.jira.plugin.... ] Wolf-Dieter Fink updated ISPN-4439: ----------------------------------- Assignee: Galder Zamarreño (was: Mircea Markus) > enhance asynchronous Hot Rod putAllAsync method > ------------------------------------------------ > > Key: ISPN-4439 > URL: https://issues.jboss.org/browse/ISPN-4439 > Project: Infinispan > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 7.0.0.Alpha4 > Reporter: Wolf-Dieter Fink > Assignee: Galder Zamarreño > > The current implementation of the method putAllAsync(...) within the Hot Rod client simple use the putAll(...) method which simple iterate over the given Map and use put(...) for each entry synchrounous. > Therefore it takes a longer time to put all entries into the cache. > A simple loop which calls putAsync for each entry has a significant improvement. > i.e. with 100,000 entries the over all duration is 15 times faster -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues June 2014