January 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-1410) Supporting rolling upgrades of a live Hot Rod cluster

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1410?page=com.atlassian.jira.plugin.... ] Mircea Markus resolved ISPN-1410. --------------------------------- Resolution: Done > Supporting rolling upgrades of a live Hot Rod cluster > ----------------------------------------------------- > > Key: ISPN-1410 > URL: https://issues.jboss.org/browse/ISPN-1410 > Project: Infinispan > Issue Type: Feature Request > Affects Versions: 5.0.0.FINAL > Reporter: Sanne Grinovero > Assignee: Tristan Tarrant > Priority: Critical > Fix For: 5.2.0.Final > > > This is an umbrella issue for several pieces need to make sure people will be able to perform a rolling upgrade. > After the depending issues are solved we should add specific tests to perform this. -- 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, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1410) Supporting rolling upgrades of a live Hot Rod cluster

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1410?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-1410: -------------------------------- Fix Version/s: 5.2.0.Final (was: 5.3.0.Final) > Supporting rolling upgrades of a live Hot Rod cluster > ----------------------------------------------------- > > Key: ISPN-1410 > URL: https://issues.jboss.org/browse/ISPN-1410 > Project: Infinispan > Issue Type: Feature Request > Affects Versions: 5.0.0.FINAL > Reporter: Sanne Grinovero > Assignee: Tristan Tarrant > Priority: Critical > Fix For: 5.2.0.Final > > > This is an umbrella issue for several pieces need to make sure people will be able to perform a rolling upgrade. > After the depending issues are solved we should add specific tests to perform this. -- 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, 12 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: 5.3.0.Final (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 > Fix For: 5.3.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, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2281) Enable inter server endpoint communication in a compatibility mode

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2281?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2281: -------------------------------- Fix Version/s: 5.3.0.Final (was: 6.0.0.Final) > Enable inter server endpoint communication in a compatibility mode > ------------------------------------------------------------------ > > Key: ISPN-2281 > URL: https://issues.jboss.org/browse/ISPN-2281 > Project: Infinispan > Issue Type: Feature Request > Components: Remote protocols > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 5.3.0.Final > > > Enable a compatibility mode that allows 3 main servers (Hot Rod, Memcached, REST ) and embedded mode (in-VM) to interact with each other. This would require some compatibility mode. > Obviously, this needs to be testable, so possibly adding tests to the 'integration-tests' module. Need to demonstrate storing data in one “client” and accessing from others, modifying in others, and re-accessing in the first. Test should cover each of the 4 “clients” as the initial creator. > When running in this mode, keys to be stored as Strings. In the case of REST and memcached, keys are strings anyway. In the case of Hot Rod, start the server with a flag to determine the encoding used (assuming the HR client uses Strings as well). > For values - polymorphism between a MarshalledValue (in-VM), MemcachedValue, HotRodValue, RESTValue. Lazily convert from one to the other. May need a PortableValue as well, which contains all of the metadata of all of the value types above. > May need to provide and encoding for values as well - to be able to make sense between Hot Rod byte array values and Strings in REST/memcached (base64?). > In-VM may need registration of an Externalizer? -- 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, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2725) Upgrade to JGroups 3.2.6.Final

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2725?page=com.atlassian.jira.plugin.... ] Mircea Markus resolved ISPN-2725. --------------------------------- Resolution: Done > Upgrade to JGroups 3.2.6.Final > ------------------------------ > > Key: ISPN-2725 > URL: https://issues.jboss.org/browse/ISPN-2725 > Project: Infinispan > Issue Type: Feature Request > Affects Versions: 5.2.0.CR1 > Reporter: Mircea Markus > Assignee: Mircea Markus > Fix For: 5.2.0.CR2, 5.2.0.Final > > -- 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, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1583) AbstractDelegatingAdvancedCache with(ClassLoader), withFlags(Flag...) logic is broken

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1583?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-1583: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > AbstractDelegatingAdvancedCache with(ClassLoader), withFlags(Flag...) logic is broken > ------------------------------------------------------------------------------------- > > Key: ISPN-1583 > URL: https://issues.jboss.org/browse/ISPN-1583 > Project: Infinispan > Issue Type: Bug > Components: Core API > Affects Versions: 5.1.0.BETA5 > Reporter: Paul Ferraro > Assignee: Galder Zamarreño > Fix For: 5.2.0.CR2, 5.2.0.Final > > > When the withFlags(...) logic was modified to use a DecoratedCache instead of thread-local storage, any caches already decorated with the AbstractDelegatingAdvancedCache(...) broke. > Take the following code: > AdvancedCache<K, V> baseCache; > AdvancedCache<K, V> customCache = new AbstractDelegatingAdvancedCache<K, V>(baseCache) { > public void clear() { > // custom clear logic > } > }; > customCache.withFlags(Flag.CACHE_MODE_LOCAL).clear(); > In the above statement, the flag is not applied. > The call to withFlags(...) returns a reference to customCache, and the reference to DecoratedCache containing the flags is lost to garbage collection. > In the case of with(ClassLoader) we have the opposite problem. > customCache.with(customClassLoader).clear(); > In the above statement, the native clear() method is invoked instead of my custom clear() method. with(ClassLoader) returns a reference to DecoratedCache. The clear() method then operates on baseCache, instead of customCache. -- 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, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2725) Upgrade to JGroups 3.2.6.Final

