February 2013 - infinispan-issues

[JBoss JIRA] (ISPN-2824) Excluive lock operation required to support invokeEntryProcessor()

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2824?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-2824: ----------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/1686 > Excluive lock operation required to support invokeEntryProcessor() > ------------------------------------------------------------------ > > Key: ISPN-2824 > URL: https://issues.jboss.org/browse/ISPN-2824 > Project: Infinispan > Issue Type: Sub-task > Components: Locking and Concurrency > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 5.3.0.Alpha1 > > > Exclusive lock semantics are needed within Infinispan in order to support JSR-107's invokeEntryProcessor() method. See dev thread for detailed information. -- 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

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2859) Reduce the verbosity of state transfer trace logs

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2859?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2859: -------------------------------- Attachment: segments.txt just for my own curiosity: this is how a 5k segments with numOwners=2 log looks like. It's big (160kb) but fixed in size (i.e. doesn't depende om the number of entires) so not s killer for the trace. > Reduce the verbosity of state transfer trace logs > ------------------------------------------------- > > Key: ISPN-2859 > URL: https://issues.jboss.org/browse/ISPN-2859 > Project: Infinispan > Issue Type: Feature Request > Components: State transfer > Affects Versions: 5.2.2.Final > Reporter: Mircea Markus > Assignee: Mircea Markus > Labels: 5.2.x > Fix For: 5.3.0.Alpha1, 5.3.0.Final > > Attachments: segments.txt > > > StateResponseCommand logs all entries that are sent across during state transfer which can be too verbose. For more details refer to http://infinispan.markmail.org/search/?q=More+verbose+logging#query:More%... -- 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

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2839) Method boolean Cache.replace(K key, V oldValue, V value) (and variants) should guard against null oldValue parameter

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2839?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-2839: ----------------------------------- Fix Version/s: 5.3.0.Alpha1 I guess it'll be included in Alpha1 too? :) Thanks for fixing this, JSR-107 checks that too, so glad you fixed it. > Method boolean Cache.replace(K key, V oldValue, V value) (and variants) should guard against null oldValue parameter > -------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-2839 > URL: https://issues.jboss.org/browse/ISPN-2839 > Project: Infinispan > Issue Type: Bug > Components: Core API > Affects Versions: 5.2.1.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Priority: Minor > Labels: 5.2.x > Fix For: 5.2.2.Final, 5.3.0.Alpha1, 5.3.0.Final > > > The null check is not done explicitly but it will accidentally fail with NPE when trying to cast the result of the execution of ReplaceCommand to a Boolean. -- 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

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2867) The CLI doesn't quit when using JBoss Remoting

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-2867?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-2867: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/1685 > The CLI doesn't quit when using JBoss Remoting > ---------------------------------------------- > > Key: ISPN-2867 > URL: https://issues.jboss.org/browse/ISPN-2867 > Project: Infinispan > Issue Type: Bug > Components: CLI > Affects Versions: 5.2.2.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 5.2.3.Final, 5.3.0.Final > > > JBoss Remoting doesn't terminate all threads. Therefore we should use System.exit(0) to quit. -- 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

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2865) Error calling clear() via JMX on a transactional cache with autoCommit=false

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-2865?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-2865: ---------------------------------- Fix Version/s: 5.2.3.Final 5.3.0.Final > Error calling clear() via JMX on a transactional cache with autoCommit=false > ---------------------------------------------------------------------------- > > Key: ISPN-2865 > URL: https://issues.jboss.org/browse/ISPN-2865 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management > Affects Versions: 5.2.1.Final > Environment: Apache Tomcat on Linux and Windows > Reporter: Marc Richards > Assignee: Mircea Markus > Fix For: 5.2.3.Final, 5.3.0.Final > > > Calling clear() via JMX (e.g. JConsole) on a transactional cache with autoCommit="false" fails with an IllegalStateException. > Looking at the source code it would appear that the expectation is that the call to clear() would have been wrapped in a transaction, however that is not currently happening for calls made via JMX if autoCommit="false". > > The [clear() method in CacheImpl.java line 321|https://github.com/infinispan/infinispan/blob/5.2.1.Final/core/src/ma...] calls getInvocationContextWithImplicitTransaction() which tests to see if there is an ongoing transaction [on line 482|https://github.com/infinispan/infinispan/blob/5.2.1.Final/core/src/ma...] . If autocommit is turned on, it will automatically create an implicit transaction, but if it is off as I had it, it will simply call createInvocationContext() and throw an IllegalStateException when it sees that the transaction is still null in [TransactionalInvocationContextContainer.java on line 112|https://github.com/infinispan/infinispan/blob/5.2.1.Final/core/src/ma...]. > I currently work around the issue by setting autoCommit="true", but that is not an ideal solution. -- 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

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2865) Error calling clear() via JMX on a transactional cache with autoCommit=false

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-2865?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-2865: ---------------------------------- Labels: 5.2.x (was: ) > Error calling clear() via JMX on a transactional cache with autoCommit=false > ---------------------------------------------------------------------------- > > Key: ISPN-2865 > URL: https://issues.jboss.org/browse/ISPN-2865 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management > Affects Versions: 5.2.1.Final > Environment: Apache Tomcat on Linux and Windows > Reporter: Marc Richards > Assignee: Mircea Markus > Labels: 5.2.x > Fix For: 5.2.3.Final, 5.3.0.Final > > > Calling clear() via JMX (e.g. JConsole) on a transactional cache with autoCommit="false" fails with an IllegalStateException. > Looking at the source code it would appear that the expectation is that the call to clear() would have been wrapped in a transaction, however that is not currently happening for calls made via JMX if autoCommit="false". > > The [clear() method in CacheImpl.java line 321|https://github.com/infinispan/infinispan/blob/5.2.1.Final/core/src/ma...] calls getInvocationContextWithImplicitTransaction() which tests to see if there is an ongoing transaction [on line 482|https://github.com/infinispan/infinispan/blob/5.2.1.Final/core/src/ma...] . If autocommit is turned on, it will automatically create an implicit transaction, but if it is off as I had it, it will simply call createInvocationContext() and throw an IllegalStateException when it sees that the transaction is still null in [TransactionalInvocationContextContainer.java on line 112|https://github.com/infinispan/infinispan/blob/5.2.1.Final/core/src/ma...]. > I currently work around the issue by setting autoCommit="true", but that is not an ideal solution. -- 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

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2867) The CLI doesn't quit when using JBoss Remoting

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-2867: ------------------------------------- Summary: The CLI doesn't quit when using JBoss Remoting Key: ISPN-2867 URL: https://issues.jboss.org/browse/ISPN-2867 Project: Infinispan Issue Type: Bug Components: CLI Affects Versions: 5.2.2.Final Reporter: Tristan Tarrant Assignee: Tristan Tarrant Fix For: 5.2.3.Final, 5.3.0.Final JBoss Remoting doesn't terminate all threads. Therefore we should use System.exit(0) to quit. -- 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

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2866) EmbeddedCacheManager.defineConfiguration(...) should be thread safe

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/ISPN-2866?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated ISPN-2866: ------------------------------- Summary: EmbeddedCacheManager.defineConfiguration(...) should be thread safe (was: defineConfiguration() should be thread safe) > EmbeddedCacheManager.defineConfiguration(...) should be thread safe > ------------------------------------------------------------------- > > Key: ISPN-2866 > URL: https://issues.jboss.org/browse/ISPN-2866 > Project: Infinispan > Issue Type: Feature Request > Components: Configuration > Affects Versions: 5.2.1.Final > Reporter: Radoslav Husar > Assignee: Mircea Markus > Priority: Critical > Fix For: 5.2.3.Final > > > Defining configuration really should be thread safe. > In AS we will temporarily workaround per AS7-6639. > The issue was uncovered after we started seeing NPE from https://github.com/infinispan/infinispan/commit/f0beece095acb273a18bbef05... -- 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

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2866) defineConfiguration() should be thread safe

