[JBoss JIRA] (ISPN-7820) Document store-by-reference effects in functional commands
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-7820?page=com.atlassian.jira.plugin.... ]
Radim Vansa updated ISPN-7820:
------------------------------
Summary: Document store-by-reference effects in functional commands (was: Uncommitted functional command modifies value)
> Document store-by-reference effects in functional commands
> ----------------------------------------------------------
>
> Key: ISPN-7820
> URL: https://issues.jboss.org/browse/ISPN-7820
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Test Suite - Core, Transactions
> Affects Versions: 9.0.0.Final
> Reporter: Radim Vansa
> Assignee: Radim Vansa
>
> In transactional mode, functional read write command loads the value into the context without making a defensive copy. Then, the function is applied directly on that value, exposing uncommitted changes to all other threads. Rollback is ineffective, the value is already changed.
> There are no tests for rollback in FunctionalTxInMemoryTest.
> Reproducer:
> {code:java}
> @Test
> public void testValueInContextIsACopy() throws Exception {
> Object key = getKeyForCache(cache(0, DIST), cache(1, DIST));
> cache(0, DIST).put(key, new ArrayList());
> tm.begin();
> // nasty cast
> FunctionalMap.ReadWriteMap<Object, List> otherRw = (FunctionalMap.ReadWriteMap) rw;
> otherRw.eval(key, (Serializable & Function<EntryView.ReadWriteEntryView<Object, List>, Object>) view -> {
> List list = view.get();
> list.add("woohoo");
> view.set(list);
> return null;
> }).join();
> tm.rollback();
> assertEquals(new ArrayList(), cache(0, DIST).get(key));
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (ISPN-7820) Uncommitted functional command modifies value
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-7820?page=com.atlassian.jira.plugin.... ]
Radim Vansa commented on ISPN-7820:
-----------------------------------
In fact this has to be handled in user code and we should just add a warning to the docs; both to functional API and to compute*. Otherwise, we would have to create a defensive copy even for reads (because we can't guarantee that the should-be-read-only function won't access the value in modifying way) and that would result in excessive overhead.
> Uncommitted functional command modifies value
> ---------------------------------------------
>
> Key: ISPN-7820
> URL: https://issues.jboss.org/browse/ISPN-7820
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Test Suite - Core, Transactions
> Affects Versions: 9.0.0.Final
> Reporter: Radim Vansa
> Assignee: Radim Vansa
>
> In transactional mode, functional read write command loads the value into the context without making a defensive copy. Then, the function is applied directly on that value, exposing uncommitted changes to all other threads. Rollback is ineffective, the value is already changed.
> There are no tests for rollback in FunctionalTxInMemoryTest.
> Reproducer:
> {code:java}
> @Test
> public void testValueInContextIsACopy() throws Exception {
> Object key = getKeyForCache(cache(0, DIST), cache(1, DIST));
> cache(0, DIST).put(key, new ArrayList());
> tm.begin();
> // nasty cast
> FunctionalMap.ReadWriteMap<Object, List> otherRw = (FunctionalMap.ReadWriteMap) rw;
> otherRw.eval(key, (Serializable & Function<EntryView.ReadWriteEntryView<Object, List>, Object>) view -> {
> List list = view.get();
> list.add("woohoo");
> view.set(list);
> return null;
> }).join();
> tm.rollback();
> assertEquals(new ArrayList(), cache(0, DIST).get(key));
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (ISPN-7820) Uncommitted functional command modifies value
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-7820?page=com.atlassian.jira.plugin.... ]
Radim Vansa updated ISPN-7820:
------------------------------
Description:
In transactional mode, functional read write command loads the value into the context without making a defensive copy. Then, the function is applied directly on that value, exposing uncommitted changes to all other threads. Rollback is ineffective, the value is already changed.
There are no tests for rollback in FunctionalTxInMemoryTest.
Reproducer:
{code:java}
@Test
public void testValueInContextIsACopy() throws Exception {
Object key = getKeyForCache(cache(0, DIST), cache(1, DIST));
cache(0, DIST).put(key, new ArrayList());
tm.begin();
// nasty cast
FunctionalMap.ReadWriteMap<Object, List> otherRw = (FunctionalMap.ReadWriteMap) rw;
otherRw.eval(key, (Serializable & Function<EntryView.ReadWriteEntryView<Object, List>, Object>) view -> {
List list = view.get();
list.add("woohoo");
view.set(list);
return null;
}).join();
tm.rollback();
assertEquals(new ArrayList(), cache(0, DIST).get(key));
}
{code}
was:
In transactional mode, functional read write command loads the value into the context without making a defensive copy. Then, the function is applied directly on that value, exposing uncommitted changes to all other threads. Rollback is ineffective, the value is already changed.
There are no tests for rollback in FunctionalTxInMemoryTest.
> Uncommitted functional command modifies value
> ---------------------------------------------
>
> Key: ISPN-7820
> URL: https://issues.jboss.org/browse/ISPN-7820
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Test Suite - Core, Transactions
> Affects Versions: 9.0.0.Final
> Reporter: Radim Vansa
> Assignee: Radim Vansa
>
> In transactional mode, functional read write command loads the value into the context without making a defensive copy. Then, the function is applied directly on that value, exposing uncommitted changes to all other threads. Rollback is ineffective, the value is already changed.
> There are no tests for rollback in FunctionalTxInMemoryTest.
> Reproducer:
> {code:java}
> @Test
> public void testValueInContextIsACopy() throws Exception {
> Object key = getKeyForCache(cache(0, DIST), cache(1, DIST));
> cache(0, DIST).put(key, new ArrayList());
> tm.begin();
> // nasty cast
> FunctionalMap.ReadWriteMap<Object, List> otherRw = (FunctionalMap.ReadWriteMap) rw;
> otherRw.eval(key, (Serializable & Function<EntryView.ReadWriteEntryView<Object, List>, Object>) view -> {
> List list = view.get();
> list.add("woohoo");
> view.set(list);
> return null;
> }).join();
> tm.rollback();
> assertEquals(new ArrayList(), cache(0, DIST).get(key));
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (ISPN-7820) Uncommitted functional command modifies value
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-7820?page=com.atlassian.jira.plugin.... ]
Radim Vansa commented on ISPN-7820:
-----------------------------------
[~karesti] Hi Katia, please check this out - I think that the same problem will apply to compute et al., too.
> Uncommitted functional command modifies value
> ---------------------------------------------
>
> Key: ISPN-7820
> URL: https://issues.jboss.org/browse/ISPN-7820
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Test Suite - Core, Transactions
> Affects Versions: 9.0.0.Final
> Reporter: Radim Vansa
> Assignee: Radim Vansa
>
> In transactional mode, functional read write command loads the value into the context without making a defensive copy. Then, the function is applied directly on that value, exposing uncommitted changes to all other threads. Rollback is ineffective, the value is already changed.
> There are no tests for rollback in FunctionalTxInMemoryTest.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (ISPN-7820) Uncommitted functional command modifies value
by Radim Vansa (JIRA)
Radim Vansa created ISPN-7820:
---------------------------------
Summary: Uncommitted functional command modifies value
Key: ISPN-7820
URL: https://issues.jboss.org/browse/ISPN-7820
Project: Infinispan
Issue Type: Bug
Components: Core, Test Suite - Core, Transactions
Affects Versions: 9.0.0.Final
Reporter: Radim Vansa
Assignee: Radim Vansa
In transactional mode, functional read write command loads the value into the context without making a defensive copy. Then, the function is applied directly on that value, exposing uncommitted changes to all other threads. Rollback is ineffective, the value is already changed.
There are no tests for rollback in FunctionalTxInMemoryTest.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (ISPN-7801) RehashWithL1Test.testPutWithRehashAndCacheClear random failures
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-7801?page=com.atlassian.jira.plugin.... ]
Radim Vansa commented on ISPN-7801:
-----------------------------------
[~dan.berindei] Thinking about this 'additional logic', the readCH/writeCH semantics is still imperfect. During the RNWA phase it is possible to ignore a write locally if this node is the old owner (and not a new owner), because there's no way to retrieve that value. However, you have to address the write to the other old owners. So it should be:
READ_OLD_WRITE_ALL
READ_ALL_WRITE_ALL
READ_NEW_WRITE_ALL_REMOTE_NEW_LOCAL.
Sounds like in case that in {{NonTxDI.handleNonTxWriteCommand}} if {{entry == null}} and we're not on originator, you should just silently return success. Not sure what you'll break, though :)
> RehashWithL1Test.testPutWithRehashAndCacheClear random failures
> ---------------------------------------------------------------
>
> Key: ISPN-7801
> URL: https://issues.jboss.org/browse/ISPN-7801
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 9.0.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Labels: testsuite_stability
> Fix For: 9.1.0.Final
>
>
> The test kills the only owner of a key and checks that when a node starts owning an L1 entry, it doesn't send it to other nodes during state transfer. Then it adds a new node (owning the key) and checks that the key isn't transferred to the new node, and it's deleted from L1 on the old nodes. The problem is that it doesn't wait, it assumes all the nodes have already removed it by the time {{getCache()}} returns on the joiner.
> {noformat}
> 03:24:27,606 TRACE (jgroups-5,Test-NodeB-54331:[]) [L1WriteSynchronizer] Caching remotely retrieved entry for key k0 in L1
> 03:24:27,607 TRACE (jgroups-5,Test-NodeB-54331:[]) [DefaultDataContainer] Store MortalCacheEntry{key=k0, value=some data} in container
> 03:24:26,754 DEBUG (testng-Test:[]) [Test] Populating L1 on Test-NodeA-2588
> 03:24:27,514 DEBUG (testng-Test:[]) [Test] Populating L1 on Test-NodeB-54331
> 03:24:27,777 DEBUG (testng-Test:[]) [Test] Populating L1 on Test-NodeC-65326
> 03:24:27,777 DEBUG (testng-Test:[]) [Test] Killing node Test-NodeC-65326
> 03:24:27,781 TRACE (transport-thread-Test-NodeA-p51-t2:[Topology-___defaultcache]) [DefaultDataContainer] Removed MortalCacheEntry{key=k0, value=some data} from container
> *** The entry is not removed from NodeB at this point
> 03:24:27,936 DEBUG (testng-Test:[]) [Test] Checking values on Test-NodeA-2588
> 03:24:27,998 TRACE (jgroups-5,Test-NodeB-54331:[]) [CommandAwareRpcDispatcher] About to send back response SuccessfulResponse{responseValue=MortalCacheValue{value=some data, lifespan=600000, created=1493943867607}} for command ClusteredGetCommand{key=k0, flags=[]}
> 03:24:28,034 TRACE (jgroups-7,Test-NodeA-2588:[]) [L1WriteSynchronizer] Caching remotely retrieved entry for key k0 in L1
> 03:24:28,044 TRACE (jgroups-7,Test-NodeA-2588:[]) [DefaultDataContainer] Store MortalCacheEntry{key=k0, value=some data} in container
> 03:24:28,519 DEBUG (testng-Test:[]) [Test] Checking values on Test-NodeB-54331
> 03:24:28,595 DEBUG (testng-Test:[]) [Test] Starting a new joiner
> 03:24:30,261 TRACE (transport-thread-Test-NodeA-p51-t6:[Topology-___defaultcache]) [InvocationContextInterceptor] Invoked with command InvalidateCommand{keys=[k0, k1, k2, k3, k4, k5, k6, k7, k8, k9]} and InvocationContext [org.infinispan.context.impl.NonTxInvocationContext@54c5cc1d]
> 03:24:30,292 DEBUG (testng-Test:[]) [Test] Checking values on Test-NodeA-2588
> 03:24:30,355 ERROR (testng-Test:[]) [TestSuiteProgress] Test failed: org.infinispan.distribution.rehash.RehashWithL1Test.testPutWithRehashAndCacheClear
> java.lang.AssertionError: wrong value for k0
> at org.testng.AssertJUnit.fail(AssertJUnit.java:59) ~[testng-6.8.8.jar:?]
> at org.testng.AssertJUnit.assertTrue(AssertJUnit.java:24) ~[testng-6.8.8.jar:?]
> at org.testng.AssertJUnit.assertNull(AssertJUnit.java:282) ~[testng-6.8.8.jar:?]
> at org.infinispan.distribution.rehash.RehashWithL1Test.testPutWithRehashAndCacheClear(RehashWithL1Test.java:78) ~[test-classes/:?]
> *** Too late
> 03:24:30,360 TRACE (transport-thread-Test-NodeA-p51-t6:[Topology-___defaultcache]) [DefaultDataContainer] Removed MortalCacheEntry{key=k0, value=some data} from container
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (ISPN-375) Enable Hot Rod clients to start transactions
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-375?page=com.atlassian.jira.plugin.s... ]
Radim Vansa commented on ISPN-375:
----------------------------------
Does not seem as a blocker, after 7 years not being implemented. Related: https://github.com/infinispan/infinispan-designs/pull/6
> 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: Pedro Ruivo
> Priority: Blocker
> Labels: hackathon
>
> 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 was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (ISPN-7806) QueryInterceptor should not load entries from DC but context
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-7806?page=com.atlassian.jira.plugin.... ]
Radim Vansa updated ISPN-7806:
------------------------------
Description:
Currently in {{visitPrepareCommand}} the query interceptor is loading data directly from data container. That's wrong - if the entry is passivated/evicted, the previous value is incorrect.
As the data is not loaded (from DC/persistence) at current QI position, we should move QueryInterceptor after EntryWrappingInterceptor, CacheLoaderInterceptor and xDistributionInterceptor (which may load the data from remote node), and load the previous entry from context instead. The same approach should be taken for non-tx command, rather than relying on their return value.
There will still be issues if the command has SKIP_CACHE_LOAD flag: I suggest warning message if it doesn't have SKIP_INDEXING flag as well.
was:
Currently in {{visitPrepareCommand}} the query interceptor is loading data directly from data container. That's wrong - if the entry is passivated/evicted, the previous value is incorrect.
As the data is not loaded (from DC/persistence) at current QI position, we should move QueryInterceptor after EntryWrappingInterceptor and CacheLoaderInterceptor (before xDistributionInterceptor), and load the previous entry from context instead. The same approach should be taken for non-tx command, rather than relying on their return value.
There will still be issues if the command has SKIP_CACHE_LOAD flag: I suggest warning message if it doesn't have SKIP_INDEXING flag as well.
> QueryInterceptor should not load entries from DC but context
> ------------------------------------------------------------
>
> Key: ISPN-7806
> URL: https://issues.jboss.org/browse/ISPN-7806
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying
> Affects Versions: 9.0.0.Final
> Reporter: Radim Vansa
> Assignee: Adrian Nistor
>
> Currently in {{visitPrepareCommand}} the query interceptor is loading data directly from data container. That's wrong - if the entry is passivated/evicted, the previous value is incorrect.
> As the data is not loaded (from DC/persistence) at current QI position, we should move QueryInterceptor after EntryWrappingInterceptor, CacheLoaderInterceptor and xDistributionInterceptor (which may load the data from remote node), and load the previous entry from context instead. The same approach should be taken for non-tx command, rather than relying on their return value.
> There will still be issues if the command has SKIP_CACHE_LOAD flag: I suggest warning message if it doesn't have SKIP_INDEXING flag as well.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months