February 2014 - infinispan-issues

[JBoss JIRA] (ISPN-4030) Allow distributed executors to store results into cache

by Vladimir Blagojevic (JIRA)

Vladimir Blagojevic created ISPN-4030: ----------------------------------------- Summary: Allow distributed executors to store results into cache Key: ISPN-4030 URL: https://issues.jboss.org/browse/ISPN-4030 Project: Infinispan Issue Type: Feature Request Reporter: Vladimir Blagojevic Assignee: Vladimir Blagojevic -- 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-4030) Allow distributed executors to store results into cache

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-4030?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic updated ISPN-4030: -------------------------------------- Component/s: Core > Allow distributed executors to store results into cache > ------------------------------------------------------- > > Key: ISPN-4030 > URL: https://issues.jboss.org/browse/ISPN-4030 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Reporter: Vladimir Blagojevic > Assignee: Vladimir Blagojevic > -- 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-4030) Allow distributed executors to store results into cache

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-4030?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic updated ISPN-4030: -------------------------------------- Component/s: Distributed Execution and Map/Reduce > Allow distributed executors to store results into cache > ------------------------------------------------------- > > Key: ISPN-4030 > URL: https://issues.jboss.org/browse/ISPN-4030 > Project: Infinispan > Issue Type: Feature Request > Components: Core, Distributed Execution and Map/Reduce > Reporter: Vladimir Blagojevic > Assignee: Vladimir Blagojevic > -- 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-4000) Delta view logging

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4000?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-4000: ------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 7.0.0.Alpha1 Resolution: Done > Delta view logging > ------------------ > > Key: ISPN-4000 > URL: https://issues.jboss.org/browse/ISPN-4000 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Affects Versions: 6.0.1.Final > Reporter: Takayoshi Kimura > Assignee: Takayoshi Kimura > Fix For: 7.0.0.Alpha1 > > > Currently on view change the only log we have is "INFO ISPN000094: Received new cluster view". > {noformat} > 11:36:27,355 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-1,localhost-13545) ISPN000094: Received new cluster view: [localhost-7255|23] (24) [localhost-7255, localhost-51221, localhost-12479, localhost-1550, localhost-10300, localhost-11620, localhost-35337, localhost-40886, localhost-3020, localhost-51201, localhost-32626, localhost-17205, localhost-2984, localhost-45021, localhost-23189, localhost-9189, localhost-12902, localhost-38468, localhost-36454, localhost-63088 ...] > {noformat} > In a large cluster environment the view list is truncated at max.list.print_size sys prop value, 20 by default. We can increase it but it's still hard to see who is joined/left. > It would be nice to see the delta on view change, like the following: > {noformat} > 11:36:27,355 DEBUG [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-1,localhost-13545) Joined: [localhost-8582], Left: [] > {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-2203) Test AsyncAPITest.testAsyncMethodWithLifespanAndMaxIdle is unstable

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-2203?page=com.atlassian.jira.plugin.... ] Dan Berindei reassigned ISPN-2203: ---------------------------------- Assignee: Dan Berindei (was: Mircea Markus) > Test AsyncAPITest.testAsyncMethodWithLifespanAndMaxIdle is unstable > ------------------------------------------------------------------- > > Key: ISPN-2203 > URL: https://issues.jboss.org/browse/ISPN-2203 > Project: Infinispan > Issue Type: Bug > Reporter: Galder Zamarreño > Assignee: Dan Berindei > Labels: testsuite_stability > Fix For: 5.2.0.Beta2, 5.3.0.Beta2, 6.0.0.Alpha2 > > Attachments: AsyncAPITest.testAsyncMethodWithLifespanAndMaxIdle.tar.gz, testAsyncMethodWithLifespanAndMaxIdle-0.log > > > Test being disabled as part of ISPN-2196 cos it's unstable. -- 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-4029) NotifyingFutureTest.testExceptionOtherThread1 random failures

by Dan Berindei (JIRA)

