November 2012 - infinispan-issues

[JBoss JIRA] (ISPN-2530) Clear command does not work for distributed transactional caches

by Adrian Nistor (JIRA)

Adrian Nistor created ISPN-2530: ----------------------------------- Summary: Clear command does not work for distributed transactional caches Key: ISPN-2530 URL: https://issues.jboss.org/browse/ISPN-2530 Project: Infinispan Issue Type: Bug Components: Transactions Affects Versions: 5.2.0.Beta4 Reporter: Adrian Nistor Assignee: Adrian Nistor Fix For: 5.2.0.CR1 The clear command is executed locally and it removes all local keys but it is not sent to any other nodes (because affectedKeys for this transaction is empty). -- 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, 8 months

4
14
0 / 0

[JBoss JIRA] (ISPN-2534) Some tests are not picked up by Surefire

by Dan Berindei (JIRA)

Dan Berindei created ISPN-2534: ---------------------------------- Summary: Some tests are not picked up by Surefire Key: ISPN-2534 URL: https://issues.jboss.org/browse/ISPN-2534 Project: Infinispan Issue Type: Task Components: Test Suite Affects Versions: 5.2.0.Beta4 Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 5.2.0.Final Surefire picks up tests named "*Test.java" and "Test*.java", but not "*Test*.java". There are some tests that don't follow the "*Test.java" naming convention, and because of that they don't run in the test suite: ./query/src/test/java/org/infinispan/query/config/MultipleCachesTests.java ./query/src/test/java/org/infinispan/query/indexedembedded/BooksExampleTests.java ./cli/cli-server/src/test/java/org/infinispan/cli/interpreter/ClusteredCLITests.java ./cachestore/jdbc/src/test/java/org/infinispan/loaders/jdbc/stringbased/JdbcStringBasedCacheStoreTest2.java ./cachestore/jdbc/src/test/java/org/infinispan/loaders/jdbc/stringbased/JdbcStringBasedCacheStoreVamTest2.java ./cachestore/jdbc/src/test/java/org/infinispan/loaders/jdbc/mixed/JdbcMixedCacheStoreTest2.java ./cachestore/jdbc/src/test/java/org/infinispan/loaders/jdbc/mixed/JdbcMixedCacheStoreVamTest2.java -- 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, 8 months

2
5
0 / 0

[JBoss JIRA] (ISPN-2323) RemoteCacheStore should optionally put/get raw values (instead of InternalCacheEntries)

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-2323: ------------------------------------- Summary: RemoteCacheStore should optionally put/get raw values (instead of InternalCacheEntries) Key: ISPN-2323 URL: https://issues.jboss.org/browse/ISPN-2323 Project: Infinispan Issue Type: Feature Request Components: Loaders and Stores Reporter: Tristan Tarrant Assignee: Tristan Tarrant Fix For: 5.2.0.Final Accessing a remote HotRod cache via a RemoteCacheManager and a RemoteCacheStore is not possible since the former stores plain values whereas the latter stores InternalCacheEntries. We should enhance the RemoteCacheStore to be able to "unwrap/wrap" cache entries -- 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, 8 months

3
9
0 / 0

[JBoss JIRA] (ISPN-2499) Configuration schema missing "versioning" tag

by Radim Vansa (JIRA)

Radim Vansa created ISPN-2499: --------------------------------- Summary: Configuration schema missing "versioning" tag Key: ISPN-2499 URL: https://issues.jboss.org/browse/ISPN-2499 Project: Infinispan Issue Type: Bug Components: Configuration Affects Versions: 5.2.0.Beta3 Reporter: Radim Vansa Assignee: Mircea Markus Priority: Minor There is no "versioning" tag in the configuration XML schema for Infinispan 5.2. Moreover, the design doc https://docs.jboss.org/author/display/ISPN/Data+Versioning contains imprecise attribute names so the only way to get the attribute names is reading source code for class Parser52. As a sidenote, using {code}<versioning enabled="true" versioninigSchema="SIMPLE" />{code} isn't the 'versioning' prefix in versioningSchema attribute redundant? Wouldn't be sufficient this? {code}<versioning enabled="true" schema="SIMPLE" />{code} (I had problems spelling versioning once, why twice) -- 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, 8 months

4
7
0 / 0

[JBoss JIRA] Created: (ISPN-1293) Enable default lifespan/maxIdle values to be used by the Hot Rod server

by Galder Zamarreño (JIRA)

Enable default lifespan/maxIdle values to be used by the Hot Rod server ----------------------------------------------------------------------- Key: ISPN-1293 URL: https://issues.jboss.org/browse/ISPN-1293 Project: Infinispan Issue Type: Enhancement Components: Cache Server Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.2.0.FINAL Hot Rod clients should be able to tell the server that no lifespan/maxIdle value was given, and so that the server should use the default lifespan+maxIdle values set in configuration. This is not currently possible in v1 of the protocol and so requires a change of protocol. This is the result of the investigation for ISPN-1285, and so when this is resolved: 1. Make sure you revert the javadoc added to ISPN-1285 to document the limitation 2. Enable and expand client/hotrod-client/src/test/java/org/infinispan/client/hotrod/ExpiryTest.java -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 8 months

4
9
0 / 0

[JBoss JIRA] (ISPN-2569) Upgrade to JGroups 3.2.4

by Dan Berindei (JIRA)

