May 2018 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-9161) Description of StateTransferManager.joinComplete does not match the behaviour

by Wolf-Dieter Fink (JIRA)

Wolf-Dieter Fink created ISPN-9161: -------------------------------------- Summary: Description of StateTransferManager.joinComplete does not match the behaviour Key: ISPN-9161 URL: https://issues.jboss.org/browse/ISPN-9161 Project: Infinispan Issue Type: Bug Reporter: Wolf-Dieter Fink Current description is: If true, the node has successfully joined the grid and is considered to hold state. If false, the join process is still in progress.. But the behaviour is: It doesn't wait for the initial state transfer, it just waits for the coordinator to send it a topology before joinComplete is set to TRUE -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9155) Clear should not emit listener notifications

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-9155?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-9155: ------------------------------------ JCache does emit notifications on {{removeAll()}}, maybe we should add something similar if we're going to remove the {{clear()}} notifications. > Clear should not emit listener notifications > -------------------------------------------- > > Key: ISPN-9155 > URL: https://issues.jboss.org/browse/ISPN-9155 > Project: Infinispan > Issue Type: Enhancement > Components: Listeners, Remote Protocols > Reporter: Galder Zamarreño > Labels: redhat-summit-18 > > JCache does not emit notifications on clear(). We shouldn't either. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9160) Concurrent management console access in multiple OpenShift clusters

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-9160: -------------------------------------- Summary: Concurrent management console access in multiple OpenShift clusters Key: ISPN-9160 URL: https://issues.jboss.org/browse/ISPN-9160 Project: Infinispan Issue Type: Enhancement Components: JMX, reporting and management, OpenShift Reporter: Galder Zamarreño Assignee: Vladimir Blagojevic The management console, when used in conjunction with OpenShift, does not handle well opening management console windows to different OpenShift clusters. To workaround it, during the presentation, one site was queried using the console, and the same console was used to update data in that site, but when it came to checking other sites, command line was used. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9160) Concurrent management console access in multiple OpenShift clusters

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-9160?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-9160: ----------------------------------- Labels: redhat-summit-18 (was: ) > Concurrent management console access in multiple OpenShift clusters > ------------------------------------------------------------------- > > Key: ISPN-9160 > URL: https://issues.jboss.org/browse/ISPN-9160 > Project: Infinispan > Issue Type: Enhancement > Components: JMX, reporting and management, OpenShift > Reporter: Galder Zamarreño > Assignee: Vladimir Blagojevic > Labels: redhat-summit-18 > > The management console, when used in conjunction with OpenShift, does not handle well opening management console windows to different OpenShift clusters. To workaround it, during the presentation, one site was queried using the console, and the same console was used to update data in that site, but when it came to checking other sites, command line was used. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9159) Improve visulation of cached data in management console

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-9159: -------------------------------------- Summary: Improve visulation of cached data in management console Key: ISPN-9159 URL: https://issues.jboss.org/browse/ISPN-9159 Project: Infinispan Issue Type: Enhancement Components: JMX, reporting and management Reporter: Galder Zamarreño Assignee: Vladimir Blagojevic A pre-release version of this was used during the presentation to demonstrate that updates in one site would be replicated to other sites. The first thing we noticed is the UI itself, it needs some polishing and adjusting to better represent data. Tristan mentioned having some kind of table and I agree with that, using rows in a table to represent k/v entries would probably be better. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9158) Improve X-Site configuration

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-9158: -------------------------------------- Summary: Improve X-Site configuration Key: ISPN-9158 URL: https://issues.jboss.org/browse/ISPN-9158 Project: Infinispan Issue Type: Enhancement Components: Cross-Site Replication Reporter: Galder Zamarreño Some Dan comments on x-site configuration: bq. I'd rather move the list of backup sites to the global configuration as backup configuration templates, so individual cache configurations could only pick one or more of those global sites (but maybe with a different config). Then the protobuf metadata cache would just back up to all the globally defined backup sites, with the template config. And I think having a single "offline" status for the backup site across all caches would also be an improvement. bq. We also need to allow a site to be offline at startup, currently a site can only be disabled in the configuration, and I’m not sure what’s the relationship between a site’s “enabled” status and it’s “online” status. We may also want to allow a site to become online automatically, without the administrator’s intervention (with or without starting a cross-site state transfer). -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9111) Internal caches should be replicated across sites

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-9111?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-9111: ---------------------------------------- Also, an important factor here is determining which combination of additive options and internal default options are incompatible, and/or which ones can/cannot be overridden. > Internal caches should be replicated across sites > ------------------------------------------------- > > Key: ISPN-9111 > URL: https://issues.jboss.org/browse/ISPN-9111 > Project: Infinispan > Issue Type: Enhancement > Components: Cross-Site Replication, Remote Querying > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Labels: redhat-summit-18 > > Given a cache manager, we should look for all enabled x-site locations and add those sites as SYNC backups for the protobuf metadata cache. Without this data, the user has to implement its own code to make sure the data is added in each site which is troublesome. > Using SYNC/FAIL combo turns out to be very buggy. In the initial test created, only one site was up and the other was not. The put call to replicate the metadata was failing (as a result of ISPN-9113) but this was going under the radar (more tests needed!), and it ended up waiting for the replication timeout to happen. > Even after replication timeout happened, the put call was completing fine. This is because invocation batching was enabled for protobuf metadata cache which means any update failures would not make the cache operations fail. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9111) Internal caches should be replicated across sites

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-9111?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-9111: ---------------------------------------- Actually, not all internal caches might need x-site replicating. As per Dan's comments: bq. The CONFIG cache is also internal, but it shouldn't be replicated across sites, because the backup cache can have a different name and config compared to the original cache. Index manager caches are also internal, and I don't think they should be backed up either. If the backup needs to be indexed, it should compute its own index. > Internal caches should be replicated across sites > ------------------------------------------------- > > Key: ISPN-9111 > URL: https://issues.jboss.org/browse/ISPN-9111 > Project: Infinispan > Issue Type: Enhancement > Components: Cross-Site Replication, Remote Querying > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Labels: redhat-summit-18 > > Given a cache manager, we should look for all enabled x-site locations and add those sites as SYNC backups for the protobuf metadata cache. Without this data, the user has to implement its own code to make sure the data is added in each site which is troublesome. > Using SYNC/FAIL combo turns out to be very buggy. In the initial test created, only one site was up and the other was not. The put call to replicate the metadata was failing (as a result of ISPN-9113) but this was going under the radar (more tests needed!), and it ended up waiting for the replication timeout to happen. > Even after replication timeout happened, the put call was completing fine. This is because invocation batching was enabled for protobuf metadata cache which means any update failures would not make the cache operations fail. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9157) Improve RELAY/RELAY2 JGroups protocol selection

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-9157: -------------------------------------- Summary: Improve RELAY/RELAY2 JGroups protocol selection Key: ISPN-9157 URL: https://issues.jboss.org/browse/ISPN-9157 Project: Infinispan Issue Type: Enhancement Components: Cross-Site Replication Reporter: Galder Zamarreño When using x-site replication, there is the choice of using RELAY or RELAY2 JGroups protocols. The existence of choice is not obvious and not well documented. As an example, if using SYNC x-site replication and RELAY2, it's easy to end up in this situation: if I define site A to have site B as backup, and site B is simply not up yet, why should a put in site A fail? In a normal cluster, if I have node X and node Y is not up yet, a put on node X simply does not fail. To make this work, you need to configure RELAY instead of RELAY2. The RELAY2 doc is very explicit that it doesn't want to expose a virtual view, the sites should be configured statically, and sites that are not up are considered unreachable (https://github.com/belaban/JGroups/blob/master/doc/design/RELAY2.txt) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9156) Protobuf metadata cache should not have invocation batching enabled

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-9156: -------------------------------------- Summary: Protobuf metadata cache should not have invocation batching enabled Key: ISPN-9156 URL: https://issues.jboss.org/browse/ISPN-9156 Project: Infinispan Issue Type: Enhancement Components: Remote Querying Reporter: Galder Zamarreño As a result of having invocation batching enabled, any update failures would not make the cache operations fail. Although surprising, that's an expected behaviour of invocation batching. It should be better documented (see [discussion email|https://markmail.org/message/gbvtv6a3w4gtsvj6]). -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 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 May 2018