December 2016 - infinispan-issues

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

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6803?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-6803: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/4734 > 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.Beta2 > > > 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 (v7.2.3#72005)

7 years, 4 months

1
0
0 / 0

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

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6802?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-6802: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/4732 > 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.Beta2 > > > * 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 (v7.2.3#72005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3731) Multicast messages can be replayed to new node

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3731?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3731: ----------------------------------------------- Miroslav Sochurek <msochure(a)redhat.com> changed the Status of [bug 1385162|https://bugzilla.redhat.com/show_bug.cgi?id=1385162] from POST to MODIFIED > Multicast messages can be replayed to new node > ---------------------------------------------- > > Key: ISPN-3731 > URL: https://issues.jboss.org/browse/ISPN-3731 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.0.Final > Reporter: Radim Vansa > Assignee: Dan Berindei > Priority: Critical > Labels: 620, 630, 630betablocker > Fix For: 6.0.1.Final, 7.0.0.Alpha1, 7.0.0.Final > > > Messages that target all current members are sent as multicast messages. > However, these retransmissions can be replayed on new nodes that have just joined the cluster. > This can result for example in execution of already completed transaction on the new node, causing possible data inconsistency for those entries which are owned by the new node in backup way - the replayed transaction sequence authoritatively overwrites them. > The node should remember the first topologyId it has seen and do not execute any commands that have lower topologyId. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2577) Silence SuspectExceptions

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2577?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-2577: ----------------------------------------------- Miroslav Sochurek <msochure(a)redhat.com> changed the Status of [bug 1385162|https://bugzilla.redhat.com/show_bug.cgi?id=1385162] from POST to MODIFIED > Silence SuspectExceptions > ------------------------- > > Key: ISPN-2577 > URL: https://issues.jboss.org/browse/ISPN-2577 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 5.2.0.Beta4, 6.0.0.Final > Reporter: Michal Linhard > Priority: Critical > Fix For: 7.0.0.Final > > > There are lots of SuspectExceptions in resilience test run: > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EDG6/view/EDG-REPOR... > We managed to keep these under cover for 5.1.x branch. > This is of course a cosmetic problem, but it polutes the log with unnecessary ERRORs. > Parsed logs here: > http://www.qa.jboss.com/~mlinhard/test_results/run54-parsed/ -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 4 months

1
0
0 / 0

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

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6802?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-6802: ------------------------------- Status: Open (was: New) > 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.Beta2 > > > * 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 (v7.2.3#72005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7290) Document Data Container Changes

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-7290?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-7290: -------------------------------- Status: Open (was: New) > Document Data Container Changes > ------------------------------- > > Key: ISPN-7290 > URL: https://issues.jboss.org/browse/ISPN-7290 > Project: Infinispan > Issue Type: Task > Components: Documentation-Core > Reporter: William Burns > Assignee: William Burns > > A bunch of changes have been added for the data container including new eviction and off heap. These need to be documented. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7290) Document Data Container Changes

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-7290?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-7290: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/4731 > Document Data Container Changes > ------------------------------- > > Key: ISPN-7290 > URL: https://issues.jboss.org/browse/ISPN-7290 > Project: Infinispan > Issue Type: Task > Components: Documentation-Core > Reporter: William Burns > Assignee: William Burns > > A bunch of changes have been added for the data container including new eviction and off heap. These need to be documented. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7120) Refactor Java Hot Rod Client Test Suite

by Vittorio Rigamonti (JIRA)

[ https://issues.jboss.org/browse/ISPN-7120?page=com.atlassian.jira.plugin.... ] Vittorio Rigamonti commented on ISPN-7120: ------------------------------------------ I've created a spread sheet with the org.infinispan.infinispan-client-hotrod maven tests listed and the current C++ status. Here: https://docs.google.com/spreadsheets/d/1mG7f_AGn6lxmUicFJUY-D5EMLLgzZHt-G... > Refactor Java Hot Rod Client Test Suite > --------------------------------------- > > Key: ISPN-7120 > URL: https://issues.jboss.org/browse/ISPN-7120 > Project: Infinispan > Issue Type: Enhancement > Components: Remote Protocols > Reporter: Martin Gencur > > The goal is to identify tests that will be part of a "TCK" for HotRod clients and create test groups according to client intelligence (L1, L2, L3) and/or respective feature under test. > This task will involve a number of steps: > 1) Identify test classes for the "TCK" first. Have them in a spread sheet with suggested new package and explanation and before proceeding discuss the changes with the team. > 2) Create org.infinispan.client.hotrod.tck package, move the identified classes under a sub-package there. Possibly rename the tests to better reflect their purpose. > 3) Each test should have a predefined *server-side* configuration. In order to make it easier to share the same server-side configuration between Java client test suite, Server integration test suite, and Native clients (NodeJS, C++, C#, ...), convert the respective Java ConfigurationBuilder-style configurations to XML configurations. The mapping between tests and XML server configurations within the TCK should be described in a separate file (possibly generated from annotations??). Where possible share the same configuration file between multiple test classes. > Some suggestions for Java packages within the TCK: intelligence (L1, L2, L2), encryption, authentication, authorazition, xsite, events, near cache > Note: Marshalling is not part of the TCK. The TCK should include things independent of the target language (e.g. C++, C#). It should only include functionality shared by all clients. The java client test suite covers all versions of HotRod protocol and the TCK should include tests for all these versions (not necessarily in separate groups). It should also include things that are not directly related to Hot Rod protocol such as tests related to failover, state transfer. > The next steps after completing the above would be identifying tests in C++,C#,NodeJS client test suite that are missing, according to the new TCK, and adding those tests. This is not part of this JIRA, though. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7316) Minimize thread usage in server related tests

by Gustavo Fernandes (JIRA)

Gustavo Fernandes created ISPN-7316: --------------------------------------- Summary: Minimize thread usage in server related tests Key: ISPN-7316 URL: https://issues.jboss.org/browse/ISPN-7316 Project: Infinispan Issue Type: Enhancement Components: Test Suite - Server Affects Versions: 9.0.0.Beta1 Reporter: Gustavo Fernandes -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4546) Possible stale lock when the primary owner leaves during rebalance

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4546?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4546: ----------------------------------------------- Miroslav Sochurek <msochure(a)redhat.com> changed the Status of [bug 1385162|https://bugzilla.redhat.com/show_bug.cgi?id=1385162] from POST to MODIFIED > Possible stale lock when the primary owner leaves during rebalance > ------------------------------------------------------------------ > > Key: ISPN-4546 > URL: https://issues.jboss.org/browse/ISPN-4546 > Project: Infinispan > Issue Type: Bug > Components: Core, State Transfer > Affects Versions: 7.0.0.Alpha5, 7.1.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Fix For: 7.2.0.Final > > > Topology T: coordinator = A, owners(k) = [C, D], pending_owners(k) = null > B sends prepareCommand(tx1, put(k, v)) to C, D > D adds backup locks and replies > C acquires lock, ready to send reply to B > A starts installing topology T+1: owners(k) = [C, D], pending_owners(k) = [C, E] > A, C and E install topology T+1, B and D do not > E requests and receives tx data from C, including tx1 > C leaves > B sees a SuspectException, sends rollbackCommand(tx1) to C, D > D removes tx1 > C has left, but is ignored > B reports to the user that the tx has been rolled back > B and D install topology T+1 (optional) > A starts installing topology T+2: owners(k) = [D], pending_owners(k) = [E] > A, B, D, E all install topology T+2 > E requests and receives state from D, but it does not remove tx1 > A starts installing topology T+3: owners(k) = [E], pending_owners(k) = null > E now has a stale backup lock on k > It seems very hard to reproduce in production: C would have to leave soon enough so that B and D haven't received the T+1 topology yet, but late enough for it to send its transaction data to E. > A possible solution would be to catch any SuspectException during prepare/commit/rollback (without ignoring leavers), wait for a new topology, and replicate the command again on the new owners. Obviously, this wouldn't work with asynchronous prepare/commit/rollback. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 4 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues December 2016