April 2017 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-7707) Add more configuration options for the keystores in Hot Rod clients and servers

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-7707?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7707: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/5074 > Add more configuration options for the keystores in Hot Rod clients and servers > ------------------------------------------------------------------------------- > > Key: ISPN-7707 > URL: https://issues.jboss.org/browse/ISPN-7707 > Project: Infinispan > Issue Type: Enhancement > Components: Remote Protocols > Affects Versions: 9.0.0.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 9.1.0.Final > > > The user should be able to specify the following additional configuration options when setting up a keystore/truststore for Hot Rod: > - the key alias to selet the desired identity to present to the peer > - the store type (JKS, JCEKS, ...) > - the protocol type (TLSv1.1, TLSv1.2, etc) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7509) TotalOrderStateTransferInterceptor doesn't handle OutdatedTopologyException for read commands

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-7509?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-7509: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/5073 > TotalOrderStateTransferInterceptor doesn't handle OutdatedTopologyException for read commands > --------------------------------------------------------------------------------------------- > > Key: ISPN-7509 > URL: https://issues.jboss.org/browse/ISPN-7509 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.0.0.CR1 > Reporter: Dan Berindei > Assignee: Pedro Ruivo > Priority: Critical > Labels: testsuite_stability > Fix For: 9.0.1.Final > > > Since ISPN-6859, read commands can also trigger {{OutdatedTopologyException}}, but these are only handled in the non-TO {{StateTransferInterceptor}}. When a read should be retried because of a topology change in a TO cache, the {{OutdatedTopologyException}} is instead thrown to the user: > {noformat} > 16:50:40,595 DEBUG (jgroups-9,Test-NodeA-483:[]) [InvocationContextInterceptor] ISPN000311: Received a command from an outdated topology, returning the exception to caller > org.infinispan.statetransfer.OutdatedTopologyException: Did not get any successful response, got {Test-NodeC-46564=UnsuccessfulResponse} > 16:50:40,595 ERROR (testng-Test:[]) [TestSuiteProgress] Test failed: org.infinispan.tx.totalorder.statetransfer.DistTotalOrderVersionedStateTransferTest.testStateTransfer > org.infinispan.statetransfer.OutdatedTopologyException: Did not get any successful response, got {Test-NodeC-46564=UnsuccessfulResponse} > {noformat} > This causes random failures in {{DistTotalOrderVersionedStateTransferTest}}. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7509) TotalOrderStateTransferInterceptor doesn't handle OutdatedTopologyException for read commands

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-7509?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-7509: ------------------------------ Fix Version/s: 9.0.1.Final (was: 9.1.0.Final) > TotalOrderStateTransferInterceptor doesn't handle OutdatedTopologyException for read commands > --------------------------------------------------------------------------------------------- > > Key: ISPN-7509 > URL: https://issues.jboss.org/browse/ISPN-7509 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.0.0.CR1 > Reporter: Dan Berindei > Assignee: Pedro Ruivo > Priority: Critical > Labels: testsuite_stability > Fix For: 9.0.1.Final > > > Since ISPN-6859, read commands can also trigger {{OutdatedTopologyException}}, but these are only handled in the non-TO {{StateTransferInterceptor}}. When a read should be retried because of a topology change in a TO cache, the {{OutdatedTopologyException}} is instead thrown to the user: > {noformat} > 16:50:40,595 DEBUG (jgroups-9,Test-NodeA-483:[]) [InvocationContextInterceptor] ISPN000311: Received a command from an outdated topology, returning the exception to caller > org.infinispan.statetransfer.OutdatedTopologyException: Did not get any successful response, got {Test-NodeC-46564=UnsuccessfulResponse} > 16:50:40,595 ERROR (testng-Test:[]) [TestSuiteProgress] Test failed: org.infinispan.tx.totalorder.statetransfer.DistTotalOrderVersionedStateTransferTest.testStateTransfer > org.infinispan.statetransfer.OutdatedTopologyException: Did not get any successful response, got {Test-NodeC-46564=UnsuccessfulResponse} > {noformat} > This causes random failures in {{DistTotalOrderVersionedStateTransferTest}}. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7717) ClusteredGetAllCommand should be invoked with SYNCHRONOUS_IGNORE_LEAVERS

by Radim Vansa (JIRA)

