July 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-159) Extended coalesced logic to other parts

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-159?page=com.atlassian.jira.plugin.s... ] Mircea Markus updated ISPN-159: ------------------------------- Fix Version/s: (was: 6.0.0.Final) > Extended coalesced logic to other parts > --------------------------------------- > > Key: ISPN-159 > URL: https://issues.jboss.org/browse/ISPN-159 > Project: Infinispan > Issue Type: Feature Request > Components: RPC, Transactions > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > > Reuse same coalesced async cache store logic to: > - Reduce size of replicable commands where N modifications are sent so that only latest state is sent. > - Manage the async replication queue. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3037) Failing test: MixedModeTest.testMixedMode:72 NullPointer

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3037?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3037: -------------------------------- Labels: testsuite_stability (was: ) > Failing test: MixedModeTest.testMixedMode:72 NullPointer > -------------------------------------------------------- > > Key: ISPN-3037 > URL: https://issues.jboss.org/browse/ISPN-3037 > Project: Infinispan > Issue Type: Bug > Reporter: Sanne Grinovero > Assignee: Mircea Markus > Labels: testsuite_stability > Fix For: 6.0.0.Alpha1 > > > ~~~~~~~~~~~~~~~~~~~~~~~~~ ENVIRONMENT INFO ~~~~~~~~~~~~~~~~~~~~~~~~~~ > jgroups.bind_addr = 127.0.0.1 > java.runtime.version = 1.6.0_43-b01 > java.runtime.name =Java(TM) SE Runtime Environment > java.vm.version = 20.14-b01 > java.vm.vendor = Sun Microsystems Inc. > os.name = Linux > os.version = 3.8.8-202.fc18.x86_64 > sun.arch.data.model = 64 > sun.cpu.endian = little > protocol.stack = null > infinispan.test.jgroups.protocol = tcp > infinispan.unsafe.allow_jdk8_chm = true > java.net.preferIPv4Stack = true > java.net.preferIPv6Stack = null > log4.configuration = null > MAVEN_OPTS = null > ~~~~~~~~~~~~~~~~~~~~~~~~~ ENVIRONMENT INFO ~~~~~~~~~~~~~~~~~~~~~~~~~~ > Tests run: 2911, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 212.448 sec <<< FAILURE! > testMixedMode(org.infinispan.api.MixedModeTest) Time elapsed: 0.03 sec <<< FAILURE! > java.lang.NullPointerException > at org.infinispan.api.MixedModeTest.testMixedMode(MixedModeTest.java:72) > 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.invokeMethod(Invoker.java:714) > at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231) > 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:303) > at java.util.concurrent.FutureTask.run(FutureTask.java:138) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) > at java.lang.Thread.run(Thread.java:662) > Results : > Failed tests: > MixedModeTest.testMixedMode:72 NullPointer > Tests run: 2911, Failures: 1, Errors: 0, Skipped: 0 -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2649) Extend PutMapCommandTest to test with optimistic caches and write skew check

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2649?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2649: -------------------------------- Fix Version/s: (was: 6.0.0.Alpha1) > Extend PutMapCommandTest to test with optimistic caches and write skew check > ---------------------------------------------------------------------------- > > Key: ISPN-2649 > URL: https://issues.jboss.org/browse/ISPN-2649 > Project: Infinispan > Issue Type: Task > Components: Core API > Affects Versions: 5.2.0.Beta5 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > > There is no evidence yet that write skew check is properly performed for PutMapCommand in clustered mode. Need to cover this with a unit test. > What worries me is the BaseDistributionInterceptor.visitPutMapCommand() method calls handleWriteCommand() with parameter skipRemoteGet==true. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3189) Extend Grouping API to mapping of DeltaCompositeKeys to the same node as the delta aware value key

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3189?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3189: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > Extend Grouping API to mapping of DeltaCompositeKeys to the same node as the delta aware value key > -------------------------------------------------------------------------------------------------- > > Key: ISPN-3189 > URL: https://issues.jboss.org/browse/ISPN-3189 > Project: Infinispan > Issue Type: Enhancement > Components: Fine-grained API > Affects Versions: 5.3.0.CR1 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Priority: Minor > > Try to understand and analyze the performance impact to extended the Grouping API to support the DeltaCompositeKey and return the owners based on the delta aware value key. > In the current implementation, the interceptors are responsible to check if the key is a DeltaCompositeKey instance and check for the ownership based on the delta aware value key. > Pros and cons of using an extension of Grouping API > Pros: > * this check for DeltaCompositeKey instance is done in a single point instead of being spread in the code. > * less error prone > Cons: > * possible performance impact since all the getSegment(key) invocations should perform the check. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-863) Eviction based on JVM memory utilization

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-863?page=com.atlassian.jira.plugin.s... ] Mircea Markus updated ISPN-863: ------------------------------- Fix Version/s: (was: 6.0.0.Final) > Eviction based on JVM memory utilization > ---------------------------------------- > > Key: ISPN-863 > URL: https://issues.jboss.org/browse/ISPN-863 > Project: Infinispan > Issue Type: Enhancement > Components: Eviction > Affects Versions: 4.2.0.Final > Environment: N/A > Reporter: Dave Marion > Assignee: Manik Surtani > Labels: eviction, threshold > > Allow user to specify percentage threshold upon which eviction will kick in and begin evicting entries based on the specified strategy. This would allow user to create a cache that will attempt to keep as many entries in memory as possible without having to specify maxEntries. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2284) Execute Mapper and Reducer tasks in parallel where possible

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2284?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2284: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > Execute Mapper and Reducer tasks in parallel where possible > ----------------------------------------------------------- > > Key: ISPN-2284 > URL: https://issues.jboss.org/browse/ISPN-2284 > Project: Infinispan > Issue Type: Feature Request > Components: Distributed Execution and Map/Reduce > Affects Versions: 5.2.0.Alpha3 > Reporter: Vladimir Blagojevic > Assignee: Vladimir Blagojevic > Attachments: Infinispan-MapReduce Job Times.png > > > In our current implementation of Map/Reduce, Mapper and Reducer tasks executed on remote JVMs load and process key/values serially on a single thread. Where and if possible we should use executors to process keys/values in parallel. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2438) Executor services are configured to abort submitted tasks if all threads are busy and the queue is full

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2438?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2438: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > Executor services are configured to abort submitted tasks if all threads are busy and the queue is full > ------------------------------------------------------------------------------------------------------- > > Key: ISPN-2438 > URL: https://issues.jboss.org/browse/ISPN-2438 > Project: Infinispan > Issue Type: Feature Request > Affects Versions: 5.2.0.Beta2 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > > This is the default, but a better approach would be to block rather than abort. We need a RejectedExecutionHandler similar to org.hibernate.search.batchindexing.impl.Executors.BlockPolicy -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-445) Ensure that locks time out

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-445?page=com.atlassian.jira.plugin.s... ] Mircea Markus commented on ISPN-445: ------------------------------------ Have a background thread that would either warn on locks being acquired for too long (configurable) or even release them (config option). > Ensure that locks time out > -------------------------- > > Key: ISPN-445 > URL: https://issues.jboss.org/browse/ISPN-445 > Project: Infinispan > Issue Type: Feature Request > Components: Locking and Concurrency > Reporter: Philippe Van Dyck > Assignee: Manik Surtani > Fix For: 6.0.0.Final > > > When a lock is acquired, no mechanism ensure that it is reclaimed later. > So if for whatever reason the thread owning the lock is stuck in an endless loop or waiting for some resource, the entry is locked. This kind of situation could happen in cache stores trying to contact a remote storage. > The risk is quite high that other entries may be locked as well if you use lock stripping (default : TRUE) -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-445) Ensure that locks time out

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-445?page=com.atlassian.jira.plugin.s... ] Mircea Markus updated ISPN-445: ------------------------------- Fix Version/s: (was: 6.0.0.Final) > Ensure that locks time out > -------------------------- > > Key: ISPN-445 > URL: https://issues.jboss.org/browse/ISPN-445 > Project: Infinispan > Issue Type: Feature Request > Components: Locking and Concurrency > Reporter: Philippe Van Dyck > Assignee: Manik Surtani > > When a lock is acquired, no mechanism ensure that it is reclaimed later. > So if for whatever reason the thread owning the lock is stuck in an endless loop or waiting for some resource, the entry is locked. This kind of situation could happen in cache stores trying to contact a remote storage. > The risk is quite high that other entries may be locked as well if you use lock stripping (default : TRUE) -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2107) Enable logging for all modules' test suites

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2107?page=com.atlassian.jira.plugin.... ] Mircea Markus resolved ISPN-2107. --------------------------------- Fix Version/s: (was: 6.0.0.Final) Resolution: Rejected using -Dlog4j.configuration runs each module with the supplied log4j configuration file. > Enable logging for all modules' test suites > ------------------------------------------- > > Key: ISPN-2107 > URL: https://issues.jboss.org/browse/ISPN-2107 > Project: Infinispan > Issue Type: Task > Components: Test Suite > Affects Versions: 5.1.5.FINAL > Reporter: Dan Berindei > Assignee: Mircea Markus > > Some modules do not log anything, not even to the console, because they don't have a {{log4j.xml}} file in their classpath (e.g. cdi). Because of this, errors in jenkins are harder to spot and to fix. > We should ensure that each module has a log4j configuration file in the test classpath (or maybe use a system property to configure a generic log4j.xml in the root directory). Preferably each module should have its own log file, but they could use the same log file as long as they don't truncate it. -- 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, 9 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues July 2013