April 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-2587) Optimize command forwarding after topology changes

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2587?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2587: -------------------------------- Fix Version/s: 6.0.0.Final (was: 5.3.0.Final) > Optimize command forwarding after topology changes > -------------------------------------------------- > > Key: ISPN-2587 > URL: https://issues.jboss.org/browse/ISPN-2587 > Project: Infinispan > Issue Type: Task > Components: State transfer > Affects Versions: 5.2.0.Beta5 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 6.0.0.Final > > > When a node receives a command with a topology id lower than its own topology id, it forwards the command to all the owners in the current topology. > This is especially bad in replicated caches, where all the nodes check whether to forward or not, and after a join we may get {{n * (n-1)}} forwarded commands instead of just {{n}}. > Most of the time the difference between the current topology id and the command's topology id is <= 1, so we could avoid a lot of the extra forwarding if we kept the previous cache topology and we forwarded the command only to the owners added in the latest topology. Obviously, if the command is older we'd still forward it to all the owners. -- 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

11 years, 2 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: 6.0.0.Final (was: 5.3.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 > 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2634) Implement cross-site replication based on I-RAC (Reliably Asynchronous Clustering)

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2634?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2634: -------------------------------- Fix Version/s: 6.0.0.Final (was: 5.3.0.Final) > Implement cross-site replication based on I-RAC (Reliably Asynchronous Clustering) > ---------------------------------------------------------------------------------- > > Key: ISPN-2634 > URL: https://issues.jboss.org/browse/ISPN-2634 > Project: Infinispan > Issue Type: Feature Request > Components: Cross-Site Replication > Reporter: Mircea Markus > Assignee: Erik Salter > Fix For: 6.0.0.Final > > > As described here: https://community.jboss.org/wiki/RAC -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2724) L1 is not used for write-operations (for node affine keys)

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2724?page=com.atlassian.jira.plugin.... ] Mircea Markus commented on ISPN-2724: ------------------------------------- Reducing priority as it only relates to performance in a very specific scenario. > L1 is not used for write-operations (for node affine keys) > ---------------------------------------------------------- > > Key: ISPN-2724 > URL: https://issues.jboss.org/browse/ISPN-2724 > Project: Infinispan > Issue Type: Bug > Components: Distributed Execution and Map/Reduce > Affects Versions: 5.2.0.CR1 > Reporter: Thomas Fromm > Assignee: Mircea Markus > Priority: Minor > Fix For: 6.0.0.Final > > Attachments: L1WriteTest.java > > > I need to make sure, that a key written on a node is present in L1, even when the owner is a different node. > Attached an example which shows the expected behaviour. -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2724) L1 is not used for write-operations (for node affine keys)

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2724?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2724: -------------------------------- Priority: Minor (was: Major) > L1 is not used for write-operations (for node affine keys) > ---------------------------------------------------------- > > Key: ISPN-2724 > URL: https://issues.jboss.org/browse/ISPN-2724 > Project: Infinispan > Issue Type: Bug > Components: Distributed Execution and Map/Reduce > Affects Versions: 5.2.0.CR1 > Reporter: Thomas Fromm > Assignee: Mircea Markus > Priority: Minor > Fix For: 5.3.0.Final > > Attachments: L1WriteTest.java > > > I need to make sure, that a key written on a node is present in L1, even when the owner is a different node. > Attached an example which shows the expected behaviour. -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2724) L1 is not used for write-operations (for node affine keys)

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2724?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2724: -------------------------------- Fix Version/s: 6.0.0.Final (was: 5.3.0.Final) > L1 is not used for write-operations (for node affine keys) > ---------------------------------------------------------- > > Key: ISPN-2724 > URL: https://issues.jboss.org/browse/ISPN-2724 > Project: Infinispan > Issue Type: Bug > Components: Distributed Execution and Map/Reduce > Affects Versions: 5.2.0.CR1 > Reporter: Thomas Fromm > Assignee: Mircea Markus > Priority: Minor > Fix For: 6.0.0.Final > > Attachments: L1WriteTest.java > > > I need to make sure, that a key written on a node is present in L1, even when the owner is a different node. > Attached an example which shows the expected behaviour. -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-375) Enable Hot Rod clients to start transactions

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-375?page=com.atlassian.jira.plugin.s... ] Mircea Markus updated ISPN-375: ------------------------------- Fix Version/s: (was: 5.3.0.Beta1) > Enable Hot Rod clients to start transactions > -------------------------------------------- > > Key: ISPN-375 > URL: https://issues.jboss.org/browse/ISPN-375 > Project: Infinispan > Issue Type: Feature Request > Components: Remote protocols > Reporter: Galder Zamarreño > Assignee: Michael Musgrove > Priority: Blocker > Labels: hackathon > Fix For: 5.3.0.Final > > > It might be useful to allow Hot Rod clients to start transactions within Hot Rod servers. The possibility of clients participating in the actual transaction, i.e. being an XAResource, should not be imposed since this might be less than trivial to achieve in non-Java environments. The alternative would be to allow clients to start Hot Rod server local transactions only. > This would require enhancing Hot Rod spec to have some begin/commit/rollback commands that return a tx id, and for clients to be able to send this id as part of each command that should participate in the transaction. > Pitfalls to avoid include avoiding a transaction to be propagated over several Hot Rod servers. IOW, to simplify things, if a tx is started in server A, all ops within that tx should be directed to tx. Load balancing could still happen but would need to be tx sticky. -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1345) Dirty reads may occurs on mutable objects

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1345?page=com.atlassian.jira.plugin.... ] Mircea Markus commented on ISPN-1345: ------------------------------------- [~manik]storeAsBinary should really solve the issue (at least without L1 enabled) the value is de-serialized on each read. > Dirty reads may occurs on mutable objects > ----------------------------------------- > > Key: ISPN-1345 > URL: https://issues.jboss.org/browse/ISPN-1345 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 5.0.0.FINAL > Environment: Windows Java 1.6.0_26 > Reporter: Christophe Labouisse > Assignee: Manik Surtani > Priority: Critical > Fix For: 5.3.0.Final > > > In local mode, I create a cache like this: > {code} > cacheManager = new DefaultCacheManager(); > cacheManager.getDefaultConfiguration().fluent().storeAsBinary().transaction().cacheStopTimeout(5000); > final Configuration config = new Configuration().fluent().transactionManagerLookup(this.tmLookup).locking() > .isolationLevel(IsolationLevel.READ_COMMITED).build(); > this.cacheManager.defineConfiguration("Gruik", config); > this.cache = this.cacheManager.getCache("Gruik"); > {code} > When retrieving data using {{cache.get(_key_)}} I find out that Infinispan returns the object instance actually stored in the cache datastore. This is OK when the inserted objects are immutable but fails to achieve isolation when using mutable objects. > For instance on a simple Pojo with a {{get/setValue}}. > ||Step||Reader||Writer|| > |1|Starts transaction| | > |2|{{value = cache.get(KEY);}}| | > |3|{{System.out.println(value.getValue());}} Prints 42| | > |4| |Starts transaction| > |5| |{{value = cache.get(KEY);}} Same instance than step 2| > |6| |{{value.setValue(666); // Prepare update}}| > |7|{{System.out.println(value.getValue());}} Prints 666 !| | > |8|{{value = cache.get(KEY);}} Same instance than step 2| | > |9| |{{cache.put(KEY,value);}}| > |10| |Commits transaction| > |11|{{value = cache.get(KEY);}} Same instance than step 2| | > |12|{{System.out.println(value.getValue());}} Prints 666| | > |13|Commits transaction| | > According to the READ_COMMITTED specification, the value printed on step 7 should be 42 as the change to 666 is not committed yet. -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2331) Add documentation describing rolling upgrades of a live cluster

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2331?page=com.atlassian.jira.plugin.... ] Mircea Markus resolved ISPN-2331. --------------------------------- Resolution: Done https://docs.jboss.org/author/display/ISPN/Rolling+upgrades > Add documentation describing rolling upgrades of a live cluster > --------------------------------------------------------------- > > Key: ISPN-2331 > URL: https://issues.jboss.org/browse/ISPN-2331 > Project: Infinispan > Issue Type: Sub-task > Reporter: Mircea Markus > Assignee: Manik Surtani > Priority: Critical > Labels: documentation > Fix For: 5.3.0.Final > > > Once the issues under ISPN-1410 are resolved we should add a user manual page describing how rolling upgrades can be performed. A video with a demo would also be awesome :-) -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2806) Add a more efficient FileCacheStore implementation

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2806?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2806: -------------------------------- Fix Version/s: 6.0.0.Final (was: 5.3.0.Final) > Add a more efficient FileCacheStore implementation > -------------------------------------------------- > > Key: ISPN-2806 > URL: https://issues.jboss.org/browse/ISPN-2806 > Project: Infinispan > Issue Type: Feature Request > Components: Loaders and Stores > Reporter: Mircea Markus > Assignee: Dan Berindei > Priority: Critical > Fix For: 6.0.0.Final > > > Based on the feedback we got from community/users Infinispan needs a more efficient FileCacheStore implementation. See the [design document|https://community.jboss.org/wiki/FileCacheStoreRedesign] that contains several suggestion of implementing it. It would be nice to also have a benchmark written in order to evaluate the performance between various implementation suggestion. -- 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

11 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues April 2013