[JBoss JIRA] (ISPN-3468) ClassCastException in map-reduce with unfamiliar key type, some cache stores and storeAsBinary
by Krzysztof Sobolewski (JIRA)
Krzysztof Sobolewski created ISPN-3468:
------------------------------------------
Summary: ClassCastException in map-reduce with unfamiliar key type, some cache stores and storeAsBinary
Key: ISPN-3468
URL: https://issues.jboss.org/browse/ISPN-3468
Project: Infinispan
Issue Type: Bug
Components: Loaders and Stores
Affects Versions: 5.3.0.Final
Reporter: Krzysztof Sobolewski
Assignee: Mircea Markus
The conditions needed to replicate:
1) storeAsBinary enabled for keys
2) a cache store that marshals keys directly, e.g. any BucketBasedCacheStore (I'm using JdbcBinaryCacheStore)
3) a key type that is unfamiliar to MarshalledValue.isTypeExcluded(Class<?>)
If these are satisfied, then map-reduce fails with an exception like this:
org.infinispan.CacheException: java.util.concurrent.ExecutionException: java.lang.ClassCastException: org.infinispan.marshall.MarshalledValue cannot be cast to com.example.UnfamiliarKeyType
at com.example.TestMapper.map(TestMapper.java:11) ~[?:?]
at org.infinispan.distexec.mapreduce.MapReduceManagerImpl.map(MapReduceManagerImpl.java:216) ~[?:?]
at org.infinispan.distexec.mapreduce.MapReduceManagerImpl.mapAndCombineForLocalReduction(MapReduceManagerImpl.java:103) ~[?:?]
at org.infinispan.distexec.mapreduce.MapReduceTask$MapTaskPart.invokeMapCombineLocallyForLocalReduction(MapReduceTask.java:977) ~[?:?]
at org.infinispan.distexec.mapreduce.MapReduceTask$MapTaskPart.access$300(MapReduceTask.java:916) ~[?:?]
at org.infinispan.distexec.mapreduce.MapReduceTask$MapTaskPart$2.call(MapReduceTask.java:948) ~[?:?]
at org.infinispan.distexec.mapreduce.MapReduceTask$MapTaskPart$2.call(MapReduceTask.java:944) ~[?:?]
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) ~[?:1.6.0_45]
at java.util.concurrent.FutureTask.run(FutureTask.java:138) ~[?:1.6.0_45]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439) ~[?:1.6.0_45]
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) ~[?:1.6.0_45]
at java.util.concurrent.FutureTask.run(FutureTask.java:138) ~[?:1.6.0_45]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) ~[?:1.6.0_45]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) ~[?:1.6.0_45]
--
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, 3 months
[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
12 years, 3 months
[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
12 years, 3 months
[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
12 years, 3 months
[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
12 years, 3 months
[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
12 years, 3 months
[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
12 years, 3 months
[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
12 years, 3 months
[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
12 years, 3 months