Radim Vansa created ISPN-7717: --------------------------------- Summary: ClusteredGetAllCommand should be invoked with SYNCHRONOUS_IGNORE_LEAVERS Key: ISPN-7717 URL: https://issues.jboss.org/browse/ISPN-7717 Project: Infinispan Issue Type: Bug Components: Core Affects Versions: 9.0.0.Final Reporter: Radim Vansa Assignee: Radim Vansa This is the intended mode for all read commands; otherwise it can trigger IllegalStateException in StateTransferInterceptor. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7715) Command can reply when the cache has been shut down

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-7715?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-7715: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/5072 > Command can reply when the cache has been shut down > --------------------------------------------------- > > Key: ISPN-7715 > URL: https://issues.jboss.org/browse/ISPN-7715 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.0.0.Final > Reporter: Radim Vansa > Assignee: Radim Vansa > > When a cache has been shut down, therefore wiping out the data container, there can be still ongoing commands that will reply to the RPC sender. The result can be invalid at that moment, though. > This causes issues in GetAllCommandStressTest. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7715) Command can reply when the cache has been shut down

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-7715?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-7715: ------------------------------ Status: Open (was: New) > Command can reply when the cache has been shut down > --------------------------------------------------- > > Key: ISPN-7715 > URL: https://issues.jboss.org/browse/ISPN-7715 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.0.0.Final > Reporter: Radim Vansa > Assignee: Radim Vansa > > When a cache has been shut down, therefore wiping out the data container, there can be still ongoing commands that will reply to the RPC sender. The result can be invalid at that moment, though. > This causes issues in GetAllCommandStressTest. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7144) Cross-Site Replication: inconsistent data with multiple site masters

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-7144?page=com.atlassian.jira.plugin.... ] Pedro Ruivo commented on ISPN-7144: ----------------------------------- [~zeguan], the fix would be setting {{RELAY2.max_site_master=1}} (that is the default value anyway) in JGroups configuration. > Cross-Site Replication: inconsistent data with multiple site masters > -------------------------------------------------------------------- > > Key: ISPN-7144 > URL: https://issues.jboss.org/browse/ISPN-7144 > Project: Infinispan > Issue Type: Bug > Components: Cross-Site Replication > Affects Versions: 9.0.0.Alpha4 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > > Cross-Site replication with multiple site masters may not work properly when configured asynchronously. > It relies on the deliver order of the updates to the remote site but, with multiple site masters, it is possible an update to go through one of the possible routes. Having commands going through different routes violates the FIFO order needed leading to inconsistent data between sites. > Note: it doesn't happen in synchronous mode. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7631) Cache.entrySet() entries don't implement Map.Entry.equals() correctly

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-7631?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-7631: ------------------------------ Fix Version/s: 9.0.1.Final > Cache.entrySet() entries don't implement Map.Entry.equals() correctly > --------------------------------------------------------------------- > > Key: ISPN-7631 > URL: https://issues.jboss.org/browse/ISPN-7631 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.0.0.CR2 > Reporter: Dan Berindei > Assignee: Pedro Ruivo > Fix For: 9.0.1.Final > > > The {{Map.Entry.equals()}} javadoc says "Returns true if the given object is also a map entry and the two entries represent the same mapping.", meaning any other metadata stored in cache entries (e.g. lifespan) must be ignored for the purpose of checking equality. In other words, this code should work regardless of what entries are stored in the cache or in the invocation context: > {code:java} > cache.entrySet().contains(new AbstractMap.SimpleEntry("k", "v")) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7631) Cache.entrySet() entries don't implement Map.Entry.equals() correctly

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-7631?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-7631: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/5071 > Cache.entrySet() entries don't implement Map.Entry.equals() correctly > --------------------------------------------------------------------- > > Key: ISPN-7631 > URL: https://issues.jboss.org/browse/ISPN-7631 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.0.0.CR2 > Reporter: Dan Berindei > Assignee: Pedro Ruivo > Fix For: 9.0.1.Final > > > The {{Map.Entry.equals()}} javadoc says "Returns true if the given object is also a map entry and the two entries represent the same mapping.", meaning any other metadata stored in cache entries (e.g. lifespan) must be ignored for the purpose of checking equality. In other words, this code should work regardless of what entries are stored in the cache or in the invocation context: > {code:java} > cache.entrySet().contains(new AbstractMap.SimpleEntry("k", "v")) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7144) Cross-Site Replication: inconsistent data with multiple site masters

by Zefa Guan (JIRA)

[ https://issues.jboss.org/browse/ISPN-7144?page=com.atlassian.jira.plugin.... ] Zefa Guan commented on ISPN-7144: --------------------------------- Hi Pedro, do we have the target time to fix it? > Cross-Site Replication: inconsistent data with multiple site masters > -------------------------------------------------------------------- > > Key: ISPN-7144 > URL: https://issues.jboss.org/browse/ISPN-7144 > Project: Infinispan > Issue Type: Bug > Components: Cross-Site Replication > Affects Versions: 9.0.0.Alpha4 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > > Cross-Site replication with multiple site masters may not work properly when configured asynchronously. > It relies on the deliver order of the updates to the remote site but, with multiple site masters, it is possible an update to go through one of the possible routes. Having commands going through different routes violates the FIFO order needed leading to inconsistent data between sites. > Note: it doesn't happen in synchronous mode. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues April 2017