May 2016 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-6130) # Activations shows incorrect value

by Pedro Zapata (JIRA)

[ https://issues.jboss.org/browse/ISPN-6130?page=com.atlassian.jira.plugin.... ] Pedro Zapata commented on ISPN-6130: ------------------------------------ the console is displaying the following attributes: - clusterwide-activations - clusterwide-evictions - clusterwide-invalidations - clusterwide-passivations which are the correct attributes. The problem relies on the DMR calculation. On the other side, for replicated caches also they are calculated as activations x num_nodes, not sure if the user might be expecting this (given all nodes will have the same behaviour). > # Activations shows incorrect value > ------------------------------------ > > Key: ISPN-6130 > URL: https://issues.jboss.org/browse/ISPN-6130 > Project: Infinispan > Issue Type: Bug > Components: Console > Affects Versions: 8.1.0.Beta1 > Reporter: Martin Vrabel > Assignee: Vladimir Blagojevic > > Page: Caches -> select cache container -> select cache. > Configuration of the cache: replicated cache, 2 nodes in the domain evictions size=10 > In the Entries lifecycle" tab, there is a field "# Activations" which should show number of Activations . When I put 10 entries in the cache and read 10, this field #Activations show 0 as is should. But when I insert another 10 entries (so the first 10 entries will evict and be stored in the cache store) and read the first 10 entries the #Activations field will show 0, but it should be 10 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6587) Eviction type does not chage after reconfiguring in console

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-6587?page=com.atlassian.jira.plugin.... ] Ryan Emerson updated ISPN-6587: ------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan-management-console/pull/92 > Eviction type does not chage after reconfiguring in console > ----------------------------------------------------------- > > Key: ISPN-6587 > URL: https://issues.jboss.org/browse/ISPN-6587 > Project: Infinispan > Issue Type: Bug > Components: Console > Affects Versions: 9.0.0.Alpha1 > Reporter: Ryan Emerson > Assignee: Ryan Emerson > > container -> cache -> configuration -> eviction -> eviction type > "Type" was empty before. > After changing it to COUNT or MEMORY and afterwards open the configuration page again to check if it was changed the "Type" remained empty. > The JMX value was also not changed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6179) Number of Locks available and Locks held is always 0

by Pedro Zapata (JIRA)

[ https://issues.jboss.org/browse/ISPN-6179?page=com.atlassian.jira.plugin.... ] Pedro Zapata updated ISPN-6179: ------------------------------- Attachment: (was: screenshot-1.png) > Number of Locks available and Locks held is always 0 > ---------------------------------------------------- > > Key: ISPN-6179 > URL: https://issues.jboss.org/browse/ISPN-6179 > Project: Infinispan > Issue Type: Bug > Components: Console > Affects Versions: 8.1.1.Final > Reporter: Martin Vrabel > Assignee: Vladimir Blagojevic > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6491) Remove total order thread pool.

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-6491?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-6491: ------------------------------ Status: Open (was: New) > Remove total order thread pool. > ------------------------------- > > Key: ISPN-6491 > URL: https://issues.jboss.org/browse/ISPN-6491 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 9.0.0.Alpha2 > > > The thread pool was deprecated and it is no longer used since long time ago. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6491) Remove total order thread pool.

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-6491?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-6491: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/4301 > Remove total order thread pool. > ------------------------------- > > Key: ISPN-6491 > URL: https://issues.jboss.org/browse/ISPN-6491 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 9.0.0.Alpha2 > > > The thread pool was deprecated and it is no longer used since long time ago. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6179) Number of Locks available and Locks held is always 0

by Pedro Zapata (JIRA)

[ https://issues.jboss.org/browse/ISPN-6179?page=com.atlassian.jira.plugin.... ] Pedro Zapata updated ISPN-6179: ------------------------------- Attachment: screenshot-1.png > Number of Locks available and Locks held is always 0 > ---------------------------------------------------- > > Key: ISPN-6179 > URL: https://issues.jboss.org/browse/ISPN-6179 > Project: Infinispan > Issue Type: Bug > Components: Console > Affects Versions: 8.1.1.Final > Reporter: Martin Vrabel > Assignee: Vladimir Blagojevic > Attachments: screenshot-1.png > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6488) CacheRpcCommands should use byte[] representations of cache names to avoid writeUTF

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6488?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-6488: ------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 9.0.0.Alpha2 Resolution: Done > CacheRpcCommands should use byte[] representations of cache names to avoid writeUTF > ----------------------------------------------------------------------------------- > > Key: ISPN-6488 > URL: https://issues.jboss.org/browse/ISPN-6488 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 9.0.0.Alpha2 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6582) JDBC isUpsertSupported() does not respect Semantic Versioning

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6582?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-6582: ------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 9.0.0.Alpha2 Resolution: Done > JDBC isUpsertSupported() does not respect Semantic Versioning > ------------------------------------------------------------- > > Key: ISPN-6582 > URL: https://issues.jboss.org/browse/ISPN-6582 > Project: Infinispan > Issue Type: Bug > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Fix For: 9.0.0.Alpha2 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[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)

9 years, 11 months

1
0
0 / 0

[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)

9 years, 11 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues May 2016