[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)
9 years
[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)
9 years
[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)
9 years
[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)
9 years