March 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4010) Allow configuring the LevelDB cache store through JON

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4010?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4010: ----------------------------------------------- William Burns <wburns(a)redhat.com> changed the Status of [bug 1060299|https://bugzilla.redhat.com/show_bug.cgi?id=1060299] from NEW to POST > Allow configuring the LevelDB cache store through JON > ----------------------------------------------------- > > Key: ISPN-4010 > URL: https://issues.jboss.org/browse/ISPN-4010 > Project: Infinispan > Issue Type: Feature Request > Reporter: Mircea Markus > Assignee: William Burns > Labels: 621, 630 > Fix For: 7.0.0.Final, 7.0.0.Alpha2 > > > Although a JON console can create a cache, the JON can not set a levelDB store configuration. Our customer wants to set a levelDB store setting using the JON when creating the cache. -- 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

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-3803) Stale locks during state transfer in non-tx caches

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3803?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3803: ------------------------------- Labels: 621 testsuite_stability (was: testsuite_stability) > Stale locks during state transfer in non-tx caches > -------------------------------------------------- > > Key: ISPN-3803 > URL: https://issues.jboss.org/browse/ISPN-3803 > Project: Infinispan > Issue Type: Bug > Components: State Transfer, Transactions > Affects Versions: 6.0.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Labels: 621, testsuite_stability > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > > The problem is that {{SingleKeyNonTxInvocationContext.addLockedKey()}} only sets a {{isLocked}} flag, the actual key is set when the entry is wrapped and inserted in the context. If the topology changes between the lock acquisition and the entry wrapping, {{SingleKeyNonTxInvocationContext.getLockedKeys()}} will return an empty set and the lock won't be released. > Future commands won't try to acquire a lock on this node, so the stale lock is harmless most of the time. But if there was already a command waiting for the lock, that command will time out (instead of retrying on the new primary owner). > This causes random failures in NonTxPutIfAbsentDuringJoinStressTest: > {noformat} > 12:34:50,960 TRACE (ForkThread-3,NonTxPutIfAbsentDuringJoinStressTest:___defaultcache) [InvocationContextInterceptor] Invoked with command PutKeyValueCommand{key=key_52, value=value_52_2, flags=null, putIfAbsent=true, valueMatcher=MATCH_EXPECTED, metadata=EmbeddedMetadata{version=null}, successful=true} and InvocationContext [org.infinispan.context.SingleKeyNonTxInvocationContext@478c9796] > 12:34:50,960 TRACE (ForkThread-3,NonTxPutIfAbsentDuringJoinStressTest:___defaultcache) [NonTransactionalLockingInterceptor] Are (NodeA-19338) we the lock owners for key 'key_52'? true > 12:34:50,960 TRACE (ForkThread-3,NonTxPutIfAbsentDuringJoinStressTest:___defaultcache) [LockManagerImpl] Attempting to lock key_52 with acquisition timeout of 10000 millis > 12:34:50,962 TRACE (remote-thread-1,NodeA:___defaultcache) [NonTransactionalLockingInterceptor] Are (NodeA-19338) we the lock owners for key 'key_52'? true > 12:34:50,962 TRACE (remote-thread-1,NodeA:___defaultcache) [LockManagerImpl] Attempting to lock key_52 with acquisition timeout of 10000 millis > 12:34:50,965 TRACE (asyncTransportThread-0,NodeA:___defaultcache) [StateConsumerImpl] Received new topology for cache ___defaultcache, isRebalance = false, isMember = true, topology = CacheTopology{id=4, currentCH=DefaultConsistentHash{numSegments=60, numOwners=2, members=[NodeA-19338, NodeB-49967, NodeC-56763]}, pendingCH=null} > 12:34:50,966 TRACE (ForkThread-3,NonTxPutIfAbsentDuringJoinStressTest:___defaultcache) [LockManagerImpl] Successfully acquired lock key_52! > *** 12:34:50,966 TRACE (ForkThread-3,NonTxPutIfAbsentDuringJoinStressTest:___defaultcache) [EntryWrappingInterceptor] Wrapping entry 'key_52'? false > 12:34:50,966 TRACE (ForkThread-3,NonTxPutIfAbsentDuringJoinStressTest:___defaultcache) [StateTransferInterceptor] Retrying command because of topology change: PutKeyValueCommand{key=key_52, value=value_52_2, flags=null, putIfAbsent=true, valueMatcher=MATCH_EXPECTED, metadata=EmbeddedMetadata{version=null}, successful=true} > 12:34:50,978 TRACE (ForkThread-3,NonTxPutIfAbsentDuringJoinStressTest:___defaultcache) [NonTransactionalLockingInterceptor] Are (NodeA-19338) we the lock owners for key 'key_52'? false > 12:34:50,978 TRACE (ForkThread-3,NonTxPutIfAbsentDuringJoinStressTest:___defaultcache) [EntryWrappingInterceptor] Wrapping entry 'key_52'? false > 12:34:50,978 TRACE (ForkThread-3,NonTxPutIfAbsentDuringJoinStressTest:___defaultcache) [BaseDistributionInterceptor] I'm not the primary owner, so sending the command to the primary owner(NodeC-56763) in order to be forwarded > 12:34:51,007 TRACE (ForkThread-3,NonTxPutIfAbsentDuringJoinStressTest:___defaultcache) [EntryWrappingInterceptor] The return value is value_52_0 > 12:35:00,963 TRACE (remote-thread-1,NodeA:___defaultcache) [ReentrantPerEntryLockContainer] Timed out attempting to acquire lock for key key_52 after 10 seconds > 12:35:00,963 DEBUG (remote-thread-1,NodeA:___defaultcache) [LockManagerImpl] Failed to acquire lock key_52, owner is Thread[ForkThread-3,NonTxPutIfAbsentDuringJoinStressTest,5,] > 12:35:00,963 DEBUG (remote-thread-1,NodeA:___defaultcache) [LockManagerImpl] This transaction (Thread[remote-thread-1,NodeA,5,main]) already owned locks [] > 12:35:00,966 ERROR (testng-NonTxPutIfAbsentDuringJoinStressTest:) [UnitTestTestNGListener] Test testNodeJoiningDuringPutIfAbsent(org.infinispan.distribution.rehash.NonTxPutIfAbsentDuringJoinStressTest) failed. > java.util.concurrent.ExecutionException: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from NodeA-19338, see cause for remote stack trace > Caused by: org.infinispan.util.concurrent.TimeoutException: Unable to acquire lock after [10 seconds] on key [key_52] for requestor [Thread[remote-thread-1,NodeA,5,main]]! Lock held by [Thread[ForkThread-3,NonTxPutIfAbsentDuringJoinStressTest,5,]]{noformat} -- 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

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-4035) SingleFileStore.FileEntry.compareTo is wrong

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4035?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4035: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1073334|https://bugzilla.redhat.com/show_bug.cgi?id=1073334] from NEW to POST > SingleFileStore.FileEntry.compareTo is wrong > -------------------------------------------- > > Key: ISPN-4035 > URL: https://issues.jboss.org/browse/ISPN-4035 > Project: Infinispan > Issue Type: Bug > Components: Core, Loaders and Stores > Affects Versions: 6.0.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Fix For: 7.0.0.Alpha1 > > > Because {{FileEntry.compareTo(fe)}} never returns 0, allocated entries are not properly removed from the free list (at least on IBM JDK 6). -- 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

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-4076) JON server plugin: bytesRead and bytesWritten stats are broken

