June 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-5497) MetadataAPIDefaultExpiryTest.testDefaultLifespanReplaceWithOldValue and MetadataAPIDefaultExpiryTest.testDefaultLifespanPutIfAbsent fail randomly

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5497?page=com.atlassian.jira.plugin.... ] Dan Berindei reassigned ISPN-5497: ---------------------------------- Assignee: Dan Berindei > MetadataAPIDefaultExpiryTest.testDefaultLifespanReplaceWithOldValue and MetadataAPIDefaultExpiryTest.testDefaultLifespanPutIfAbsent fail randomly > ------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-5497 > URL: https://issues.jboss.org/browse/ISPN-5497 > Project: Infinispan > Issue Type: Bug > Affects Versions: 7.2.1.Final > Reporter: Roman Macor > Assignee: Dan Berindei > > MetadataAPIDefaultExpiryTest.testDefaultLifespanPutIfAbsent and MetadataAPIDefaultExpiryTest.testDefaultLifespanReplaceWithOldValue fail randomly with assertion error > org.infinispan.api.MetadataAPIDefaultExpiryTest.testDefaultLifespanReplaceWithOldValue > Error Message > expected:<v11> but was:<null> > Stacktrace > java.lang.AssertionError: expected:<v11> but was:<null> > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:101) > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:108) > at org.infinispan.api.MetadataAPIDefaultExpiryTest.expectCachedThenExpired(MetadataAPIDefaultExpiryTest.java:85) > at org.infinispan.api.MetadataAPIDefaultExpiryTest.testDefaultLifespanReplaceWithOldValue(MetadataAPIDefaultExpiryTest.java:49) > 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:606) > 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.run(FutureTask.java:262) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) > org.infinispan.api.MetadataAPIDefaultExpiryTest.testDefaultLifespanPutIfAbsent > Error Message > expected:<v1> but was:<null> > Stacktrace > java.lang.AssertionError: expected:<v1> but was:<null> > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:101) > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:108) > at org.infinispan.api.MetadataAPIDefaultExpiryTest.expectCachedThenExpired(MetadataAPIDefaultExpiryTest.java:85) > at org.infinispan.api.MetadataAPIDefaultExpiryTest.testDefaultLifespanPutIfAbsent(MetadataAPIDefaultExpiryTest.java:57) > 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:606) > 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.run(FutureTask.java:262) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5526) Replication: The DELTA_WRITE flag should force a remote get during state transfer

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5526?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5526: ----------------------------------------------- dereed(a)redhat.com changed the Status of [bug 1228780|https://bugzilla.redhat.com/show_bug.cgi?id=1228780] from ASSIGNED to MODIFIED > Replication: The DELTA_WRITE flag should force a remote get during state transfer > --------------------------------------------------------------------------------- > > Key: ISPN-5526 > URL: https://issues.jboss.org/browse/ISPN-5526 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.2.10.Final > Reporter: Dennis Reed > Assignee: Ryan Emerson > Priority: Critical > Fix For: 5.2.13.Final > > > Same issue as ISPN-3184, but for repl caches in Infinispan 5.2.x. > (ISPN-3184 only fixed dist caches, since repl uses the same code in 5.3+). > AtomicHashMap and FineGrainedAtomicHashMap, as well as custom DeltaAware implementations, use PutKeyValueCommands with the DELTA_WRITE flag to execute incremental updates. These commands need the previous value of the entry in order to work. > If a node is joining and it receives a PutKeyValueCommand with the DELTA_WRITE flag before it has received the value of the affected key, it should do a remote get to retrieve the previous value and apply the change on top of that value, just like we do for conditional commands. Not doing so leads to data loss. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5393) Support mixed indexed and non-indexed fields in DSL based queries

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-5393?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-5393: -------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/3544 > Support mixed indexed and non-indexed fields in DSL based queries > ----------------------------------------------------------------- > > Key: ISPN-5393 > URL: https://issues.jboss.org/browse/ISPN-5393 > Project: Infinispan > Issue Type: Enhancement > Components: Embedded Querying > Affects Versions: 7.0.0.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > > If a query uses both indexed and non-indexed fields we should be able to execute it in two phases. A fist less selective query on the index and then post process it by reapplying the whole filter again to results of the first phase. > This should be more efficient than completely ignoring the indexed fields and executing the non-indexed query on the whole data set. > A possible idea to derive the query to be executed in first phase is to apply the Boole-Shannon expansion theorem ([http://en.wikipedia.org/wiki/Boole%27s_expansion_theorem]). -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5549) JPACacheStore should be able to lookup a container manager Persistence Unit

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5549?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-5549: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1223290 > JPACacheStore should be able to lookup a container manager Persistence Unit > --------------------------------------------------------------------------- > > Key: ISPN-5549 > URL: https://issues.jboss.org/browse/ISPN-5549 > Project: Infinispan > Issue Type: Feature Request > Components: Loaders and Stores > Reporter: Sanne Grinovero > > The current {{JpaStore}} implementation starts all its {{EntityManagerFactory}} instances by using the Java SE recommended method, but this has several limitations: > - it's likely a duplicated persistence unit as the container will start one as well > - duplication leads to name clashes and lack of statistics in dashboards > - the container won't inject special features, such as the appropriate JTA context > - custom extensions from the container, like on WildFly you get a better scanner > - better integration with datasources > - Infinispan does a poor job in managing the lifecycle of its custom starte PU (not shutting it down) > - several containers apply some customizations to get Hibernate to work best (or at all) on them, you'd bypassing these compatibility fixes -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5550) Failing to start Infinispan, started components like JPACacheStore are not closed

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5550?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-5550: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1223290 > Failing to start Infinispan, started components like JPACacheStore are not closed > --------------------------------------------------------------------------------- > > Key: ISPN-5550 > URL: https://issues.jboss.org/browse/ISPN-5550 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Reporter: Sanne Grinovero > > A misconfiguration or bug which fails Infinispan's Cache Container to start correctly will not have the core lifecycle shutdown and cleanup all resources which have been started. > In the case of the {{JPACacheStore}}, this could include database connection pools and it's critical to get these resources disposed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5550) Failing to start Infinispan, started components like JPACacheStore are not closed

by Sanne Grinovero (JIRA)

Sanne Grinovero created ISPN-5550: ------------------------------------- Summary: Failing to start Infinispan, started components like JPACacheStore are not closed Key: ISPN-5550 URL: https://issues.jboss.org/browse/ISPN-5550 Project: Infinispan Issue Type: Bug Components: Loaders and Stores Reporter: Sanne Grinovero A misconfiguration or bug which fails Infinispan's Cache Container to start correctly will not have the core lifecycle shutdown and cleanup all resources which have been started. In the case of the {{JPACacheStore}}, this could include database connection pools and it's critical to get these resources disposed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5549) JPACacheStore should be able to lookup a container manager Persistence Unit

by Sanne Grinovero (JIRA)

Sanne Grinovero created ISPN-5549: ------------------------------------- Summary: JPACacheStore should be able to lookup a container manager Persistence Unit Key: ISPN-5549 URL: https://issues.jboss.org/browse/ISPN-5549 Project: Infinispan Issue Type: Feature Request Components: Loaders and Stores Reporter: Sanne Grinovero The current {{JpaStore}} implementation starts all its {{EntityManagerFactory}} instances by using the Java SE recommended method, but this has several limitations: - it's likely a duplicated persistence unit as the container will start one as well - duplication leads to name clashes and lack of statistics in dashboards - the container won't inject special features, such as the appropriate JTA context - custom extensions from the container, like on WildFly you get a better scanner - better integration with datasources - Infinispan does a poor job in managing the lifecycle of its custom starte PU (not shutting it down) - several containers apply some customizations to get Hibernate to work best (or at all) on them, you'd bypassing these compatibility fixes -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4998) Infinispan 7 MapReduce giving inconsistent results

by Jakub Markos (JIRA)

[ https://issues.jboss.org/browse/ISPN-4998?page=com.atlassian.jira.plugin.... ] Jakub Markos commented on ISPN-4998: ------------------------------------ Hi, I tried replicating this issue with no luck, with both 7.0.0.Final and current snapshot. If it is still relevant to you, could you provide a reproducer or more info about your use case? > Infinispan 7 MapReduce giving inconsistent results > -------------------------------------------------- > > Key: ISPN-4998 > URL: https://issues.jboss.org/browse/ISPN-4998 > Project: Infinispan > Issue Type: Bug > Components: Distributed Execution and Map/Reduce > Affects Versions: 7.0.0.Final > Reporter: Vijay Bhoomireddy > Priority: Blocker > > Hi, > We are using Infinispan Map Reduce for processing our datasets that are spread across nodes in the cluster. We are seeing some surprising results when Infinispan 7 is used. To provide the context, our input data contains 10965 records. When Map Reduce from Infinispan 6.0.2 is used, both Mapper and Reducer are seeing 10965 records and are processing the same. However, with the same code and input data, Infinispan 7 MR gives different results for different invocations of the program. For one run, it gave output as 10902 records and the next run it gave 10872 records. Results seem inconsistent across invocations. > Not sure is this is an issue with the version7 of the framework. Any help would be greatly appreciated. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5526) Replication: The DELTA_WRITE flag should force a remote get during state transfer

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5526?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5526: ------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 5.2.13.Final Resolution: Done > Replication: The DELTA_WRITE flag should force a remote get during state transfer > --------------------------------------------------------------------------------- > > Key: ISPN-5526 > URL: https://issues.jboss.org/browse/ISPN-5526 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.2.10.Final > Reporter: Dennis Reed > Assignee: Ryan Emerson > Priority: Critical > Fix For: 5.2.13.Final > > > Same issue as ISPN-3184, but for repl caches in Infinispan 5.2.x. > (ISPN-3184 only fixed dist caches, since repl uses the same code in 5.3+). > AtomicHashMap and FineGrainedAtomicHashMap, as well as custom DeltaAware implementations, use PutKeyValueCommands with the DELTA_WRITE flag to execute incremental updates. These commands need the previous value of the entry in order to work. > If a node is joining and it receives a PutKeyValueCommand with the DELTA_WRITE flag before it has received the value of the affected key, it should do a remote get to retrieve the previous value and apply the change on top of that value, just like we do for conditional commands. Not doing so leads to data loss. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5526) Replication: The DELTA_WRITE flag should force a remote get during state transfer

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5526?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5526: ------------------------------- Status: Pull Request Sent (was: Open) > Replication: The DELTA_WRITE flag should force a remote get during state transfer > --------------------------------------------------------------------------------- > > Key: ISPN-5526 > URL: https://issues.jboss.org/browse/ISPN-5526 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.2.10.Final > Reporter: Dennis Reed > Assignee: Ryan Emerson > Priority: Critical > > Same issue as ISPN-3184, but for repl caches in Infinispan 5.2.x. > (ISPN-3184 only fixed dist caches, since repl uses the same code in 5.3+). > AtomicHashMap and FineGrainedAtomicHashMap, as well as custom DeltaAware implementations, use PutKeyValueCommands with the DELTA_WRITE flag to execute incremental updates. These commands need the previous value of the entry in order to work. > If a node is joining and it receives a PutKeyValueCommand with the DELTA_WRITE flag before it has received the value of the affected key, it should do a remote get to retrieve the previous value and apply the change on top of that value, just like we do for conditional commands. Not doing so leads to data loss. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 7 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues June 2015