March 2018 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-9003) Clustered maxIdle expiration

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-9003?page=com.atlassian.jira.plugin.... ] Tristan Tarrant reassigned ISPN-9003: ------------------------------------- Assignee: William Burns > Clustered maxIdle expiration > ---------------------------- > > Key: ISPN-9003 > URL: https://issues.jboss.org/browse/ISPN-9003 > Project: Infinispan > Issue Type: Enhancement > Reporter: Tristan Tarrant > Assignee: William Burns > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (ISPN-2810) In REST, default values for maxIdleTimeSeconds and timeToLiveSeconds should be 0

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-2810?page=com.atlassian.jira.plugin.... ] Tristan Tarrant closed ISPN-2810. --------------------------------- Resolution: Out of Date > In REST, default values for maxIdleTimeSeconds and timeToLiveSeconds should be 0 > -------------------------------------------------------------------------------- > > Key: ISPN-2810 > URL: https://issues.jboss.org/browse/ISPN-2810 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Protocols > Affects Versions: 5.2.0.Final > Reporter: Dan Berindei > Assignee: Sebastian Łaskawiec > > Contrary to what ISPN-732 says, timeToLiveSeconds=0 and maxIdleTimeSeconds=0 are now treated correctly by the server and the entry is stored in the cache with the default lifespan/maxIdle. > But if the user PUTs or POSTs an entry and doesn't specify timeToLiveSeconds=0 and maxIdleTimeSeconds=0 explicitly, the entries are stored with infinite lifespan/maxIdle. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (ISPN-8983) Invalid Ickle query causes server exception

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-8983?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-8983: -------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 9.2.1.Final Resolution: Done Merged in master. Thanks [~gustavonalle]! > Invalid Ickle query causes server exception > ------------------------------------------- > > Key: ISPN-8983 > URL: https://issues.jboss.org/browse/ISPN-8983 > Project: Infinispan > Issue Type: Bug > Components: Remote Querying > Affects Versions: 9.2.0.Final > Reporter: Vladimir Blagojevic > Assignee: Gustavo Fernandes > Fix For: 9.2.1.Final > > > I wrote an invalid Ickle query: select id, name from Character where id:"1009148" but instead of getting an error back the server side blew up with an exception. We should catch these cases and report back to the client the cause of the error. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (ISPN-6688) PreferAvailabilityStrategy: Improve selection of segment owners after merge

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6688?page=com.atlassian.jira.plugin.... ] Dan Berindei resolved ISPN-6688. -------------------------------- Fix Version/s: 9.2.1.Final Resolution: Won't Fix Turns out mixing owners is not really feasible when conflict resolution is not enabled. Because partitions always stay available, during a merge all partition CHs will include owners for all the segments. Keeping all the owners in the CH only works with conflict resolution, otherwise most nodes will either see the value on the primary owner or the value they have locally, ignoring all the other owners. In theory we could include the number of entries per segment in the cluster recovery response, and select the node with the most entries as the primary owner, but we'd need to clear all other owners and fetch the entries from the primary. So it would end up almost as expensive as conflict resolution, riskier (if the primary owner crashes after clearing the other owners), and not that much better than selecting an existing CH. > PreferAvailabilityStrategy: Improve selection of segment owners after merge > --------------------------------------------------------------------------- > > Key: ISPN-6688 > URL: https://issues.jboss.org/browse/ISPN-6688 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 8.2.2.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.2.1.Final > > > {{PreferAvailabilityStrategy}} picks a winning CH after merge, but that CH is very likely to be the wrong one. We should improve our odds at preserving cache data by mixing CHs, and keeping from each node's response only the information about the segments it owns itself. > The downside is that {{PreferAvailabilityStrategy}} becomes tightly coupled with {{DefaultConsistentHash}}/{{ReplicatedConsistentHash}}, and users that want to add custom {{ConsistentHash}} implementations will have to re-implement {{PreferAvailabilityStrategy}}. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (ISPN-9002) LocalModeNoPassivationTest.testValuesWithEvictedEntries random failures

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-9002?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-9002: ------------------------------- Status: Open (was: New) > LocalModeNoPassivationTest.testValuesWithEvictedEntries random failures > ----------------------------------------------------------------------- > > Key: ISPN-9002 > URL: https://issues.jboss.org/browse/ISPN-9002 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 9.2.0.Final > Reporter: Dan Berindei > Assignee: William Burns > Labels: testsuite_stability > Fix For: 9.3.0.Alpha1 > > Attachments: LocalModeNoPassivationTest_ISPN-8962_preferavailabilitystrategy_20180327.log.gz > > > {noformat} > 12:59:16,370 ERROR (testng-Test:[]) [TestSuiteProgress] Test failed: org.infinispan.persistence.LocalModeNoPassivationTest.testValuesWithEvictedEntries > java.lang.AssertionError: Value: 247 was not found! > at org.testng.AssertJUnit.fail(AssertJUnit.java:59) ~[testng-6.9.9.jar:?] > at org.testng.AssertJUnit.assertTrue(AssertJUnit.java:24) ~[testng-6.9.9.jar:?] > at org.infinispan.persistence.LocalModePassivationTest.testValuesWithEvictedEntries(LocalModePassivationTest.java:203) ~[test-classes/:?] > {noformat} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (ISPN-9002) LocalModeNoPassivationTest.testValuesWithEvictedEntries random failures

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-9002?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-9002: ------------------------------- Attachment: LocalModeNoPassivationTest_ISPN-8962_preferavailabilitystrategy_20180327.log.gz > LocalModeNoPassivationTest.testValuesWithEvictedEntries random failures > ----------------------------------------------------------------------- > > Key: ISPN-9002 > URL: https://issues.jboss.org/browse/ISPN-9002 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 9.2.0.Final > Reporter: Dan Berindei > Assignee: William Burns > Labels: testsuite_stability > Fix For: 9.3.0.Alpha1 > > Attachments: LocalModeNoPassivationTest_ISPN-8962_preferavailabilitystrategy_20180327.log.gz > > > {noformat} > 12:59:16,370 ERROR (testng-Test:[]) [TestSuiteProgress] Test failed: org.infinispan.persistence.LocalModeNoPassivationTest.testValuesWithEvictedEntries > java.lang.AssertionError: Value: 247 was not found! > at org.testng.AssertJUnit.fail(AssertJUnit.java:59) ~[testng-6.9.9.jar:?] > at org.testng.AssertJUnit.assertTrue(AssertJUnit.java:24) ~[testng-6.9.9.jar:?] > at org.infinispan.persistence.LocalModePassivationTest.testValuesWithEvictedEntries(LocalModePassivationTest.java:203) ~[test-classes/:?] > {noformat} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (ISPN-9002) LocalModeNoPassivationTest.testValuesWithEvictedEntries random failures

