August 2016 - infinispan-issues - Jboss List Archives

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

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-6688?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-6688: -------------------------------- Fix Version/s: 9.0.0.Beta1 (was: 9.0.0.Alpha4) > 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.0.0.Beta1, 9.0.0.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 (v6.4.11#64026)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6798) Examples of JDBC CacheStore configuration should remind about the shared attribute

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-6798?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-6798: -------------------------------- Fix Version/s: 9.0.0.Beta1 (was: 9.0.0.Alpha4) > Examples of JDBC CacheStore configuration should remind about the shared attribute > ---------------------------------------------------------------------------------- > > Key: ISPN-6798 > URL: https://issues.jboss.org/browse/ISPN-6798 > Project: Infinispan > Issue Type: Enhancement > Components: Configuration, Documentation-Core > Reporter: Sanne Grinovero > Priority: Minor > Fix For: 9.0.0.Beta1 > > > The "shared" configuration attribute is defaulting to _false_ even for database-based CacheStore instances as the attribute is defined in the parent of all {{CacheStore}} types. > The attribute isn't very visible either, as it's not explicitly listed among the available attributes (because it's inherited), and I think this is quite confusing as - while a non-shared configuration could be a choice - there's a strong assumption and expectation that these will point to a shared relational database. > I'd suggest to: > - add a highlighted reminder about this > - set the attribute explicitly in all example configurations > See also: > - http://stackoverflow.com/questions/37949448/duplicate-record-errors-in-hi... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6767) Upgrade to Hibernate ORM 5.2.1.Final

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-6767?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-6767: -------------------------------- Fix Version/s: 9.0.0.Beta1 (was: 9.0.0.Alpha4) > Upgrade to Hibernate ORM 5.2.1.Final > ------------------------------------ > > Key: ISPN-6767 > URL: https://issues.jboss.org/browse/ISPN-6767 > Project: Infinispan > Issue Type: Component Upgrade > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Fix For: 9.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6766) hot rod client: RemoteCache.removeClient method does not remove the listener from the list after server restart

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-6766?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-6766: -------------------------------- Fix Version/s: 9.0.0.Beta1 (was: 9.0.0.Alpha4) > hot rod client: RemoteCache.removeClient method does not remove the listener from the list after server restart > --------------------------------------------------------------------------------------------------------------- > > Key: ISPN-6766 > URL: https://issues.jboss.org/browse/ISPN-6766 > Project: Infinispan > Issue Type: Bug > Components: Listeners, Remote Protocols > Affects Versions: 8.2.1.Final > Reporter: Eli Z > Priority: Minor > Fix For: 9.0.0.Beta1 > > > After registering a client listener in the client and then restarting the infinispan server --> The original listener object can not be removed from the client listener list by using the method RemoteCache.removeClient(Object listener) --> after calling this method and then get all listeners, i still see the old listener in the list. > By doing a little debug, it seems that in class RemoveClientListenerOperation.execute when trying to remove from the server and a failure status is returned (probably due to the fact the the server after the restart does not know this listener id) the listener is not removed from the list eventually. the line this.listenerNotifier.removeClientListener(listenerId); is not executed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6745) Locks are lost in pessimistic cache

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-6745?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-6745: -------------------------------- Fix Version/s: 9.0.0.Beta1 (was: 9.0.0.Alpha4) > Locks are lost in pessimistic cache > ----------------------------------- > > Key: ISPN-6745 > URL: https://issues.jboss.org/browse/ISPN-6745 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.2.3.Final > Environment: JBoss DataGrid 6.5.0 (6.3.1.Final-redhat-1) > 3 nodes in REPL_SYNC mode > pessimistic locking > read committed isolation > Reporter: Eugene Scripnik > Assignee: Pedro Ruivo > Fix For: 9.0.0.Beta1, 8.2.4.Final > > Attachments: InfinispanNodeFailureTest.java > > > When you perform multiple TX write operations in one transaction (put, replace, lock, etc) and one of the nodes goes down, there is a slight chance that some locks will be lost and acquired by another transaction before current transaction ends. > So client ends up with two transactions holding the same lock on pessimistic cache at the same time. Both transactions commit at the end successfully. > I spent some time debugging infinispan code and found that PessimisticLockingInterceptor#releaseLocksOnFailureBeforePrepare releases all locks when OutdatedTopologyException occurs on remote node. But then StateTransferInterceptor#handleTxWriteCommand retries last command. This behavior produces inconsistent state - all locks before last command are released and any other transaction can acquire them. > I am attaching Test which reproduces this problem -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6724) Modules scripting and infinispan directory provider use the same logging id range

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-6724?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-6724: -------------------------------- Fix Version/s: 9.0.0.Beta1 (was: 9.0.0.Alpha4) > Modules scripting and infinispan directory provider use the same logging id range > --------------------------------------------------------------------------------- > > Key: ISPN-6724 > URL: https://issues.jboss.org/browse/ISPN-6724 > Project: Infinispan > Issue Type: Bug > Reporter: Adrian Nistor > Fix For: 9.0.0.Beta1, 9.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6803) Precompute a bitset for each flag

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-6803?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-6803: -------------------------------- Fix Version/s: 9.0.0.Beta1 (was: 9.0.0.Alpha4) > Precompute a bitset for each flag > --------------------------------- > > Key: ISPN-6803 > URL: https://issues.jboss.org/browse/ISPN-6803 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 9.0.0.Alpha2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.0.0.Beta1 > > > Commands now use keep track of flags as "bitsets" that are actually {{long}}. > However, flag checks still refer to the {{Flag}} instances themselves, and because the ordinal is not a static field, it cannot be optimized away by HotSpot. We can avoid that by precomputing a bitset for each flag, and making it {{static final}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6802) Micro-optimizations for read operations

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-6802?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-6802: -------------------------------- Fix Version/s: 9.0.0.Beta1 (was: 9.0.0.Alpha4) > Micro-optimizations for read operations > --------------------------------------- > > Key: ISPN-6802 > URL: https://issues.jboss.org/browse/ISPN-6802 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 9.0.0.Alpha2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.0.0.Beta1 > > > * L1 entries are written to the data container by L1TxInterceptor/L1NonTxInterceptor directly, so there is no reason to commit the context entries in EntryWrappingInterceptor or to clear the locks in the locking interceptors. > * ClearCommands can no longer be wrapped in PrepareCommands, so we can stop the state transfer in {{EntryWrappingInterceptor.visitClearCommand()}} instead of checking the type for each command. > * In transactional caches, a read operation without an explicit transaction triggers two queries for the current transaction to the transaction manager, which usually means 2 thread-local lookups. > * IsMarshallerInterceptor shouldn't do anything unless there is an asynchronous store > * Transactional remote get commands use NonTxInvocationInterceptor instead of SingleKeyNonTxInterceptor. > * Configuration attributes should be cached, as reading them requires accessing multiple instances + a cast in Attribute.get() -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6827) ReplTotalOrderVersionedStateTransferTest.testStateTransfer random failures

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-6827?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-6827: -------------------------------- Fix Version/s: 9.0.0.Beta1 (was: 9.0.0.Alpha4) > ReplTotalOrderVersionedStateTransferTest.testStateTransfer random failures > --------------------------------------------------------------------------- > > Key: ISPN-6827 > URL: https://issues.jboss.org/browse/ISPN-6827 > Project: Infinispan > Issue Type: Bug > Components: Core, Test Suite - Core > Affects Versions: 9.0.0.Alpha2 > Reporter: Dan Berindei > Priority: Critical > Labels: testsuite_stability > Fix For: 9.0.0.Beta1 > > Attachments: ReplTotalOrderVersionedStateTransferTest_pr_rvansa_ISPN-5989_20160314.log.zip > > > {noformat} > java.lang.RuntimeException: Timed out waiting for rebalancing to complete on node ReplTotalOrderVersionedStateTransferTest-NodeB-17608, expected member list is [ReplTotalOrderVersionedStateTransferTest-NodeB-17608, ReplTotalOrderVersionedStateTransferTest-NodeC-39826], current member list is [ReplTotalOrderVersionedStateTransferTest-NodeA-54647, ReplTotalOrderVersionedStateTransferTest-NodeB-17608, ReplTotalOrderVersionedStateTransferTest-NodeC-39826]! > at org.infinispan.test.TestingUtil.waitForRehashToComplete(TestingUtil.java:267) > at org.infinispan.test.TestingUtil.waitForRehashToComplete(TestingUtil.java:277) > at org.infinispan.container.versioning.VersionedReplStateTransferTest.testStateTransfer(VersionedReplStateTransferTest.java:74) > {noformat} > http://ci.infinispan.org/project.html?tab=testDetails&testNameId=-7264982... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6819) SharedStoreInvalidationDuringRehashTest.testRehashWith[out]Preload random failures

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-6819?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-6819: -------------------------------- Fix Version/s: 9.0.0.Beta1 (was: 9.0.0.Alpha4) > SharedStoreInvalidationDuringRehashTest.testRehashWith[out]Preload random failures > ---------------------------------------------------------------------------------- > > Key: ISPN-6819 > URL: https://issues.jboss.org/browse/ISPN-6819 > Project: Infinispan > Issue Type: Bug > Components: Core, Test Suite - Core > Affects Versions: 9.0.0.Alpha2 > Reporter: Dan Berindei > Priority: Critical > Labels: testsuite_stability > Fix For: 9.0.0.Beta1 > > > {noformat} > java.lang.AssertionError: expected:<0> but was:<3> > at org.testng.AssertJUnit.fail(AssertJUnit.java:59) > at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364) > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80) > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:245) > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:252) > at org.infinispan.distribution.rehash.SharedStoreInvalidationDuringRehashTest.checkContentAndInvalidations(SharedStoreInvalidationDuringRehashTest.java:213) > at org.infinispan.distribution.rehash.SharedStoreInvalidationDuringRehashTest.doTest(SharedStoreInvalidationDuringRehashTest.java:135) > at org.infinispan.distribution.rehash.SharedStoreInvalidationDuringRehashTest.testRehashWithoutPreload(SharedStoreInvalidationDuringRehashTest.java:122) > {noformat} > http://ci.infinispan.org/project.html?tab=testDetails&testNameId=-7068250... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues August 2016