[JBoss JIRA] (ISPN-6573) Functional API should support transactional caches
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-6573?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-6573:
------------------------------------
[~rvansa] [~ksobolewski] I made it an enhancement.
> Functional API should support transactional caches
> --------------------------------------------------
>
> Key: ISPN-6573
> URL: https://issues.jboss.org/browse/ISPN-6573
> Project: Infinispan
> Issue Type: Enhancement
> 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 should support transactional caches
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-6573?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-6573:
-------------------------------
Issue Type: Enhancement (was: Bug)
Summary: Functional API should support transactional caches (was: Functional API does not work [correctly] in transaction context)
> Functional API should support transactional caches
> --------------------------------------------------
>
> Key: ISPN-6573
> URL: https://issues.jboss.org/browse/ISPN-6573
> Project: Infinispan
> Issue Type: Enhancement
> 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-5972) Number of entries not working correctly in cache statistics in mgmt console
by Pedro Zapata (JIRA)
[ https://issues.jboss.org/browse/ISPN-5972?page=com.atlassian.jira.plugin.... ]
Pedro Zapata reassigned ISPN-5972:
----------------------------------
Assignee: Pedro Ruivo (was: Pedro Zapata)
> Number of entries not working correctly in cache statistics in mgmt console
> ---------------------------------------------------------------------------
>
> Key: ISPN-5972
> URL: https://issues.jboss.org/browse/ISPN-5972
> Project: Infinispan
> Issue Type: Bug
> Components: Console
> Affects Versions: 8.1.0.Beta1
> Reporter: Jiří Holuša
> Assignee: Pedro Ruivo
>
> Page: Caches -> select cache container -> select cache.
> Configuration of the cache: replicated cache, 2 nodes in the domain
> In the "Cache content" tab, there is a field "# Entries" which should probably show number of entries in the cache. When I put 100 entries in the cache, this field shows 200. Given that it's replicated cache, I think what's happening is that it shows numberOfNodes*numberOfEntries, because when I try to put 100 entries with 3 nodes in the domain, the "# Entries" shows 300.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years
[JBoss JIRA] (ISPN-5972) Number of entries not working correctly in cache statistics in mgmt console
by Pedro Zapata (JIRA)
[ https://issues.jboss.org/browse/ISPN-5972?page=com.atlassian.jira.plugin.... ]
Pedro Zapata commented on ISPN-5972:
------------------------------------
I believe the console is showing the right DMR attribute (clusterwide-number-of-entries). The problem seems that for replicated caches it's calculated as number_of_entries x number_of_nodes. It needs to be fixed at the DMR level.
> Number of entries not working correctly in cache statistics in mgmt console
> ---------------------------------------------------------------------------
>
> Key: ISPN-5972
> URL: https://issues.jboss.org/browse/ISPN-5972
> Project: Infinispan
> Issue Type: Bug
> Components: Console
> Affects Versions: 8.1.0.Beta1
> Reporter: Jiří Holuša
> Assignee: Pedro Zapata
>
> Page: Caches -> select cache container -> select cache.
> Configuration of the cache: replicated cache, 2 nodes in the domain
> In the "Cache content" tab, there is a field "# Entries" which should probably show number of entries in the cache. When I put 100 entries in the cache, this field shows 200. Given that it's replicated cache, I think what's happening is that it shows numberOfNodes*numberOfEntries, because when I try to put 100 entries with 3 nodes in the domain, the "# Entries" shows 300.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years