April 2017 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-7708) Use UnsuccesfulResponse to signalize command failure

by Radim Vansa (JIRA)

Radim Vansa created ISPN-7708: --------------------------------- Summary: Use UnsuccesfulResponse to signalize command failure Key: ISPN-7708 URL: https://issues.jboss.org/browse/ISPN-7708 Project: Infinispan Issue Type: Enhancement Components: Core Affects Versions: 9.0.0.Final Reporter: Radim Vansa Assignee: Radim Vansa Instead of hacky {{WriteCommand#updateStatusFromRemoteResponse}} use UnsuccessfulResponse to signalize that on primary owner the command was not successful. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

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

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-7707: ------------------------------------- Summary: 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, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7706) Supply a default VoidCallback when the SASL mech on the Hot Rod client is EXTERNAL

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-7706: ------------------------------------- Summary: Supply a default VoidCallback when the SASL mech on the Hot Rod client is EXTERNAL Key: ISPN-7706 URL: https://issues.jboss.org/browse/ISPN-7706 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 EXTERNAL SASL mech doesn't need any special callback handlers. We already package a VoidCallbackHandler, so we can implicitly set it when EXTERNAL is configured -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7586) Rolling Upgrade: use of Remote Store in mode read-only causes data inconsistencies

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-7586?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-7586: ------------------------------------ Description: We recommend to do rolling upgrades with the target cluster with a remote-store pointing to the source cluster, in mode ready-only. Clients are switched to point to the target cluster. This cause situations like this in the client: {code:java} client.put("K","value") // will get "value" back client.get("K") // Deletes will not propagate to the source cluster, // the RemoteStore is in 'read-only' mode. client.remove("K") // Returns "V". Although deleted, value will be retrieved // from the remote store cache.get("K") {code} This can break existing applications that expect a consistent access to data during a Rolling Upgrade process. Clearly the remote store should not be in read only mode, but at the same time, as the Rolling Upgrade does a put in the target cache reading data from the source cache, it should not trigger a write back to the source cluster. was: We recommend to do rolling upgrades with the target cluster with a remote-store pointing to the source cluster, in mode ready-only. Clients are switched to point to the target cluster. This cause situations like this in the client: {code:java} client.put("K","value") // will get "V" back client.get("K") // Deletes will not propagate to the source cluster, // the RemoteStore is in 'read-only' mode. client.remove("K") // Returns "V". Although deleted, value will be retrieved // from the remote store cache.get("K") {code} This can break existing applications that expect a consistent access to data during a Rolling Upgrade process. Clearly the remote store should not be in read only mode, but at the same time, as the Rolling Upgrade does a put in the target cache reading data from the source cache, it should not trigger a write back to the source cluster. > Rolling Upgrade: use of Remote Store in mode read-only causes data inconsistencies > ---------------------------------------------------------------------------------- > > Key: ISPN-7586 > URL: https://issues.jboss.org/browse/ISPN-7586 > Project: Infinispan > Issue Type: Bug > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Fix For: 9.0.0.CR4 > > > We recommend to do rolling upgrades with the target cluster with a remote-store pointing to the source cluster, in mode ready-only. Clients are switched to point to the target cluster. > This cause situations like this in the client: > {code:java} > client.put("K","value") > // will get "value" back > client.get("K") > // Deletes will not propagate to the source cluster, > // the RemoteStore is in 'read-only' mode. > client.remove("K") > // Returns "V". Although deleted, value will be retrieved > // from the remote store > cache.get("K") > > {code} > This can break existing applications that expect a consistent access to data during a Rolling Upgrade process. Clearly the remote store should not be in read only mode, but at the same time, as the Rolling Upgrade does a put in the target cache reading data from the source cache, it should not trigger a write back to the source cluster. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7586) Rolling Upgrade: use of Remote Store in mode read-only causes data inconsistencies

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-7586?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-7586: ------------------------------------ Description: We recommend to do rolling upgrades with the target cluster with a remote-store pointing to the source cluster, in mode ready-only. Clients are switched to point to the target cluster. This cause situations like this in the client: {code:java} client.put("K","value") // will get "value" back client.get("K") // Deletes will not propagate to the source cluster, // the RemoteStore is in 'read-only' mode. client.remove("K") // Returns "value". Although deleted, value will be retrieved // from the remote store cache.get("K") {code} This can break existing applications that expect a consistent access to data during a Rolling Upgrade process. Clearly the remote store should not be in read only mode, but at the same time, as the Rolling Upgrade does a put in the target cache reading data from the source cache, it should not trigger a write back to the source cluster. was: We recommend to do rolling upgrades with the target cluster with a remote-store pointing to the source cluster, in mode ready-only. Clients are switched to point to the target cluster. This cause situations like this in the client: {code:java} client.put("K","value") // will get "value" back client.get("K") // Deletes will not propagate to the source cluster, // the RemoteStore is in 'read-only' mode. client.remove("K") // Returns "V". Although deleted, value will be retrieved // from the remote store cache.get("K") {code} This can break existing applications that expect a consistent access to data during a Rolling Upgrade process. Clearly the remote store should not be in read only mode, but at the same time, as the Rolling Upgrade does a put in the target cache reading data from the source cache, it should not trigger a write back to the source cluster. > Rolling Upgrade: use of Remote Store in mode read-only causes data inconsistencies > ---------------------------------------------------------------------------------- > > Key: ISPN-7586 > URL: https://issues.jboss.org/browse/ISPN-7586 > Project: Infinispan > Issue Type: Bug > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Fix For: 9.0.0.CR4 > > > We recommend to do rolling upgrades with the target cluster with a remote-store pointing to the source cluster, in mode ready-only. Clients are switched to point to the target cluster. > This cause situations like this in the client: > {code:java} > client.put("K","value") > // will get "value" back > client.get("K") > // Deletes will not propagate to the source cluster, > // the RemoteStore is in 'read-only' mode. > client.remove("K") > // Returns "value". Although deleted, value will be retrieved > // from the remote store > cache.get("K") > > {code} > This can break existing applications that expect a consistent access to data during a Rolling Upgrade process. Clearly the remote store should not be in read only mode, but at the same time, as the Rolling Upgrade does a put in the target cache reading data from the source cache, it should not trigger a write back to the source cluster. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7705) Administration console - greyed out cluster action can still be selected

