July 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3112) KeyAffinityService API - provide overload of getKeyForAddress()

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3112?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3112: -------------------------------- Fix Version/s: (was: 6.0.0.Alpha1) > KeyAffinityService API - provide overload of getKeyForAddress() > --------------------------------------------------------------- > > Key: ISPN-3112 > URL: https://issues.jboss.org/browse/ISPN-3112 > Project: Infinispan > Issue Type: Enhancement > Components: Distributed Cache > Affects Versions: 5.3.0.Beta1 > Reporter: Ben Cotton > Assignee: Mircea Markus > Priority: Minor > > Add to the org.inifinispan.affinity.KeyAffinityService<K> interface an overload = > *K getKeyForAddress(Address address, K otherKey);* > //compute address specific version of 'otherKey' -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2575) KeyTransformer registration is required on all nodes of the cluster, in case of custom keys

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2575?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2575: -------------------------------- Fix Version/s: (was: 6.0.0.Alpha1) > KeyTransformer registration is required on all nodes of the cluster, in case of custom keys > ------------------------------------------------------------------------------------------- > > Key: ISPN-2575 > URL: https://issues.jboss.org/browse/ISPN-2575 > Project: Infinispan > Issue Type: Enhancement > Components: Querying > Affects Versions: 5.2.0.Beta5 > Reporter: Anna Manukyan > Assignee: Sanne Grinovero > Attachments: ClusteredCacheTest.java > > > The case is the following: > I have a clustered cache on which I want to perform a search. I'm doing the following: > I'm initializing SearchManager on node1, I'm registering a custom key transformer for my key using the created searchmanager, but then when I'm trying to put data into the cache on node1 (which is in REPL_SYNC mode with cache on node2), I'm getting the exception: > java.lang.IllegalArgumentException: Indexing only works with entries keyed on Strings, primitives and classes that have the @Transformable annotation - you passed in a class org.infinispan.query.test.CustomKey3. Alternatively, see org.infinispan.query.SearchManager#registerKeyTransformer > When I'm initializing the SearchManager using node2 cache and register the keyTransformer on it as well, then everything works perfectly, even though I am not using the second created SearchManager. > The test which reproduces the issue is attached to the jira. Please see the test case: testSearchKeyTransformer() -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1394) Investigate possibility of doing manual rehashing

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1394?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-1394: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > Investigate possibility of doing manual rehashing > ------------------------------------------------- > > Key: ISPN-1394 > URL: https://issues.jboss.org/browse/ISPN-1394 > Project: Infinispan > Issue Type: Feature Request > Components: Distributed Cache > Reporter: Galder Zamarreño > Assignee: Dan Berindei > > Investigate the possibility of being able to do manual rehashing: > - Approach used Dynamo (and Cassandra) > - If you're adding 100 nodes, using manual rehashing could reduce traffic and make it more predictable > - Could be called via JMX > - But removing 10 nodes could be problematic. Unless number of owners is 11 or higher, which will guarantee that at least a copy of data is around -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2505) Java Activation Framework dependency unnessesary

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2505?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2505: -------------------------------- Assignee: Tristan Tarrant (was: Mircea Markus) > Java Activation Framework dependency unnessesary > ------------------------------------------------ > > Key: ISPN-2505 > URL: https://issues.jboss.org/browse/ISPN-2505 > Project: Infinispan > Issue Type: Enhancement > Components: Build process > Affects Versions: 5.2.0.Beta3 > Reporter: Thomas Fromm > Assignee: Tristan Tarrant > Priority: Optional > Fix For: 6.0.0.Final > > > Distribution includes activation.jar. Since ISPN needs JDK6 jaf is already included in JDK and the with ISPN shipped version is anyway an old one. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1409) Introduce a binary-stream upgrading CacheLoader

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1409?page=com.atlassian.jira.plugin.... ] Mircea Markus commented on ISPN-1409: ------------------------------------- protbuff take care of schema evolution so would be simpler to delegate this logic to it and require users that need this behaviour to keep their data serialised through hotrod. > Introduce a binary-stream upgrading CacheLoader > ----------------------------------------------- > > Key: ISPN-1409 > URL: https://issues.jboss.org/browse/ISPN-1409 > Project: Infinispan > Issue Type: Feature Request > Reporter: Sanne Grinovero > Assignee: Manik Surtani > Fix For: 6.0.0.Final > > > We need a CacheLoader decorator able to chain sets of two different Externalizers which are targeting the same Java type to transform from one binary format to the next binary format. > Example: a Person object stored in the cache and an Externalizer is coupled to it. In a new release the Externalizer is changed to provide a different binary representation. Using the old one the stream is transformed from a byte[] to a Person, then this Java instance is feed to the new Externalizer implementation to get the new corresponding byte[]; the updated stream is stored in the decorated CacheLoader so that the nodes going to be attached to the cache store and using the new Externalizer will be fine. > A little complexity is introduced if the cache has to know about different sets of Externalizers if several different types need to be upgraded. A possible solution is to use a single decorator instance for each type, creating a chain of decorators if they are able to pass "as is" each externalizer id they are not directly coupled to. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1409) Introduce a binary-stream upgrading CacheLoader

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1409?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-1409: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > Introduce a binary-stream upgrading CacheLoader > ----------------------------------------------- > > Key: ISPN-1409 > URL: https://issues.jboss.org/browse/ISPN-1409 > Project: Infinispan > Issue Type: Feature Request > Reporter: Sanne Grinovero > Assignee: Manik Surtani > > We need a CacheLoader decorator able to chain sets of two different Externalizers which are targeting the same Java type to transform from one binary format to the next binary format. > Example: a Person object stored in the cache and an Externalizer is coupled to it. In a new release the Externalizer is changed to provide a different binary representation. Using the old one the stream is transformed from a byte[] to a Person, then this Java instance is feed to the new Externalizer implementation to get the new corresponding byte[]; the updated stream is stored in the decorated CacheLoader so that the nodes going to be attached to the cache store and using the new Externalizer will be fine. > A little complexity is introduced if the cache has to know about different sets of Externalizers if several different types need to be upgraded. A possible solution is to use a single decorator instance for each type, creating a chain of decorators if they are able to pass "as is" each externalizer id they are not directly coupled to. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1414) Introduce a builder than can create an Infinispan CacheManager

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1414?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-1414: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > Introduce a builder than can create an Infinispan CacheManager > -------------------------------------------------------------- > > Key: ISPN-1414 > URL: https://issues.jboss.org/browse/ISPN-1414 > Project: Infinispan > Issue Type: Feature Request > Reporter: Pete Muir > Assignee: Manik Surtani > > Provide a builder class that allows passing in of SPI instances, rather than doing lookup. This allows for much easier integration, as context from the app server bootstrap can be easily passed in. > For example: > {code} > public class CacheManagerBuilder { > void setClassLoader(ClassLoader cl); > void setTransport(Transport t); > ... > Cache start(); > } > {code} > We would still want to offer a wrapper around this for Java SE users that would expose a create a CacheManager easily. This factory would want to use a CacheManagerBuilder internally to create the cache, but offer a simplified API. You would want to expose the Builder from the factory as well, offering a sensible set of defaults for SE. > This would break backwards compatibility, as doing new EmbeddedCacheManager etc. would no longer be possible. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1253) Integrate the Tattletale Maven plugin into Infinispan

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1253?page=com.atlassian.jira.plugin.... ] Mircea Markus commented on ISPN-1253: ------------------------------------- I'll let [~NadirX] comment ^^ > Integrate the Tattletale Maven plugin into Infinispan > ----------------------------------------------------- > > Key: ISPN-1253 > URL: https://issues.jboss.org/browse/ISPN-1253 > Project: Infinispan > Issue Type: Task > Components: Build process > Reporter: Navin Surtani > Assignee: Navin Surtani > Priority: Minor > Fix For: 6.0.0.Final > > Original Estimate: 3 days > Remaining Estimate: 3 days > > Make use of the tattletale maven plugin for infinispan. This way there will not be issues similar to ISPN-1234 cropping up. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-928) Interceptor that allows invocations only when cluster is formed of N nodes

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-928?page=com.atlassian.jira.plugin.s... ] Mircea Markus updated ISPN-928: ------------------------------- Fix Version/s: (was: 6.0.0.Final) > Interceptor that allows invocations only when cluster is formed of N nodes > -------------------------------------------------------------------------- > > Key: ISPN-928 > URL: https://issues.jboss.org/browse/ISPN-928 > Project: Infinispan > Issue Type: Feature Request > Components: Configuration, RPC > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Labels: hackathon > > Following from https://github.com/pmuir/infinispan-examples/commit/f5d090092fa7b3660025b... > It'd be great to have an configurable StrictCluster interceptor in Infinispan which would basically make all invocations wait until the cluster of N nodes has been formed. I think it'd be a great addition and would allow clients to verify whether the cluster actually forms without the need to verify whether data replicates...etc. > In principle, the configuration would be at the CacheManager, i.e.: > <transport strictNumMembers="4"... /> > However, it could also be useful to configure it at the cache level. So, could maybe want to do this: I want cache X to allow invocations the moment I have 2 nodes (in spite of the cluster being formed of 4 noes), whereas I want cache Y to allow invocations once I have 3 nodes. > Apart from an strict number of nodes, you could have a minimum number of nodes: allow invocations once I have 4 or more nodes. The strict value could still be useful to make sure intrusive machines don't get into the cluster, i.e. I expect 4 nodes in the cluster and if I have 5, something is wrong. > I think it's an interesting concept that would get rid of cluster validation code in examples and RadarGun. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2590) In case of Errors/Warns/Exceptions include cache name into log/message

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2590?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2590: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > In case of Errors/Warns/Exceptions include cache name into log/message > ---------------------------------------------------------------------- > > Key: ISPN-2590 > URL: https://issues.jboss.org/browse/ISPN-2590 > Project: Infinispan > Issue Type: Enhancement > Components: Locking and Concurrency > Affects Versions: 5.2.0.Beta5 > Reporter: Thomas Fromm > Assignee: Mircea Markus > > When having lots of caches in use and its not always possible to determine the used cache based upon cache key, it would be very useful to have the related cache name inside logs/messages. > For example: > ERROR 05.12.12 20:09:40,589 [OOB-160,IBIS-32523] InvocationContextInterceptor ISPN000136: Execution error > org.infinispan.util.concurrent.TimeoutException: Could not acquire lock on CacheKey{name='Mux234935827442390'} on behalf of transaction GlobalTransaction:<IBIS-15651>:10696:remote. Lock > is being held by null -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 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 July 2013