Dan Berindei created ISPN-4029: ---------------------------------- Summary: NotifyingFutureTest.testExceptionOtherThread1 random failures Key: ISPN-4029 URL: https://issues.jboss.org/browse/ISPN-4029 Project: Infinispan Issue Type: Bug Components: Test Suite - Core Affects Versions: 6.0.1.Final Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 7.0.0.Final {noformat} 16:58:33,402 ERROR (testng-NotifyingFutureTest:) [UnitTestTestNGListener] Test testExceptionOtherThread1(org.infinispan.commons.util.concurrent.NotifyingFutureTest) failed. java.lang.AssertionError: expected [true] but found [false] at org.testng.Assert.fail(Assert.java:94) at org.testng.Assert.failNotEquals(Assert.java:494) at org.testng.Assert.assertTrue(Assert.java:42) at org.testng.Assert.assertTrue(Assert.java:52) at org.infinispan.commons.util.concurrent.NotifyingFutureTest.testException(NotifyingFutureTest.java:150) at org.infinispan.commons.util.concurrent.NotifyingFutureTest.testExceptionOtherThread(NotifyingFutureTest.java:67) at org.infinispan.commons.util.concurrent.NotifyingFutureTest.testExceptionOtherThread1(NotifyingFutureTest.java:46) {noformat} The test submits a task to a ThreadPoolExecutor that notifies a NotifyingFutureImpl and assumes that when the NotifyingFutureImpl is done, the original Future is also done. That's clearly not happening some of the time. -- 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-2780) org.infinispan.lucene.cacheloader.IndexCacheLoaderTest.readExistingIndexTest fails randomly on all environments

by Vojtech Juranek (JIRA)

