[JBoss JIRA] (ISPN-6573) Functional API does not work [correctly] in transaction context
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-6573?page=com.atlassian.jira.plugin.... ]
Radim Vansa edited comment on ISPN-6573 at 5/3/16 5:16 AM:
-----------------------------------------------------------
So the functional API was not implemented yet for transactional mode; some graceful failure to tell that user would be nice.
I did some work on this in https://github.com/rvansa/infinispan/tree/ISPN-6573 but I've realized that it needs even more effort, especially in TxDistributionInterceptor, where the read* commands have to replicate to remote nodes. That means new command like ClusteredGet(All)Command.
It's even more troublesome for read-write commands: transactional commands are expected to be sent and executed only as part of the PrepareCommand. However, these functional commands need to go to the owners, execute there (to provide return values, but not apply the new values), and then execute second time (this time under locks) during 2PC. Or, ideally, the result of first execution should be stored on the remote site.
All in all, days or weeks of work.
was (Author: rvansa):
So the functional API was not implemented yet for transactional mode; some graceful failure to tell that user would be nice.
I did some work on this in https://github.com/rvansa/infinispan/tree/ISPN-6573 but I've realized that it needs even more effort, especially in TxDistributionInterceptor, where the read commands have to replicate to remote nodes.
> Functional API does not work [correctly] in transaction context
> ---------------------------------------------------------------
>
> Key: ISPN-6573
> URL: https://issues.jboss.org/browse/ISPN-6573
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 8.2.1.Final
> Reporter: Krzysztof Sobolewski
> Attachments: AbstractFunctionalCachestoreTest.java, AbstractFunctionalInMemoryTest.java, FunctionalCachestoreTestNonTx.java, FunctionalCachestoreTestTx.java, FunctionalInMemoryTestNonTx.java, FunctionalInMemoryTestTx.java
>
>
> What is needed: a functional write operation on a key on a node that is not the key's owner, with cache loader enabled. What happens then is in non-transactional context it works fine; It starts failing when the functional operation is done in a transaction. Looks like the entry is wrapped prematurely, which puts it into the context's looked up nodes with the null value; the cache loader skips because the key is not local; and when it reaches Command.perform(), it still has null value. In the non-tx context this works OK because the command returns early if the entry is null (not wrapped) and then it is properly sent across the cluster. But in tx context it gets confused and invokes the functional operation on the local node even if it's not the owner. The functional operation gets an empty entry even though the cache loader would load it. It then modifies the entry, but the modification is not propagated anywhere because the tx distribution interceptor... well, because it doesn't handle this command at all? And the change is (apparently) not committed on the local node because it's not an owner.
> Oh, and if the node *is* an owner it doesn't help :)
> The tests are also available at https://gist.github.com/ksobolew/74bb8ff6b321786e64a62ecd0e4c5878/836905d...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years
[JBoss JIRA] (ISPN-6573) Functional API does not work [correctly] in transaction context
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-6573?page=com.atlassian.jira.plugin.... ]
Radim Vansa commented on ISPN-6573:
-----------------------------------
So the functional API was not implemented yet for transactional mode; some graceful failure to tell that user would be nice.
I did some work on this in https://github.com/rvansa/infinispan/tree/ISPN-6573 but I've realized that it needs even more effort, especially in TxDistributionInterceptor, where the read commands have to replicate to remote nodes.
> Functional API does not work [correctly] in transaction context
> ---------------------------------------------------------------
>
> Key: ISPN-6573
> URL: https://issues.jboss.org/browse/ISPN-6573
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 8.2.1.Final
> Reporter: Krzysztof Sobolewski
> Attachments: AbstractFunctionalCachestoreTest.java, AbstractFunctionalInMemoryTest.java, FunctionalCachestoreTestNonTx.java, FunctionalCachestoreTestTx.java, FunctionalInMemoryTestNonTx.java, FunctionalInMemoryTestTx.java
>
>
> What is needed: a functional write operation on a key on a node that is not the key's owner, with cache loader enabled. What happens then is in non-transactional context it works fine; It starts failing when the functional operation is done in a transaction. Looks like the entry is wrapped prematurely, which puts it into the context's looked up nodes with the null value; the cache loader skips because the key is not local; and when it reaches Command.perform(), it still has null value. In the non-tx context this works OK because the command returns early if the entry is null (not wrapped) and then it is properly sent across the cluster. But in tx context it gets confused and invokes the functional operation on the local node even if it's not the owner. The functional operation gets an empty entry even though the cache loader would load it. It then modifies the entry, but the modification is not propagated anywhere because the tx distribution interceptor... well, because it doesn't handle this command at all? And the change is (apparently) not committed on the local node because it's not an owner.
> Oh, and if the node *is* an owner it doesn't help :)
> The tests are also available at https://gist.github.com/ksobolew/74bb8ff6b321786e64a62ecd0e4c5878/836905d...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years
[JBoss JIRA] (ISPN-6456) OptimisticTxPartitionAndMergeDuringPrepareTest.testOriginatorIsolatedPartition fails randomly
by Ivan Straka (JIRA)
[ https://issues.jboss.org/browse/ISPN-6456?page=com.atlassian.jira.plugin.... ]
Ivan Straka reassigned ISPN-6456:
---------------------------------
Assignee: Galder Zamarreño (was: Martin Vrabel)
> OptimisticTxPartitionAndMergeDuringPrepareTest.testOriginatorIsolatedPartition fails randomly
> ---------------------------------------------------------------------------------------------
>
> Key: ISPN-6456
> URL: https://issues.jboss.org/browse/ISPN-6456
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 8.1.2.Final
> Reporter: Ivan Straka
> Assignee: Galder Zamarreño
>
> Test in Infinispan testsuite org.infinispan.partitionhandling.OptimisticTxPartitionAndMergeDuringPrepareTest.testOriginatorIsolatedPartition fails randomly
> {code:java}
> java.lang.RuntimeException: Timed out waiting for rebalancing to complete on node OptimisticTxPartitionAndMergeDuringPrepareTest-NodeI-7304, expected member list is [OptimisticTxPartitionAndMergeDuringPrepareTest-NodeI-7304, OptimisticTxPartitionAndMergeDuringPrepareTest-NodeJ-31794, OptimisticTxPartitionAndMergeDuringPrepareTest-NodeK-33671, OptimisticTxPartitionAndMergeDuringPrepareTest-NodeL-56275], current member list is [OptimisticTxPartitionAndMergeDuringPrepareTest-NodeJ-31794, OptimisticTxPartitionAndMergeDuringPrepareTest-NodeK-33671, OptimisticTxPartitionAndMergeDuringPrepareTest-NodeL-56275]!
> at org.infinispan.test.TestingUtil.waitForRehashToComplete(TestingUtil.java:239)
> at org.infinispan.test.TestingUtil.waitForRehashToComplete(TestingUtil.java:249)
> at org.infinispan.partitionhandling.BaseTxPartitionAndMergeTest.mergeCluster(BaseTxPartitionAndMergeTest.java:87)
> at org.infinispan.partitionhandling.BaseOptimisticTxPartitionAndMergeTest.doTest(BaseOptimisticTxPartitionAndMergeTest.java:75)
> at org.infinispan.partitionhandling.OptimisticTxPartitionAndMergeDuringPrepareTest.testOriginatorIsolatedPartition(OptimisticTxPartitionAndMergeDuringPrepareTest.java:33)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:348)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:38)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:382)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years
[JBoss JIRA] (HRJS-10) Buffer extension could lead to String truncation
by Galder Zamarreño (JIRA)
Galder Zamarreño created HRJS-10:
------------------------------------
Summary: Buffer extension could lead to String truncation
Key: HRJS-10
URL: https://issues.jboss.org/browse/HRJS-10
Project: Infinispan Javascript client
Issue Type: Bug
Reporter: Galder Zamarreño
Priority: Critical
When encoding a String, there's a chance that there's a need to extend the size of the buffer if the String won't fit the buffer. However, when calculating whether extending is required, only the String size is counted without counting the num bytes counter at the start. As a result of that, a String might end up being truncated and lead to operation hanging up.
This happened in executing a Script where the number of bytes sent as message ID was bigger than 27 and the script name being executed was exactly 23 characters.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years
[JBoss JIRA] (ISPN-6530) Cannot enable security configuration for a cache in cache configuration page if there was no security configuration at container startup
by Vladimir Blagojevic (JIRA)
[ https://issues.jboss.org/browse/ISPN-6530?page=com.atlassian.jira.plugin.... ]
Vladimir Blagojevic updated ISPN-6530:
--------------------------------------
Comment: was deleted
(was: [~mvrabel] What are the steps? I took a fresh install of Infinispan server, went on cache container security page, clicked on yes and configured two roles. Everything worked ok. )
> Cannot enable security configuration for a cache in cache configuration page if there was no security configuration at container startup
> ----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-6530
> URL: https://issues.jboss.org/browse/ISPN-6530
> Project: Infinispan
> Issue Type: Bug
> Components: Console
> Affects Versions: 8.2.1.Final
> Reporter: Martin Vrabel
> Assignee: Vladimir Blagojevic
>
> in cache configuration page in security tab. if a cache didn't have a security configuration e.g.
> <security>
> <authorization roles="admin" />
> </security>
> at the start of the container and I enable security in the cache configuration page I get this error.
> The console looks for the JMX value but because there is no configuration it throws an error
> Error
> domain-failure-description
> WFLYCTL0175: Resource [ ("profile" => "clustered"), ("subsystem" => "datagrid-infinispan"), ("cache-container" => "testContainer"), ("configurations" => "CONFIGURATIONS"), ("local-cache-configuration" => "localCacheForConfigurationTesting"), ("security" => "SECURITY") ] does not exist; a resource at address [ ("profile" => "clustered"), ("subsystem" => "datagrid-infinispan"), ("cache-container" => "testContainer"), ("configurations" => "CONFIGURATIONS"), ("local-cache-configuration" => "localCacheForConfigurationTesting"), ("security" => "SECURITY"), ("authorization" => "AUTHORIZATION") ] cannot be created until all ancestor resources have been added
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years
[JBoss JIRA] (ISPN-6530) Cannot enable security configuration for a cache in cache configuration page if there was no security configuration at container startup
by Vladimir Blagojevic (JIRA)
[ https://issues.jboss.org/browse/ISPN-6530?page=com.atlassian.jira.plugin.... ]
Vladimir Blagojevic commented on ISPN-6530:
-------------------------------------------
[~mvrabel] What are the steps? I took a fresh install of Infinispan server, went on cache container security page, clicked on yes and configured two roles. Everything worked ok.
> Cannot enable security configuration for a cache in cache configuration page if there was no security configuration at container startup
> ----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-6530
> URL: https://issues.jboss.org/browse/ISPN-6530
> Project: Infinispan
> Issue Type: Bug
> Components: Console
> Affects Versions: 8.2.1.Final
> Reporter: Martin Vrabel
> Assignee: Vladimir Blagojevic
>
> in cache configuration page in security tab. if a cache didn't have a security configuration e.g.
> <security>
> <authorization roles="admin" />
> </security>
> at the start of the container and I enable security in the cache configuration page I get this error.
> The console looks for the JMX value but because there is no configuration it throws an error
> Error
> domain-failure-description
> WFLYCTL0175: Resource [ ("profile" => "clustered"), ("subsystem" => "datagrid-infinispan"), ("cache-container" => "testContainer"), ("configurations" => "CONFIGURATIONS"), ("local-cache-configuration" => "localCacheForConfigurationTesting"), ("security" => "SECURITY") ] does not exist; a resource at address [ ("profile" => "clustered"), ("subsystem" => "datagrid-infinispan"), ("cache-container" => "testContainer"), ("configurations" => "CONFIGURATIONS"), ("local-cache-configuration" => "localCacheForConfigurationTesting"), ("security" => "SECURITY"), ("authorization" => "AUTHORIZATION") ] cannot be created until all ancestor resources have been added
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years
[JBoss JIRA] (ISPN-5354) HotRod putAll send proper CH routing
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-5354?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-5354:
----------------------------------
Status: Open (was: New)
> HotRod putAll send proper CH routing
> ------------------------------------
>
> Key: ISPN-5354
> URL: https://issues.jboss.org/browse/ISPN-5354
> Project: Infinispan
> Issue Type: Enhancement
> Components: Remote Protocols
> Reporter: William Burns
> Fix For: 9.0.0.Alpha2, 8.2.2.Final, 9.0.0.Final
>
>
> We need to enable putAll operation on hot rod to send multiple commands where each owner receives the keys it owns. This way the embedded server has less routing to do.
> This requires having some sort of thread pool for use on the client though, as doing each request sequentially seems it would probably be slower than just sending 1 request.
> This relates to ISPN-5266
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years