by Tomas Sykora (JIRA)

Tomas Sykora created ISPN-4076: ---------------------------------- Summary: JON server plugin: bytesRead and bytesWritten stats are broken Key: ISPN-4076 URL: https://issues.jboss.org/browse/ISPN-4076 Project: Infinispan Issue Type: Bug Components: JMX, reporting and management Affects Versions: 7.0.0.Alpha1 Reporter: Tomas Sykora Assignee: Tomas Sykora resource path: subsystem=endpoint and underlined connectors provides statistics: bytesRead, bytesWritten. However plugin asks for bytes-read and bytes-written which is wrong. Small change in map in MetricsRemappingComponent is needed. + We will remove monitoring of those statistics for REST endpoint, as this endpoint does not provide those statistics at all. -- 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

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-4076) JON server plugin: bytesRead and bytesWritten stats are broken

by Tomas Sykora (JIRA)

[ https://issues.jboss.org/browse/ISPN-4076?page=com.atlassian.jira.plugin.... ] Work on ISPN-4076 started by Tomas Sykora. > JON server plugin: bytesRead and bytesWritten stats are broken > -------------------------------------------------------------- > > Key: ISPN-4076 > URL: https://issues.jboss.org/browse/ISPN-4076 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management > Affects Versions: 7.0.0.Alpha1 > Reporter: Tomas Sykora > Assignee: Tomas Sykora > > resource path: subsystem=endpoint > and underlined connectors provides statistics: bytesRead, bytesWritten. > However plugin asks for bytes-read and bytes-written which is wrong. Small change in map in MetricsRemappingComponent is needed. > + We will remove monitoring of those statistics for REST endpoint, as this endpoint does not provide those statistics at all. -- 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

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-3933) Preloading and Shared options can not be enabled on a JDBCCachestore via configuration files

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3933?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3933: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1073332|https://bugzilla.redhat.com/show_bug.cgi?id=1073332] from NEW to POST > Preloading and Shared options can not be enabled on a JDBCCachestore via configuration files > -------------------------------------------------------------------------------------------- > > Key: ISPN-3933 > URL: https://issues.jboss.org/browse/ISPN-3933 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 6.0.0.Final, 6.0.1.Final > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Priority: Critical > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > > The configuration schema doesn't allow to enable the "preload" attribute of a JDBCCacheStore. > I classify this as critical as the JDBCCacheStore is the only viable solution for a shared cachestore, and the Lucene Directory requires "preload" to be activated. -- 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

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-3937) Investigate the memory usage of JDBC cache stores when processing a large result set

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3937?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-3937: ------------------------------------ The fetch size is already exposed in the JDBC store configuration, so a user could work around the issue with {{storeBuilder.table().fetchSize(Integer.MIN_VALUE)}}. MySQL 5.0.2+ also has a {{useCursorFetch=true}} connection property that allows the driver to use any fetch size, not just Integer.MIN_VALUE: http://dev.mysql.com/doc/connector-j/en/connector-j-reference-configurati... It would be nice to have a better behaviour by default, but I'm not sure what would be the best choice. If the connection property really works, I think we could require the user to set it, and warn on startup if it's not set. > Investigate the memory usage of JDBC cache stores when processing a large result set > ------------------------------------------------------------------------------------ > > Key: ISPN-3937 > URL: https://issues.jboss.org/browse/ISPN-3937 > Project: Infinispan > Issue Type: Task > Components: Core, Loaders and Stores > Affects Versions: 6.0.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 7.0.0.Final > > > Iterating over a huge ResultSet with MySQL seems to keep all the rows in memory: https://community.jboss.org/message/854402 > We should investigate whether we can limit the memory usage to a fixed amount and whether this affects other drivers as well. -- 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

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-3868) Deadlock in RemoteCache getAsync

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3868?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3868: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1073331|https://bugzilla.redhat.com/show_bug.cgi?id=1073331] from NEW to POST > Deadlock in RemoteCache getAsync > -------------------------------- > > Key: ISPN-3868 > URL: https://issues.jboss.org/browse/ISPN-3868 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 6.0.0.Final > Environment: RemoteCahe component of 6.0.0.Final > Reporter: Alexander Furer > Assignee: Mircea Markus > Labels: remote > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > > Here is the implementation of remoteCahe.getAsync() : > {code} > public NotifyingFuture<V> getAsync(final K key) { > assertRemoteCacheManagerIsStarted(); > final NotifyingFutureImpl<V> result = new NotifyingFutureImpl<V>(); > Future<V> future = executorService.submit(new Callable<V>() { > @Override > public V call() throws Exception { > V toReturn = get(key); > result.notifyFutureCompletion(); > return toReturn; > } > }); > result.setExecuting(future); > return result; > } > {code} > 2 problems here : > 1. Callable's call method might be called BEFORE calling client had a chance to add listener (i.e. getAsync is not returned yet), in this case its' listener futureDone method will never be called. > 2. Even case #1 has not happened and notifyFutureCompletion is called on listener, but the future is not resolved yet : "call" has not returned, that's why the future that is passed to listener is not resolved, and calling future.get from listener blocks forever. -- 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

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-4006) Make protostream OSGI/Karaf friendly by providing a features.xml

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-4006?page=com.atlassian.jira.plugin.... ] Work on ISPN-4006 started by Adrian Nistor. > Make protostream OSGI/Karaf friendly by providing a features.xml > ---------------------------------------------------------------- > > Key: ISPN-4006 > URL: https://issues.jboss.org/browse/ISPN-4006 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Querying > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 7.0.0.Final > > -- 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

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-3845) CACHE_MODE_LOCAL flag only works in primary owner for non-tx caches

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3845?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3845: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1060311|https://bugzilla.redhat.com/show_bug.cgi?id=1060311] from POST to MODIFIED > CACHE_MODE_LOCAL flag only works in primary owner for non-tx caches > ------------------------------------------------------------------- > > Key: ISPN-3845 > URL: https://issues.jboss.org/browse/ISPN-3845 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.0.Final > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Labels: 621, testsuite_stability > Fix For: 7.0.0.Alpha1 > > > the flag is not forcing the EntryWrappingInterceptor to wrap the entry. the result is the entry will not be stored in the cache. > It's causing the random failures in: > {noformat} > HotRodReplicationTest.testReplicatedPutWithTopologyChanges > HotRod11ReplicationTest.testReplicatedPutWithTopologyChanges > HotRod12ReplicationTest.testReplicatedPutWithTopologyChanges > {noformat} -- 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

12 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2014