by Roman Macor (JIRA)

Roman Macor created ISPN-7705: --------------------------------- Summary: Administration console - greyed out cluster action can still be selected Key: ISPN-7705 URL: https://issues.jboss.org/browse/ISPN-7705 Project: Infinispan Issue Type: Bug Components: JMX, reporting and management Affects Versions: 9.0.0.Final Reporter: Roman Macor Priority: Minor When the cluster is in the running state, start, reload and restart actions are greyed out, but they can still be clicked and the selected action is performed. This is not the case for the node operations. Also, shouldn't restart action be available when server/node are in running state? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7704) AbstractFileLookup#lookupFileStrict should also support absolute paths

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-7704?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec updated ISPN-7704: -------------------------------------- Status: Open (was: New) > AbstractFileLookup#lookupFileStrict should also support absolute paths > ---------------------------------------------------------------------- > > Key: ISPN-7704 > URL: https://issues.jboss.org/browse/ISPN-7704 > Project: Infinispan > Issue Type: Bug > Components: JCache, Spring Integration > Affects Versions: 9.0.0.Final > Reporter: Sebastian Łaskawiec > Assignee: Sebastian Łaskawiec > Priority: Critical > > When specifying {{spring.cache.jcache.config}} value in Spring's application.properties, Spring passes us a scheme with absolute path (e.g. {{file:/home/slaskawi/work/infinispan/CacheTest/target/classes/infinispan.xml}}). This causes problems with {{AbstractFileLookup#lookupFileStrict(java.net.URI, java.lang.ClassLoader)}} since it should construct a new {{File}} rather than load this resource from the classloader. > Related Pull Request: https://github.com/infinispan/infinispan/pull/4474 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7704) AbstractFileLookup#lookupFileStrict should also support absolute paths

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-7704?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec updated ISPN-7704: -------------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/5060 > AbstractFileLookup#lookupFileStrict should also support absolute paths > ---------------------------------------------------------------------- > > Key: ISPN-7704 > URL: https://issues.jboss.org/browse/ISPN-7704 > Project: Infinispan > Issue Type: Bug > Components: JCache, Spring Integration > Affects Versions: 9.0.0.Final > Reporter: Sebastian Łaskawiec > Assignee: Sebastian Łaskawiec > Priority: Critical > > When specifying {{spring.cache.jcache.config}} value in Spring's application.properties, Spring passes us a scheme with absolute path (e.g. {{file:/home/slaskawi/work/infinispan/CacheTest/target/classes/infinispan.xml}}). This causes problems with {{AbstractFileLookup#lookupFileStrict(java.net.URI, java.lang.ClassLoader)}} since it should construct a new {{File}} rather than load this resource from the classloader. > Related Pull Request: https://github.com/infinispan/infinispan/pull/4474 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7704) AbstractFileLookup#lookupFileStrict should also support absolute paths

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-7704?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec updated ISPN-7704: -------------------------------------- Workaround Description: The only way is to create {{javax.cache.CacheManager}} Bean in Spring manually and specify. It is highly advised to use {{org.infinispan.jcache.embedded.JCacheManager#JCacheManager(java.net.URI, java.lang.ClassLoader, javax.cache.spi.CachingProvider, java.util.Properties)}} constructor for this. > AbstractFileLookup#lookupFileStrict should also support absolute paths > ---------------------------------------------------------------------- > > Key: ISPN-7704 > URL: https://issues.jboss.org/browse/ISPN-7704 > Project: Infinispan > Issue Type: Bug > Components: JCache, Spring Integration > Affects Versions: 9.0.0.Final > Reporter: Sebastian Łaskawiec > Assignee: Sebastian Łaskawiec > Priority: Critical > > When specifying {{spring.cache.jcache.config}} value in Spring's application.properties, Spring passes us a scheme with absolute path (e.g. {{file:/home/slaskawi/work/infinispan/CacheTest/target/classes/infinispan.xml}}). This causes problems with {{AbstractFileLookup#lookupFileStrict(java.net.URI, java.lang.ClassLoader)}} since it should construct a new {{File}} rather than load this resource from the classloader. > Related Pull Request: https://github.com/infinispan/infinispan/pull/4474 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7704) AbstractFileLookup#lookupFileStrict should also support absolute paths

by Sebastian Łaskawiec (JIRA)

Sebastian Łaskawiec created ISPN-7704: ----------------------------------------- Summary: AbstractFileLookup#lookupFileStrict should also support absolute paths Key: ISPN-7704 URL: https://issues.jboss.org/browse/ISPN-7704 Project: Infinispan Issue Type: Bug Components: JCache, Spring Integration Affects Versions: 9.0.0.Final Reporter: Sebastian Łaskawiec Assignee: Sebastian Łaskawiec Priority: Critical When specifying {{spring.cache.jcache.config}} value in Spring's application.properties, Spring passes us a scheme with absolute path (e.g. {{file:/home/slaskawi/work/infinispan/CacheTest/target/classes/infinispan.xml}}). This causes problems with {{AbstractFileLookup#lookupFileStrict(java.net.URI, java.lang.ClassLoader)}} since it should construct a new {{File}} rather than load this resource from the classloader. Related Pull Request: https://github.com/infinispan/infinispan/pull/4474 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues April 2017