[ https://issues.jboss.org/browse/ISPN-2780?page=com.atlassian.jira.plugin.... ] Vojtech Juranek commented on ISPN-2780: --------------------------------------- I run the tests several times on RHEL and Solaris [1], as well as on windows [2] and in all cases the tests have passed. IMHO the issue can be resolved. [1] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/infinispan-upstream-... [2] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/infinispan-upstream-... > org.infinispan.lucene.cacheloader.IndexCacheLoaderTest.readExistingIndexTest fails randomly on all environments > --------------------------------------------------------------------------------------------------------------- > > Key: ISPN-2780 > URL: https://issues.jboss.org/browse/ISPN-2780 > Project: Infinispan > Issue Type: Bug > Components: Lucene Directory > Affects Versions: 5.2.0.CR3 > Reporter: Anna Manukyan > Assignee: Sanne Grinovero > Priority: Critical > Labels: retest, stable_embedded_query, testsuite_stability > > The test org.infinispan.lucene.cacheloader.IndexCacheLoaderTest.readExistingIndexTest fails almost always on all environments. The error message is: > {code} > Error Message > String '0' should exist but was not found in index > Stacktrace > java.lang.AssertionError: String '0' should exist but was not found in index > at org.infinispan.lucene.cacheloader.IndexCacheLoaderTest.verifyOnDirectory(IndexCacheLoaderTest.java:131) > at org.infinispan.lucene.cacheloader.IndexCacheLoaderTest.verifyIndex(IndexCacheLoaderTest.java:83) > at org.infinispan.lucene.cacheloader.IndexCacheLoaderTest.readExistingIndexTest(IndexCacheLoaderTest.java:71) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80) > at org.testng.internal.Invoker.invokeMethod(Invoker.java:715) > at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:907) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1237) > at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111) > 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:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:722) > {code} -- 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-4028) jgroups-tcp.xml file does not accept JVM property replacement

by William DeCoste (JIRA)

[ https://issues.jboss.org/browse/ISPN-4028?page=com.atlassian.jira.plugin.... ] William DeCoste updated ISPN-4028: ---------------------------------- Description: Configure JGroups to use TCP via custom jgroups-tcp.xml file. Start up Library mode with -Djgroups.tcp.address=X.X.X.X. Value is not replaced in the xml. Only workaround is to hardcode the IP (or any of the default values) in the XML. Ditto replacement capabilities for: - infinispan.client.hotrod.server_list in hotrod-client.properties file - cacheFileLocation in toshiba-cache.properties was:Configure JGroups to use TCP via custom jgroups-tcp.xml file. Start up Library mode with -Djgroups.tcp.address=X.X.X.X. Value is not replaced in the xml. Only workaround is to hardcode the IP (or any of the default values) in the XML. > jgroups-tcp.xml file does not accept JVM property replacement > ------------------------------------------------------------- > > Key: ISPN-4028 > URL: https://issues.jboss.org/browse/ISPN-4028 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Affects Versions: 6.0.1.Final > Reporter: William DeCoste > Assignee: Dan Berindei > Priority: Minor > > Configure JGroups to use TCP via custom jgroups-tcp.xml file. Start up Library mode with -Djgroups.tcp.address=X.X.X.X. Value is not replaced in the xml. Only workaround is to hardcode the IP (or any of the default values) in the XML. > Ditto replacement capabilities for: > - infinispan.client.hotrod.server_list in hotrod-client.properties file > - cacheFileLocation in toshiba-cache.properties -- 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-4028) jgroups-tcp.xml file does not accept JVM property replacement

by William DeCoste (JIRA)

William DeCoste created ISPN-4028: ------------------------------------- Summary: jgroups-tcp.xml file does not accept JVM property replacement Key: ISPN-4028 URL: https://issues.jboss.org/browse/ISPN-4028 Project: Infinispan Issue Type: Feature Request Components: Core Affects Versions: 6.0.1.Final Reporter: William DeCoste Assignee: Dan Berindei Priority: Minor Configure JGroups to use TCP via custom jgroups-tcp.xml file. Start up Library mode with -Djgroups.tcp.address=X.X.X.X. Value is not replaced in the xml. Only workaround is to hardcode the IP (or any of the default values) in the XML. -- 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-3999) Invoke reducer immediatelly as intermediate VOut values are being collected

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-3999?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic updated ISPN-3999: -------------------------------------- Description: Currently in intermediate phase [1] as values for every KOut are being collected/grouped in the cluster we simply add every VOut to the list of values keyed by KOut. In reducer phase we then send a reducer function that gets invoked on List<VOut> and reduces those values into single VOut. However, this could be suboptimal as we can invoke reducer function as every VOut gets grouped rather than wait for all VOut values to be collected and then invoke reducers. However, reduce function could potentially take a lot of time to execute even for one value thus causing prolonged locking and congestions. We should implement this enhancement and do thorough performance measurements. This feature should be have an API setting in MapReduceTask. Sanne Grinovero gets the credit for this idea. [1] http://blog.infinispan.org/2012/07/mapreduce-improvements-in-infinispan.html was: Currently in intermediate phase [1] as values for every KOut are being collected/grouped in the cluster we simply add every VOut to the list of values key by KOut. In reducer phase we then send a reducer function that gets invoked on List<VOut> and reduces those values into single VOut. However, this could be suboptimal as we can invoke reducer function as every VOut gets grouped rather than wait for all VOut values to be collected and then invoke reducer. However, reduce function could potentially take a lot of time to execute even for one value thus causing prolonged locking and congestions. We should implement this enhancement and do thorough performance measurements. This feature should be have an API setting in MapReduceTask. Sanne Grinovero gets the credit for this idea. [1] http://blog.infinispan.org/2012/07/mapreduce-improvements-in-infinispan.html > Invoke reducer immediatelly as intermediate VOut values are being collected > --------------------------------------------------------------------------- > > Key: ISPN-3999 > URL: https://issues.jboss.org/browse/ISPN-3999 > Project: Infinispan > Issue Type: Enhancement > Reporter: Vladimir Blagojevic > Assignee: Vladimir Blagojevic > Priority: Minor > > Currently in intermediate phase [1] as values for every KOut are being collected/grouped in the cluster we simply add every VOut to the list of values keyed by KOut. In reducer phase we then send a reducer function that gets invoked on List<VOut> and reduces those values into single VOut. However, this could be suboptimal as we can invoke reducer function as every VOut gets grouped rather than wait for all VOut values to be collected and then invoke reducers. However, reduce function could potentially take a lot of time to execute even for one value thus causing prolonged locking and congestions. We should implement this enhancement and do thorough performance measurements. This feature should be have an API setting in MapReduceTask. > Sanne Grinovero gets the credit for this idea. > [1] http://blog.infinispan.org/2012/07/mapreduce-improvements-in-infinispan.html -- 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 February 2014