[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, …
[View More]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)
[View Less]
6 years, 10 months
[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 …
[View More]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)
[View Less]
6 years, 10 months
[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 …
[View More]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)
[View Less]
6 years, 10 months
[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
> …
[View More] 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)
[View Less]
6 years, 10 months
[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 …
[View More]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)
[View Less]
6 years, 10 months
[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 …
[View More]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)
[View Less]
6 years, 10 months