Dan Berindei created ISPN-2569: ---------------------------------- Summary: Upgrade to JGroups 3.2.4 Key: ISPN-2569 URL: https://issues.jboss.org/browse/ISPN-2569 Project: Infinispan Issue Type: Component Upgrade Components: RPC Affects Versions: 5.2.0.Beta4 Reporter: Dan Berindei Assignee: Dan Berindei Priority: Critical Fix For: 5.2.0.CR1 Upgrade to JGroups 3.2.4. This release includes a fix for JGRP-1545, which was causing some random failures in StateTransferFunctionalTest. -- 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, 8 months

2
2
0 / 0

[JBoss JIRA] (ISPN-2497) Test for DistributedExecutionCompletionService hangs, if instantiation is done by passing queue

by Anna Manukyan (JIRA)

Anna Manukyan created ISPN-2497: ----------------------------------- Summary: Test for DistributedExecutionCompletionService hangs, if instantiation is done by passing queue Key: ISPN-2497 URL: https://issues.jboss.org/browse/ISPN-2497 Project: Infinispan Issue Type: Bug Components: Distributed Execution and Map/Reduce Reporter: Anna Manukyan Assignee: Vladimir Blagojevic Hi, during writing tests for DistributedExecutionCompletionService, the following issue raised: I'm creating DistributedExecutionCompletionService with constructor protected DistributedExecutionCompletionService(DistributedExecutorService executor, BlockingQueue<NotifyingFuture<V>> completionQueue, QueueingListener listener) the constructor is protected, and my test is located in the same package. As a completionQueue I'm passing ArrayBlockingQueue, and as a listener I'm passing my created QueueingListener instance. When I submit simple callable to the service which just should return 1, and then call take() method of the completion service, the suite hangs. I've added some log for finding out whether the task is executed and listener is notified, and yes - the listener is notified and the queue is filled with the completed future task. But the take() method hangs and doesn't return the value. If I use poll() instead of take(), and poll() the completed task after waiting for some time, the returned value is null, although it is already in the completion queue. The test reproducing the issue is: https://github.com/andyuk1986/infinispan/blob/DIST_EXEC_TESTS/core/src/te... (testBasicInvocationWithBlockingQueueAndListener()). -- 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, 8 months

4
10
0 / 0

[JBoss JIRA] (ISPN-2557) IllegalStateException "Segments [a, b, c] are not owned by NodeX" in StateProviderImpl

by Adrian Nistor (JIRA)

Adrian Nistor created ISPN-2557: ----------------------------------- Summary: IllegalStateException "Segments [a,b, c] are not owned by NodeX" in StateProviderImpl Key: ISPN-2557 URL: https://issues.jboss.org/browse/ISPN-2557 Project: Infinispan Issue Type: Bug Components: State transfer Affects Versions: 5.2.0.Beta4 Reporter: Adrian Nistor Assignee: Adrian Nistor Fix For: 5.2.0.CR1 The exception is occasionally thrown either from StateProviderImpl.getTransactionsForSegments() or StateProviderImpl.startOutboundTransfer() if the requested topology is higher than the one currently installed. I lost the logs that show this occuring but by analysing these methods is pretty clear that the code is wrong. It waits until the new topology is installed but it does not refresh the CacheTopology. This bug seems to be introduced when fixing ISPN-2373. -- 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, 8 months

3
5
0 / 0

[JBoss JIRA] (ISPN-2378) IllegalMonitorStateException when using LockSupportCacheStore.loadAllKeys

by Thomas Fromm (JIRA)

Thomas Fromm created ISPN-2378: ---------------------------------- Summary: IllegalMonitorStateException when using LockSupportCacheStore.loadAllKeys Key: ISPN-2378 URL: https://issues.jboss.org/browse/ISPN-2378 Project: Infinispan Issue Type: Bug Components: Loaders and Stores Affects Versions: 5.2.0.Beta1 Reporter: Thomas Fromm Assignee: Mircea Markus Priority: Critical When accessing cache store from different threads: java.lang.IllegalMonitorStateException: attempt to unlock read lock, not locked by current thread at java.util.concurrent.locks.ReentrantReadWriteLock$Sync.unmatchedUnlockException(ReentrantReadWriteLock.java:447) at java.util.concurrent.locks.ReentrantReadWriteLock$Sync.tryReleaseShared(ReentrantReadWriteLock.java:431) at java.util.concurrent.locks.AbstractQueuedSynchronizer.releaseShared(AbstractQueuedSynchronizer.java:1340) at java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.unlock(ReentrantReadWriteLock.java:883) at org.infinispan.util.concurrent.locks.StripedLock.releaseGlobalLock(StripedLock.java:243) at org.infinispan.loaders.LockSupportCacheStore.releaseGlobalLock(LockSupportCacheStore.java:134) at org.infinispan.loaders.LockSupportCacheStore.loadAllKeys(LockSupportCacheStore.java:177) ... -- 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, 8 months

3
15
0 / 0

[JBoss JIRA] (ISPN-2531) Futures in dist.exe and map/reduce do not throw CancelllationException

by Vladimir Blagojevic (JIRA)

Vladimir Blagojevic created ISPN-2531: ----------------------------------------- Summary: Futures in dist.exe and map/reduce do not throw CancelllationException Key: ISPN-2531 URL: https://issues.jboss.org/browse/ISPN-2531 Project: Infinispan Issue Type: Bug Components: Distributed Execution and Map/Reduce Affects Versions: 5.2.0.Beta4 Reporter: Vladimir Blagojevic Assignee: Vladimir Blagojevic Fix For: 5.2.0.CR1 After submitting a task to dist.executor or invoking MapReduceTask#executeAsynchronously clients get a Future handle for the task. If task is cancelled using that Future subsequent call to Future#get should throw CancellationException -- 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, 8 months

3
4
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues November 2012