[JBoss JIRA] (ISPN-2570) DistributedExecutorService should not manage lifecycle of a client supplied ExecutorService
by Vladimir Blagojevic (JIRA)
Vladimir Blagojevic created ISPN-2570:
-----------------------------------------
Summary: DistributedExecutorService should not manage lifecycle of a client supplied ExecutorService
Key: ISPN-2570
URL: https://issues.jboss.org/browse/ISPN-2570
Project: Infinispan
Issue Type: Bug
Components: Distributed Execution and Map/Reduce
Affects Versions: 5.2.0.Beta4
Reporter: Vladimir Blagojevic
Assignee: Vladimir Blagojevic
Priority: Minor
Fix For: 5.2.0.CR1
DistributedExecutorService (DES) uses client supplied ExecutorService for local task execution, however, DES also shuts down given ExecutorService when it self gets shut down. This should not be the case. DES should not manage lifecycle of supplied ExecutorService unless specifically requested.
--
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
[JBoss JIRA] (ISPN-2496) Test for DistributedExecutionCompletionService hangs, if instantiation is done using PriorityBlockingQueue
by Anna Manukyan (JIRA)
Anna Manukyan created ISPN-2496:
-----------------------------------
Summary: Test for DistributedExecutionCompletionService hangs, if instantiation is done using PriorityBlockingQueue
Key: ISPN-2496
URL: https://issues.jboss.org/browse/ISPN-2496
Project: Infinispan
Issue Type: Bug
Components: Distributed Execution and Map/Reduce
Reporter: Anna Manukyan
Assignee: Vladimir Blagojevic
Hi,
while writing tests for DistributedExecutionCompletionService, the following issue arrised:
I'm creating DistributedExecutionCompletionService with constructor:
DistributedExecutionCompletionService(DistributedExecutorService executor, BlockingQueue<NotifyingFuture<V>> completionQueue)
If I'm passing as a completionQueue instance of ArrayBlockingQueue, then everything works properly. But if as a completionQueue I'm passing instance of PriorityBlockingQueue, then the test hangs.
It hangs on line 61 of DistributedExecutionCompletionService:
completionQueue.add((NotifyingFuture<V>)future);
You can find the test reproducing the issue here:
https://github.com/andyuk1986/infinispan/blob/DIST_EXEC_TESTS/core/src/te... (testBasicInvocationWithBlockingQueue()).
--
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
[JBoss JIRA] (ISPN-1884) expose hibernate search search factory statistics jmx
by Mathieu Lachance (JIRA)
Mathieu Lachance created ISPN-1884:
--------------------------------------
Summary: expose hibernate search search factory statistics jmx
Key: ISPN-1884
URL: https://issues.jboss.org/browse/ISPN-1884
Project: Infinispan
Issue Type: Feature Request
Components: JMX, reporting and management
Affects Versions: 5.1.1.FINAL
Reporter: Mathieu Lachance
Assignee: Manik Surtani
it is possible to add jmx hook to obtain Hibernate Search SearchFactory Statistics by using this property :
<indexing enabled="true" indexLocalOnly="true">
<properties>
<property name="hibernate.search.jmx_enabled" value="true" />
</properties>
</indexing>
tough this property does not allow multiple registration (one registration per cache).
it would be nice to wrap the Statistics object from HibernateSearch into the actual cache object mbean.
i guess the implementation could look like this :
// get search factory statistics
org.hibernate.search.stat.Statistics statistics = Search.getSearchManager(org.infinispan.Cache).getSearchFactory().getStatistics();
// wrap search factory statistics
SearchFactoryStatisticMBean mbean = new SearchFactoryStatisticMBeanImpl(statistics);
// expose mbean
ManagementFactory.getPlatformMBeanServer().registerMBean(new ObjectName("..."), mbean);
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] (ISPN-2567) ClassCastException from org.infinispan.query.impl.LifecycleManager.cacheStopping
by Adrian Nistor (JIRA)
Adrian Nistor created ISPN-2567:
-----------------------------------
Summary: ClassCastException from org.infinispan.query.impl.LifecycleManager.cacheStopping
Key: ISPN-2567
URL: https://issues.jboss.org/browse/ISPN-2567
Project: Infinispan
Issue Type: Bug
Components: Querying
Affects Versions: 5.2.0.Beta4
Reporter: Adrian Nistor
Assignee: Adrian Nistor
Fix For: 5.2.0.CR1
The object obtained from registry cannot be cast to SearchFactoryIntegrator because it was already removed and replaced with the dummy LifecycleManager.REMOVED_REGISTRY_COMPONENT.
{noformat}
2012-11-29 00:33:53,094 WARN [TestingUtil] (testng-CollectionsIndexingTest) Problems killing cache manager org.infinispan.manager.DefaultCacheManager@7e515f40@Address:null
java.lang.ClassCastException: java.lang.Object cannot be cast to org.hibernate.search.spi.SearchFactoryIntegrator
at org.infinispan.query.impl.LifecycleManager.cacheStopping(LifecycleManager.java:241)
at org.infinispan.factories.ComponentRegistry.stop(ComponentRegistry.java:221)
at org.infinispan.CacheImpl.stop(CacheImpl.java:542)
at org.infinispan.CacheImpl.stop(CacheImpl.java:537)
at org.infinispan.manager.DefaultCacheManager.stop(DefaultCacheManager.java:740)
at org.infinispan.test.TestingUtil.killCacheManagers(TestingUtil.java:645)
at org.infinispan.test.SingleCacheManagerTest.teardown(SingleCacheManagerTest.java:60)
at org.infinispan.test.SingleCacheManagerTest.destroyAfterClass(SingleCacheManagerTest.java:90)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:564)
at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:213)
at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:138)
at org.testng.internal.TestMethodWorker.invokeAfterClassMethods(TestMethodWorker.java:225)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:114)
at org.testng.TestRunner.privateRun(TestRunner.java:767)
at org.testng.TestRunner.run(TestRunner.java:617)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)
at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)
at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
2012-11-29 00:33:53,105 ERROR [TestCacheManagerFactory] (testng-CollectionsIndexingTest)
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!! (testng-CollectionsIndexingTest) Exiting because CollectionsIndexingTest has NOT shut down all the cache managers it has started !!!!!!!
!!!!!! (testng-CollectionsIndexingTest) The still-running cacheManager was created here: org.infinispan.query.indexedembedded.CollectionsIndexingTest.createCacheManager(CollectionsIndexingTest.java:61) !!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
[testng-SearchMappingTest] Test testWithoutSearchMapping(org.infinispan.query.programmaticmapping.SearchMappingTest) succeeded.
{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
[JBoss JIRA] (ISPN-2474) L1 entries should be invalidated when the key ownership changes
by Dan Berindei (JIRA)
Dan Berindei created ISPN-2474:
----------------------------------
Summary: L1 entries should be invalidated when the key ownership changes
Key: ISPN-2474
URL: https://issues.jboss.org/browse/ISPN-2474
Project: Infinispan
Issue Type: Sub-task
Components: State transfer
Affects Versions: 5.1.0.FINAL
Reporter: Dan Berindei
Assignee: Dan Berindei
Priority: Blocker
Fix For: 5.2.0.CR1
Copied from the parent:
{quote}
[...] we have thought about actually transferring the requestor information with the transaction data, but that gets complicated really quickly. (It would most likely require forwarding get commands, which would negate the benefit of having an L1 in the first place.) Instead we are going to remove L1 entries that have lost owners on each topology update (which should be a small fraction of the total L1 entries).
{quote}
--
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
[JBoss JIRA] (ISPN-2472) Transactional commands should not be forwarded to the tx originator
by Dan Berindei (JIRA)
Dan Berindei created ISPN-2472:
----------------------------------
Summary: Transactional commands should not be forwarded to the tx originator
Key: ISPN-2472
URL: https://issues.jboss.org/browse/ISPN-2472
Project: Infinispan
Issue Type: Sub-task
Components: State transfer, Transactions
Affects Versions: 5.2.0.Beta3
Reporter: Dan Berindei
Assignee: Dan Berindei
Priority: Critical
Fix For: 5.2.0.CR1
As discussed in the parent issue (ISPN-2410), transactional commands should not be forwarded back to the tx originator.
Instead, when the RPC returns, the originator should check if it needs to lock or commit extra keys (because there was a rebalance during the RPC) and do that work itself.
--
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