by Mircea Markus (JIRA)

Mircea Markus created ISPN-2725: ----------------------------------- Summary: Upgrade to JGroups 3.2.6.Final Key: ISPN-2725 URL: https://issues.jboss.org/browse/ISPN-2725 Project: Infinispan Issue Type: Feature Request Affects Versions: 5.2.0.CR1 Reporter: Mircea Markus Assignee: Mircea Markus Fix For: 5.2.0.CR2, 5.2.0.Final -- 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, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2721) Issue with conditional operations and verisioning

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2721?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2721: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Issue with conditional operations and verisioning > ------------------------------------------------- > > Key: ISPN-2721 > URL: https://issues.jboss.org/browse/ISPN-2721 > Project: Infinispan > Issue Type: Sub-task > Reporter: Mircea Markus > Assignee: Galder Zamarreño > Fix For: 5.2.0.CR2 > > Attachments: SimpleConditionalOperationsWriteSkewTest.java > > > The problem: > - repeatable read cache with write skew check enabled > - a conditional operation (e.g. replace) executes and is not successful (e.g. because the value doesn't exist) > - during the successful operation the entry is written to the container with a null version. (i.e. the previous version is erased). That is well bad! > Suggested solution: > - for such entries that were not modified (isChanged==false) the value should not be re-written to the container OR > Attached is a unit test capturing the problem. -- 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, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2300) Versioned Transactional Cache issues

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2300?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2300: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Versioned Transactional Cache issues > ------------------------------------ > > Key: ISPN-2300 > URL: https://issues.jboss.org/browse/ISPN-2300 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 5.2.0.Alpha3 > Reporter: Pedro Ruivo > Assignee: Galder Zamarreño > Priority: Critical > Labels: Commands, Conditional, Transactions, Version > Fix For: 5.2.0.CR2, 5.2.0.Final > > > Description from http://lists.jboss.org/pipermail/infinispan-dev/2012-September/011205.html > 1) testPutIfAbsent, testRemoveIfPresent, testReplaceWithOldVal (methods > the test cases) > In this tests, it was updating the cache entry with a null version. This > originates later a IllegalStateException when it tries to perform the > write skew check and the version is null. > I have fixed this problem in this way: if the command fails (PutCommand, > RemoveCommand, ReplaceCommand), I unset the flag CHANGED in the > MvccEntry to avoid to update the entry in the DataContainer. > 2) testClear in distributed mode > I have no clear idea how to solve this problem but it looks like the > PrepareCommand (with the ClearCommand) is not sent to all the nodes in > the cluster. Then, when I do a get, a remote get is performed and the > key is still there. I think that it is not the desired behavior. > 3) testRemoveUnexistingEntry > In this test, it tries to remove a key that does not exists but it does > not success due to a NullPointerException. I have looked deeper and I > check that the transaction's lookup entries map has an entry with [key > => null] and when it tries to perform the write skew check in that key, > a NullPointerException is thrown in here [2] (line 80, WriteSkewHelper) > [1] https://github.com/pruivo/infinispan/tree/t_replace_fix > [2] https://github.com/pruivo/infinispan/blob/t_replace_fix/core/src/main/jav... -- 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, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2578) Two PrepareCommands in parallel cause ConcurrentModificationException

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2578?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2578: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/1584 > Two PrepareCommands in parallel cause ConcurrentModificationException > --------------------------------------------------------------------- > > Key: ISPN-2578 > URL: https://issues.jboss.org/browse/ISPN-2578 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.2.0.Beta5 > Reporter: Radim Vansa > Assignee: Mircea Markus > Priority: Blocker > Fix For: 5.2.0.CR2 > > > Situation: > 1) Node A broadcasts PrepareCommand to nodes B, C > 2) Node A leaves cluster, causing new topology to be installed > 3) The command arrives to B and C, with lower topology than the current one > 4) Both B and C forward the command to node D > 5) D executes the two commands in parallel and finds out that A has left, therefore executing RollbackCommand > In {{AbstractTxLockingInterceptor.visitRollbackCommand}} we call {{LockManagerImpl.unlockAll}} which iterates over the keys and unlocks them. As these two prepares aren't synchronized over the {{lockedKeys}} set, one may unlock and remove these keys while the other is iterating through them, causing {{ConcurrentModificationException}}. -- 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, 12 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues January 2013