February 2015 - infinispan-issues

[JBoss JIRA] (ISPN-1419) Clean up ConfigurationOverrides to match what 5.1 supports

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-1419?page=com.atlassian.jira.plugin.... ] Tristan Tarrant closed ISPN-1419. --------------------------------- Resolution: Out of Date > Clean up ConfigurationOverrides to match what 5.1 supports > ---------------------------------------------------------- > > Key: ISPN-1419 > URL: https://issues.jboss.org/browse/ISPN-1419 > Project: Infinispan > Issue Type: Enhancement > Components: Spring Integration > Affects Versions: 5.1.0.ALPHA2 > Reporter: Marius Bogoevici > Assignee: Marius Bogoevici > > Currently, ConfigurationOverrides is accessing Configuration directly through a series of deprecated methods. Make this fully compatible with Infinispan 5.1 and use FluentConfiguration instead. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-893) Addtional attribute on @CacheEntryCreated to get on pre notifications only

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-893?page=com.atlassian.jira.plugin.s... ] Tristan Tarrant commented on ISPN-893: -------------------------------------- I think event annotations should have an optional "mode" parameter which can be PRE, POST or BOTH (default). > Addtional attribute on @CacheEntryCreated to get on pre notifications only > ----------------------------------------------------------------------------- > > Key: ISPN-893 > URL: https://issues.jboss.org/browse/ISPN-893 > Project: Infinispan > Issue Type: Feature Request > Components: Listeners > Affects Versions: 4.2.1.FINAL > Environment: ALL > Reporter: Sudheer Krishna > Assignee: Manik Surtani > Priority: Minor > Labels: contributor, hackathon > > I may have usescases where i need notifications only when isPre = true. I was expecting a parameter to be taken by @CacheEntryCreated. But this doesnt seem to take any parametres. > Aslo i would like similar values on @CacheEntryremoved also. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-893) Addtional attribute on @CacheEntryCreated to get on pre notifications only

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-893?page=com.atlassian.jira.plugin.s... ] Tristan Tarrant reassigned ISPN-893: ------------------------------------ Assignee: William Burns (was: Manik Surtani) > Addtional attribute on @CacheEntryCreated to get on pre notifications only > ----------------------------------------------------------------------------- > > Key: ISPN-893 > URL: https://issues.jboss.org/browse/ISPN-893 > Project: Infinispan > Issue Type: Feature Request > Components: Listeners > Affects Versions: 4.2.1.FINAL > Environment: ALL > Reporter: Sudheer Krishna > Assignee: William Burns > Priority: Minor > Labels: contributor, hackathon > > I may have usescases where i need notifications only when isPre = true. I was expecting a parameter to be taken by @CacheEntryCreated. But this doesnt seem to take any parametres. > Aslo i would like similar values on @CacheEntryremoved also. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3729) Minimize the number of moved segments for SyncConsistentHashFactory

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3729?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3729: ------------------------------- Description: SyncConsistentHash uses an algorithm that's similar to consistent hashing, but when there is a collision (two nodes map to the same segment), the second node is moved to the next segment. Since the nodes are ordered by their UUID, that means it's possible for a joiner to change the mapping of existing nodes. In order to make the load distribution more even, SyncConsistentHash also uses "virtual nodes": each node actually maps to multiple segments. This makes the number of collisions much higher (and implicitly, the number of extra moved segments). Reading the original [consistent hashing paper|http://thor.cs.ucsb.edu/~ravenben/papers/coreos/kll%2B97.pdf], it looks like the collision handling should be done differently: a joiner should replace an existing node when it's "closer" to the segment boundary, but the existing node should never "lose" segments to another existing node (the property of monotonicity mentioned in the paper). We should investigate whether changing this would allow us to achieve better load balancing by using a much higher number of "virtual nodes" (without moving extra segments). If successful, we could even use SyncConsistentHashFactory as the default hash algorithm. was: SyncConsistentHash uses an algorithm that's similar to consistent hashing, but when there is a collision (two nodes map to the same segment), the second node is moved to the next segment. Since the nodes are ordered by their UUID, that means it's possible for a joiner to change the mapping of existing nodes. In order to make the load distribution more even, SyncConsistentHash also uses "virtual nodes": each node actually maps to multiple segments. This makes the number of collisions much higher (and implicitly, the number of extra moved segments). Reading the original [consistent hashing paper|http://thor.cs.ucsb.edu/~ravenben/papers/coreos/kll%2B97.pdf], it looks like the collision handling should be done differently: a joiner should replace an existing node when it's "closer" to the segment boundary, but the existing node should never "move" to another segment (the property of monotonicity mentioned in the paper). We should investigate whether changing this would allow us to achieve better load balancing by using a much higher number of "virtual nodes" (without moving extra segments). If successful, we could even use SyncConsistentHashFactory as the default hash algorithm. > Minimize the number of moved segments for SyncConsistentHashFactory > ------------------------------------------------------------------- > > Key: ISPN-3729 > URL: https://issues.jboss.org/browse/ISPN-3729 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 6.0.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 7.2.0.Alpha1 > > > SyncConsistentHash uses an algorithm that's similar to consistent hashing, but when there is a collision (two nodes map to the same segment), the second node is moved to the next segment. Since the nodes are ordered by their UUID, that means it's possible for a joiner to change the mapping of existing nodes. > In order to make the load distribution more even, SyncConsistentHash also uses "virtual nodes": each node actually maps to multiple segments. This makes the number of collisions much higher (and implicitly, the number of extra moved segments). > Reading the original [consistent hashing paper|http://thor.cs.ucsb.edu/~ravenben/papers/coreos/kll%2B97.pdf], it looks like the collision handling should be done differently: a joiner should replace an existing node when it's "closer" to the segment boundary, but the existing node should never "lose" segments to another existing node (the property of monotonicity mentioned in the paper). We should investigate whether changing this would allow us to achieve better load balancing by using a much higher number of "virtual nodes" (without moving extra segments). If successful, we could even use SyncConsistentHashFactory as the default hash algorithm. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1239) Graceful shutdown should be supported

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-1239?page=com.atlassian.jira.plugin.... ] Tristan Tarrant closed ISPN-1239. --------------------------------- Fix Version/s: 5.2.0.Final Resolution: Done > Graceful shutdown should be supported > ------------------------------------- > > Key: ISPN-1239 > URL: https://issues.jboss.org/browse/ISPN-1239 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Affects Versions: 5.0.0.FINAL > Reporter: Manik Surtani > Priority: Critical > Labels: clean_shutdown, rehashing > Fix For: 5.2.0.Final > > > Currently, killing any node will result in a rehash. A mechanism for clean shutdown should also be supported, so that a rehash is *not* triggered. Useful when the entire cluster is being intentionally brought down. > Need to think about how we do this; perhaps a LEAVE message that will prevent nodes triggering a rehash when a subsequent view change is detected. This could be done programmatically via a {{clean}} parameter to {{stop()}}, but we should explore alternatives here. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3023) Re-implement BoundedConcurrentHashMap using CHMv8 designs

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3023?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-3023: ---------------------------------- Fix Version/s: 7.2.0.Final > Re-implement BoundedConcurrentHashMap using CHMv8 designs > --------------------------------------------------------- > > Key: ISPN-3023 > URL: https://issues.jboss.org/browse/ISPN-3023 > Project: Infinispan > Issue Type: Feature Request > Components: Core, Eviction > Affects Versions: 5.2.5.Final > Reporter: Manik Surtani > Assignee: William Burns > Priority: Minor > Labels: performance > Fix For: 7.2.0.Final > > > This is better than the current segment-based approach, in terms of memory footprint as well as performance under high concurrency. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3039) Add JCache quickstarts