by Radoslav Husar (JIRA)

Radoslav Husar created ISPN-2866: ------------------------------------ Summary: defineConfiguration() should be thread safe Key: ISPN-2866 URL: https://issues.jboss.org/browse/ISPN-2866 Project: Infinispan Issue Type: Feature Request Components: Configuration Affects Versions: 5.2.1.Final Reporter: Radoslav Husar Assignee: Mircea Markus Priority: Critical Fix For: 5.2.3.Final Defining configuration really should be thread safe. In AS we will temporarily workaround per AS7-6639. The issue was uncovered after we started seeing NPE from https://github.com/infinispan/infinispan/commit/f0beece095acb273a18bbef05... -- 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

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2862) Integrate the Self-tuning Data Placement from CloudTM into Infinispan

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-2862?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-2862: ------------------------------ Description: With the same goal as L1 Cache, it applies a different technique to reduce the communication overhead. The self-tunning data placement detects which are the keys most accessed by each node, modifies the ConsistentHash and triggers the State Transfer in order to move the keys for that nodes. The main difference for L1 Cache is the fact that L1 creates a new copy of the <key,value> in the requestor node, that needs to be invalidated later. The Data Placement, really moves the <key,value> to that requestor. Both techniques can be enabled at the same time. This module depends of ISPN-2861, namely the top-key module. was:This is a smarter L1 implementation. > Integrate the Self-tuning Data Placement from CloudTM into Infinispan > --------------------------------------------------------------------- > > Key: ISPN-2862 > URL: https://issues.jboss.org/browse/ISPN-2862 > Project: Infinispan > Issue Type: Feature Request > Reporter: Mircea Markus > Assignee: Pedro Ruivo > Fix For: 5.3.0.Final > > Attachments: autoplacer.pdf > > > With the same goal as L1 Cache, it applies a different technique to reduce the communication overhead. The self-tunning data placement detects which are the keys most accessed by each node, modifies the ConsistentHash and triggers the State Transfer in order to move the keys for that nodes. > The main difference for L1 Cache is the fact that L1 creates a new copy of the <key,value> in the requestor node, that needs to be invalidated later. The Data Placement, really moves the <key,value> to that requestor. > Both techniques can be enabled at the same time. > This module depends of ISPN-2861, namely the top-key module. -- 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

11 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues February 2013