September 2013 - infinispan-issues

[JBoss JIRA] (ISPN-3449) ReplaceCommand with ignorePrevValue=true does not work on null entries

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3449?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3449: -------------------------------- Priority: Critical (was: Major) > ReplaceCommand with ignorePrevValue=true does not work on null entries > ---------------------------------------------------------------------- > > Key: ISPN-3449 > URL: https://issues.jboss.org/browse/ISPN-3449 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 6.0.0.Alpha3 > Reporter: Radim Vansa > Assignee: Mircea Markus > Priority: Critical > > If ReplaceCommand with ignorePrevValue=true is executed on a backup owner node which has not the entry in the container (for example because the state transfer was not completed yet), the EntryWrappingInterceptor/EntryFactoryImpl won't put it the command's context. Then, in the ReplaceCommand.perform() the entry is not replaced and the command fails. > The command on primary owner succeeds as it does not check whether the responses are successful. -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3449) ReplaceCommand with ignorePrevValue=true does not work on null entries

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3449?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3449: -------------------------------- Fix Version/s: 6.0.0.Beta1 > ReplaceCommand with ignorePrevValue=true does not work on null entries > ---------------------------------------------------------------------- > > Key: ISPN-3449 > URL: https://issues.jboss.org/browse/ISPN-3449 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 6.0.0.Alpha3 > Reporter: Radim Vansa > Assignee: Mircea Markus > Priority: Critical > Fix For: 6.0.0.Beta1 > > > If ReplaceCommand with ignorePrevValue=true is executed on a backup owner node which has not the entry in the container (for example because the state transfer was not completed yet), the EntryWrappingInterceptor/EntryFactoryImpl won't put it the command's context. Then, in the ReplaceCommand.perform() the entry is not replaced and the command fails. > The command on primary owner succeeds as it does not check whether the responses are successful. -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3449) ReplaceCommand with ignorePrevValue=true does not work on null entries

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3449?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3449: -------------------------------- Assignee: Dan Berindei (was: Mircea Markus) > ReplaceCommand with ignorePrevValue=true does not work on null entries > ---------------------------------------------------------------------- > > Key: ISPN-3449 > URL: https://issues.jboss.org/browse/ISPN-3449 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 6.0.0.Alpha3 > Reporter: Radim Vansa > Assignee: Dan Berindei > Priority: Critical > Fix For: 6.0.0.Beta1 > > > If ReplaceCommand with ignorePrevValue=true is executed on a backup owner node which has not the entry in the container (for example because the state transfer was not completed yet), the EntryWrappingInterceptor/EntryFactoryImpl won't put it the command's context. Then, in the ReplaceCommand.perform() the entry is not replaced and the command fails. > The command on primary owner succeeds as it does not check whether the responses are successful. -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3443) WriteCommand may be ignored during state transfer

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3443?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3443: -------------------------------- Fix Version/s: 6.0.0.Beta1 > WriteCommand may be ignored during state transfer > ------------------------------------------------- > > Key: ISPN-3443 > URL: https://issues.jboss.org/browse/ISPN-3443 > Project: Infinispan > Issue Type: Bug > Components: Locking and Concurrency, State transfer > Affects Versions: 6.0.0.Alpha3 > Reporter: Radim Vansa > Assignee: Dan Berindei > Fix For: 6.0.0.Beta1 > > > Distributed sync non-tx cache. > Situation: > 1) A node is joining the cluster, requesting some segment > 2) RemoveCommand is sent to backup owner with ignorePreviousValue=true > 3) It looks up the entry and finds null > 4) State transfer invokes the PutKeyValueCommand and sets the value for removed entry (updateKeys has not the key yet) > 5) RemoveCommand adds its key to updateKeys set, but it does not remove the value as it is already null (in its context) > Result: the value is removed on primary but on backup this is still present -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3443) WriteCommand may be ignored during state transfer

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3443?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3443: -------------------------------- Priority: Critical (was: Major) > WriteCommand may be ignored during state transfer > ------------------------------------------------- > > Key: ISPN-3443 > URL: https://issues.jboss.org/browse/ISPN-3443 > Project: Infinispan > Issue Type: Bug > Components: Locking and Concurrency, State transfer > Affects Versions: 6.0.0.Alpha3 > Reporter: Radim Vansa > Assignee: Dan Berindei > Priority: Critical > Fix For: 6.0.0.Beta1 > > > Distributed sync non-tx cache. > Situation: > 1) A node is joining the cluster, requesting some segment > 2) RemoveCommand is sent to backup owner with ignorePreviousValue=true > 3) It looks up the entry and finds null > 4) State transfer invokes the PutKeyValueCommand and sets the value for removed entry (updateKeys has not the key yet) > 5) RemoveCommand adds its key to updateKeys set, but it does not remove the value as it is already null (in its context) > Result: the value is removed on primary but on backup this is still present -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3430) Different CacheEntryEvents fired in library mode and compatibility mode

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3430?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-3430: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Different CacheEntryEvents fired in library mode and compatibility mode > ----------------------------------------------------------------------- > > Key: ISPN-3430 > URL: https://issues.jboss.org/browse/ISPN-3430 > Project: Infinispan > Issue Type: Bug > Components: Listeners, Remote protocols > Affects Versions: 5.3.0.Final, 6.0.0.Alpha2 > Reporter: Jiří Holuša > Assignee: Galder Zamarreño > Fix For: 6.0.0.Beta1, 6.0.0.Final > > > According to org.infinispan.notifications.cachelistener.CustomClassLoaderListenerTest.testCustomClassLoaderListener() there are fired events like this in library mode: > on replace() method: CacheEntryModifiedEvent > But I tested this feature in compatibility mode (run methods on remote cache and listener bound to embedded cache) and it fires events like this: > on replace() method: CacheEntryModifiedEvent, CacheEntryVisitedEvent > Also tested remote caches via Rest and Memcached. All three ways (HotRod, Rest, Memcached) contains this inconsistency on replace() method. In addition, when operating via Rest, on modifying existing entry via put method, it fires CacheEntryVisitedEvent, which is inconsistent even with the other remote caches. > I further explored the test CustomClassLoaderListenerTest and found another bug + bug in the test > The test comments are confusing because they are not right. Unfortunately there are two unconsidered event fires and because of the simple final assertion, it went +1 unconsidered event and -1 "over"considered event, so the test passes. > Summary, > In library mode, method remove() fires (correctly) only CacheEntryRemoveEvent, not also CacheEntryModifiedEvent as it say comment in that test. > Secondly, calling get() on key which was previously evicted (using evict()) fires (incorrectly) also CacheEntryModifiedEvent. > This is the +1/-1 thing I was talking about. > The difference in replace() method between library and compatibility mode remains. > I've pulled request with tests for these things. > Also I've noticed that when calling replace() containing the same value as it was before calling it (so no change to the value), the CacheEntryModifiedEvent is still fired, but maybe this is a feature, maybe a bug. -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2637) Supporting rolling upgrades of a live REST cluster

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-2637?page=com.atlassian.jira.plugin.... ] Tristan Tarrant resolved ISPN-2637. ----------------------------------- Resolution: Done This has been resolved primarily bu ISPN-3018 (and related issues) > Supporting rolling upgrades of a live REST cluster > --------------------------------------------------- > > Key: ISPN-2637 > URL: https://issues.jboss.org/browse/ISPN-2637 > Project: Infinispan > Issue Type: Feature Request > Reporter: Mircea Markus > Assignee: Tristan Tarrant > Priority: Blocker > Labels: jdg62, rolling_upgrade > Fix For: 6.0.0.Beta1, 6.0.0.Final > > > Similar to ISPN-1410, but for REST clusters. -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3436) Not working RemoteManager.getBulk() and keySet() in compatibility mode

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3436?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-3436: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Not working RemoteManager.getBulk() and keySet() in compatibility mode > ---------------------------------------------------------------------- > > Key: ISPN-3436 > URL: https://issues.jboss.org/browse/ISPN-3436 > Project: Infinispan > Issue Type: Bug > Components: Remote protocols > Affects Versions: 6.0.0.Alpha3 > Reporter: Jiří Holuša > Assignee: Galder Zamarreño > Fix For: 6.0.0.Beta1, 6.0.0.Final > > > When using HotRod client in compatibility mode, when trying to put entries via embedded cache and afterwards call RemoteCache.getBulk() or RemoteCache.keySet(), an exception is thrown. Exception is thrown in all cache modes (LOCAL, REPL, DIST). > {code:borderStyle=solid} > org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for message id[3] returned server error (status=0x85): java.lang.ClassCastException: java.lang.Integer cannot be cast to [B > at org.infinispan.client.hotrod.impl.protocol.Codec10.checkForErrorsInResponseStatus(Codec10.java:143) > at org.infinispan.client.hotrod.impl.protocol.Codec10.readHeader(Codec10.java:99) > at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:56) > ... > {code} > Code that did it: > {code:title=EmbeddedHotRodBulkTest.java|borderStyle=solid} > public void testEmbeddedPutHotRodGetBulk() { > Cache<Integer, Integer> embedded = cacheFactory.getEmbeddedCache(); > RemoteCache<Integer, Integer> remote = cacheFactory.getHotRodCache(); > populateCacheManager(embedded); > Map<Integer, Integer> get = remote.getBulk(); > assertEquals(100, get.size()); > for(int i = 0; i < 100; i++) { > assertTrue(get.containsValue(i)); > assertTrue(get.containsKey(i)); > } > } > {code} -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3467) Remove support for strictPeerToPeer = true

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3467?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3467: ------------------------------- Description: Setting {{transport.strictPeerToPeer = true}} doesn't really do anything with dist caches with L1 disabled, as commands are replicated only to members of the cache. With L1 enabled, writes/txs may or may not fail, depending on if there are any L1 requestors for the modified keys and on the value of {{clustering.l1.invalidationThreshold}} - unpredictable, so more harmful than useful. With repl caches, the setting does work as advertised: even if the cache topology contains only the nodes with the cache running, the writes/txs are sent to all the nodes in the cluster, and they will fail if the cache is not running on one of them. On the other hand, in order to retry the operation, the users would have to wait for the cache's topology to contain all the nodes in the cluster - so if they need to ensure that a cache is present on all the nodes in the cluster, they could check that {{RpcManager.getMembers().equals(Transport.getMembers()}} directly. So we should remove the {{transport.strictPeerToPeer}} setting, although we could mark it as deprecated and log a warning for the time being. was: The {{transport.strictPeerToPeer}} setting doesn't really do anything with dist caches with L1 disabled, as commands are replicated only to members of the cache. With L1 enabled, writes/txs may or may not fail, depending on if there are any L1 requestors for the modified keys and on the value of {{clustering.l1.invalidationThreshold}} - unpredictable, so more harmful than useful. With repl caches, the setting does work as advertised: even if the cache topology contains only the nodes with the cache running, the writes/txs are sent to all the nodes in the cluster, and they will fail if the cache is not running on one of them. On the other hand, in order to retry the operation, the users would have to wait for the cache's topology to contain all the nodes in the cluster - so if they need to ensure that a cache is present on all the nodes in the cluster, they could check that {{RpcManager.getMembers().equals(Transport.getMembers()}} directly. > Remove support for strictPeerToPeer = true > ------------------------------------------ > > Key: ISPN-3467 > URL: https://issues.jboss.org/browse/ISPN-3467 > Project: Infinispan > Issue Type: Task > Components: Configuration, RPC, Server > Affects Versions: 6.0.0.Alpha3 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 6.0.0.Beta2, 6.0.0.Final > > > Setting {{transport.strictPeerToPeer = true}} doesn't really do anything with dist caches with L1 disabled, as commands are replicated only to members of the cache. With L1 enabled, writes/txs may or may not fail, depending on if there are any L1 requestors for the modified keys and on the value of {{clustering.l1.invalidationThreshold}} - unpredictable, so more harmful than useful. > With repl caches, the setting does work as advertised: even if the cache topology contains only the nodes with the cache running, the writes/txs are sent to all the nodes in the cluster, and they will fail if the cache is not running on one of them. On the other hand, in order to retry the operation, the users would have to wait for the cache's topology to contain all the nodes in the cluster - so if they need to ensure that a cache is present on all the nodes in the cluster, they could check that {{RpcManager.getMembers().equals(Transport.getMembers()}} directly. > So we should remove the {{transport.strictPeerToPeer}} setting, although we could mark it as deprecated and log a warning for the time being. -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3327) Server init.d script should be customized for Infinispan

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3327?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-3327: ----------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 6.0.0.Beta1 Resolution: Done > Server init.d script should be customized for Infinispan > -------------------------------------------------------- > > Key: ISPN-3327 > URL: https://issues.jboss.org/browse/ISPN-3327 > Project: Infinispan > Issue Type: Bug > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 6.0.0.Beta1 > > > The current init.d script included in Infinispan Server should be appropriately renamed and verified -- 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, 4 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues September 2013