by Dan Berindei (JIRA)

Dan Berindei created ISPN-9002: ---------------------------------- Summary: LocalModeNoPassivationTest.testValuesWithEvictedEntries random failures Key: ISPN-9002 URL: https://issues.jboss.org/browse/ISPN-9002 Project: Infinispan Issue Type: Bug Components: Test Suite - Core Affects Versions: 9.2.0.Final Reporter: Dan Berindei Assignee: William Burns Fix For: 9.3.0.Alpha1 {noformat} 12:59:16,370 ERROR (testng-Test:[]) [TestSuiteProgress] Test failed: org.infinispan.persistence.LocalModeNoPassivationTest.testValuesWithEvictedEntries java.lang.AssertionError: Value: 247 was not found! at org.testng.AssertJUnit.fail(AssertJUnit.java:59) ~[testng-6.9.9.jar:?] at org.testng.AssertJUnit.assertTrue(AssertJUnit.java:24) ~[testng-6.9.9.jar:?] at org.infinispan.persistence.LocalModePassivationTest.testValuesWithEvictedEntries(LocalModePassivationTest.java:203) ~[test-classes/:?] {noformat} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (ISPN-9001) Configuration file not well loaded when using JCachemanager with spring boot 2 and jcache

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-9001?page=com.atlassian.jira.plugin.... ] Tristan Tarrant closed ISPN-9001. --------------------------------- Resolution: Duplicate Issue > Configuration file not well loaded when using JCachemanager with spring boot 2 and jcache > ----------------------------------------------------------------------------------------- > > Key: ISPN-9001 > URL: https://issues.jboss.org/browse/ISPN-9001 > Project: Infinispan > Issue Type: Bug > Affects Versions: 9.2.0.Final > Reporter: Florian BERNARD > > I create a spring boot project on github to show the error : https://github.com/fb64/sb2-infinispan-bug -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (ISPN-8494) Clear is leaking transaction with Batching

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-8494?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-8494: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/5873 > Clear is leaking transaction with Batching > ------------------------------------------ > > Key: ISPN-8494 > URL: https://issues.jboss.org/browse/ISPN-8494 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 9.3.0.Alpha1 > > > When batching is enabled, the clear() tries to suspend the running transaction but it ends leaking the internal transaction used in the batch. > {code:java} > public void testClearInBatch() { > Cache<String, String> cache = createCache("testClearInBatch"); > cache.put("k2", "value2"); > cache.startBatch(); > cache.clear(); > cache.put("k1", "value1"); > cache.endBatch(true); > // the tx is leaked and it tries to execute the get() against a committed transaction. > AssertJUnit.assertEquals(null, cache.get("k2")); > AssertJUnit.assertEquals("value1", cache.get("k1")); > } > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (ISPN-8494) Clear is leaking transaction with Batching

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-8494?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-8494: ------------------------------ Fix Version/s: 9.3.0.Alpha1 (was: 9.3.0.Final) > Clear is leaking transaction with Batching > ------------------------------------------ > > Key: ISPN-8494 > URL: https://issues.jboss.org/browse/ISPN-8494 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 9.3.0.Alpha1 > > > When batching is enabled, the clear() tries to suspend the running transaction but it ends leaking the internal transaction used in the batch. > {code:java} > public void testClearInBatch() { > Cache<String, String> cache = createCache("testClearInBatch"); > cache.put("k2", "value2"); > cache.startBatch(); > cache.clear(); > cache.put("k1", "value1"); > cache.endBatch(true); > // the tx is leaked and it tries to execute the get() against a committed transaction. > AssertJUnit.assertEquals(null, cache.get("k2")); > AssertJUnit.assertEquals("value1", cache.get("k1")); > } > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2018