by Romain Pelisse (JIRA)

[ https://issues.jboss.org/browse/ISPN-3039?page=com.atlassian.jira.plugin.... ] Romain Pelisse updated ISPN-3039: --------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan-quickstart/pull/21 Here is my first stab at a jcache quickstart - let me know what you think is wrong/missing/can be enhance.... > Add JCache quickstarts > ---------------------- > > Key: ISPN-3039 > URL: https://issues.jboss.org/browse/ISPN-3039 > Project: Infinispan > Issue Type: Task > Components: JCache > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > > Quickstarts should be added to https://github.com/infinispan/infinispan-quickstart so that users can get started quickly with JCache API. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5210) Support writing multiple modifications to cache stores in batch when using Transactions

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5210?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5210: ---------------------------------- Fix Version/s: 8.0.0.Final > Support writing multiple modifications to cache stores in batch when using Transactions > --------------------------------------------------------------------------------------- > > Key: ISPN-5210 > URL: https://issues.jboss.org/browse/ISPN-5210 > Project: Infinispan > Issue Type: Feature Request > Components: Loaders and Stores > Affects Versions: 6.0.2.Final, 7.1.0.Final > Reporter: Richard Lucas > Fix For: 8.0.0.Final > > > Currently writes to a cache store are performed individually for each modification to the cache. > While this makes sense when using a non-tx cache it would be beneficial to support writing multiple modifications to a cache store in a single call when using a Tx cache. > Currently all writes are performed in the commit phase and are done by looping through the modifications in the Tx and writing each one in turn to the the store. > Instead of doing this it would useful to pass all modifications to the store in a single call, this would allow: > a) Taking advantage of support for batch updates in underlying stores (JDBC, MongoDB, DynamoDB) for a more efficient write through. > b) Allow store implementations the chance to clean up if one or more updates in the batch fail (this is especially useful if the store does not support Tx and rollbacks as it means the store implementation can at least try to clean up any partial updates it has performed, something which is not currently possible). -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5219) Expose Distributed Iterators over HotRod

by Gustavo Fernandes (JIRA)

Gustavo Fernandes created ISPN-5219: --------------------------------------- Summary: Expose Distributed Iterators over HotRod Key: ISPN-5219 URL: https://issues.jboss.org/browse/ISPN-5219 Project: Infinispan Issue Type: Feature Request Components: Remote Protocols Affects Versions: 7.1.0.Final Reporter: Gustavo Fernandes Integration with external distributed query engines requires de capacity to: * Partition the data * Iterate over each of the partitions The distributed iterators covers that and should be exposed over hotrod Wiki page: https://github.com/infinispan/infinispan/wiki/Remote-Iterator -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1094) Map/Reduce over HotRod

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-1094?page=com.atlassian.jira.plugin.... ] Tristan Tarrant reassigned ISPN-1094: ------------------------------------- Assignee: Tristan Tarrant > Map/Reduce over HotRod > ---------------------- > > Key: ISPN-1094 > URL: https://issues.jboss.org/browse/ISPN-1094 > Project: Infinispan > Issue Type: Feature Request > Components: Distributed Execution and Map/Reduce, Remote Protocols > Affects Versions: 5.0.0.FINAL > Reporter: Galder Zamarreño > Assignee: Tristan Tarrant > Labels: HotRod, Map/Reduce > Fix For: 7.2.0.Final > > > Map/Reduce over HotRod. Most probably we'll settle on portable javascript code to be executable remotely. > More info in the discussion thread. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues February 2015