[JBoss JIRA] (ISPN-9154) Handling X-Site split brains
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-9154?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-9154:
-----------------------------------
Labels: redhat-summit-18 (was: )
> Handling X-Site split brains
> ----------------------------
>
> Key: ISPN-9154
> URL: https://issues.jboss.org/browse/ISPN-9154
> Project: Infinispan
> Issue Type: Feature Request
> Components: Cross-Site Replication
> Reporter: Galder Zamarreño
> Labels: redhat-summit-18
>
> With ASYNC x-site configurations, sites can get out of sync when the replication link is down. We use RELAY2, which basically forwards traffic to other sites but what happen is one of them is flaky?
> The biggest hurdle here is the way state transfer works. Because it's manual, it requires someone (or some script) detecting the split and when it heals pushing the state via JMX op. Automatic rebalancing could take time given the links' extra latency, so it's not clear what the solution should be.
> We do definitely need to implement some soft of conflict resolution and apply the same semantics we use for inner cluster communication regardless.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months
[JBoss JIRA] (ISPN-9154) Handling X-Site split brains
by Galder Zamarreño (JIRA)
Galder Zamarreño created ISPN-9154:
--------------------------------------
Summary: Handling X-Site split brains
Key: ISPN-9154
URL: https://issues.jboss.org/browse/ISPN-9154
Project: Infinispan
Issue Type: Feature Request
Components: Cross-Site Replication
Reporter: Galder Zamarreño
With ASYNC x-site configurations, sites can get out of sync when the replication link is down. We use RELAY2, which basically forwards traffic to other sites but what happen is one of them is flaky?
The biggest hurdle here is the way state transfer works. Because it's manual, it requires someone (or some script) detecting the split and when it heals pushing the state via JMX op. Automatic rebalancing could take time given the links' extra latency, so it's not clear what the solution should be.
We do definitely need to implement some soft of conflict resolution and apply the same semantics we use for inner cluster communication regardless.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months
[JBoss JIRA] (ISPN-9153) Integration with OCP Operator
by Galder Zamarreño (JIRA)
Galder Zamarreño created ISPN-9153:
--------------------------------------
Summary: Integration with OCP Operator
Key: ISPN-9153
URL: https://issues.jboss.org/browse/ISPN-9153
Project: Infinispan
Issue Type: Feature Request
Reporter: Galder Zamarreño
Research integration with OCP Operator Framework (the framework was developed by CoreOS Team for Tectonic and will be merged into OCP soon). The idea is to manage Application Lifecycle and automate all the hard things to do, like upgrades, handling abnormal behavior etc.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months
[JBoss JIRA] (ISPN-9152) Transparent HTTP caching service
by Galder Zamarreño (JIRA)
Galder Zamarreño created ISPN-9152:
--------------------------------------
Summary: Transparent HTTP caching service
Key: ISPN-9152
URL: https://issues.jboss.org/browse/ISPN-9152
Project: Infinispan
Issue Type: Feature Request
Reporter: Galder Zamarreño
Something like Squid that could scale up and down dynamically based on an Autoscaler. If that was a lightweight solution, we could put it in Istio or transparently to Serverless functions.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months
[JBoss JIRA] (ISPN-9151) All client listener parameters passed in programmatically
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-9151?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-9151:
-----------------------------------
Labels: redhat-summit-18 (was: summit18-keynote-demo)
> All client listener parameters passed in programmatically
> ---------------------------------------------------------
>
> Key: ISPN-9151
> URL: https://issues.jboss.org/browse/ISPN-9151
> Project: Infinispan
> Issue Type: Enhancement
> Components: Listeners, Remote Protocols
> Reporter: Galder Zamarreño
> Labels: redhat-summit-18
>
> We're working with the OpenWhisk team to create a generic Feed that allows Infinispan remote events to be exposed in an OpenWhisk way.
> So, you'd pass in Hot Rod endpoint information, name of cache and other details and you'd establish a feed of data from that cache for create/updated/removed data.
> However, making this generic is tricky when you want to pass in filter/converter factory names since these are defined at the annotation level.
> Ideally we should have a way to pass in filter/converter factory names programmatically. To avoid limiting ourselves, you could potentially pass in an instance of the annotation in an overloaded method or as optional parameter [[1|https://stackoverflow.com/questions/16299717/how-to-create-an-instance-of-an-annotation
> ]].
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months
[JBoss JIRA] (ISPN-9151) All client listener parameters passed in programmatically
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-9151?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-9151:
-----------------------------------
Labels: summit18-keynote-demo (was: )
> All client listener parameters passed in programmatically
> ---------------------------------------------------------
>
> Key: ISPN-9151
> URL: https://issues.jboss.org/browse/ISPN-9151
> Project: Infinispan
> Issue Type: Enhancement
> Components: Listeners, Remote Protocols
> Reporter: Galder Zamarreño
> Labels: summit18-keynote-demo
>
> We're working with the OpenWhisk team to create a generic Feed that allows Infinispan remote events to be exposed in an OpenWhisk way.
> So, you'd pass in Hot Rod endpoint information, name of cache and other details and you'd establish a feed of data from that cache for create/updated/removed data.
> However, making this generic is tricky when you want to pass in filter/converter factory names since these are defined at the annotation level.
> Ideally we should have a way to pass in filter/converter factory names programmatically. To avoid limiting ourselves, you could potentially pass in an instance of the annotation in an overloaded method or as optional parameter [[1|https://stackoverflow.com/questions/16299717/how-to-create-an-instance-of-an-annotation
> ]].
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months
[JBoss JIRA] (ISPN-9151) All client listener parameters passed in programmatically
by Galder Zamarreño (JIRA)
Galder Zamarreño created ISPN-9151:
--------------------------------------
Summary: All client listener parameters passed in programmatically
Key: ISPN-9151
URL: https://issues.jboss.org/browse/ISPN-9151
Project: Infinispan
Issue Type: Enhancement
Components: Listeners, Remote Protocols
Reporter: Galder Zamarreño
We're working with the OpenWhisk team to create a generic Feed that allows Infinispan remote events to be exposed in an OpenWhisk way.
So, you'd pass in Hot Rod endpoint information, name of cache and other details and you'd establish a feed of data from that cache for create/updated/removed data.
However, making this generic is tricky when you want to pass in filter/converter factory names since these are defined at the annotation level.
Ideally we should have a way to pass in filter/converter factory names programmatically. To avoid limiting ourselves, you could potentially pass in an instance of the annotation in an overloaded method or as optional parameter [[1|https://stackoverflow.com/questions/16299717/how-to-create-an-instance-of-an-annotation
]].
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months
[JBoss JIRA] (ISPN-9150) Method RemoteCache.entrySet() works incorrectly
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-9150?page=com.atlassian.jira.plugin.... ]
William Burns commented on ISPN-9150:
-------------------------------------
It depends on the network problems :)
But if the data grid cluster is in a split brain and hotrod client talked to the partition that has no data, then it wouldn't return anything.
> Method RemoteCache.entrySet() works incorrectly
> -----------------------------------------------
>
> Key: ISPN-9150
> URL: https://issues.jboss.org/browse/ISPN-9150
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 9.2.1.Final
> Environment: # Cluster contains 2 hosts (each host have one instance of Infinispan)
> # Configuration have cache "Models". The cache have 2 key owners and 2 entities
> Reporter: Sergey Chernolyas
> Assignee: William Burns
>
> Method RemoteCache.entrySet() returns empty stream. Method RemoteCache.retrieveEntries works correctly in same time
> But if I do :
> {code:java}
> System.out.println(modelRemoteCache.entrySet().stream().collect(Collectors.toSet()).size());
> modelRemoteCache.entrySet().forEach(longModelEntry -> {
> System.out.println(":"+longModelEntry.getKey()+":"+longModelEntry.getValue());
> });
> {code}
> First row show size 0. But method "entrySet" will work correctly.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months
[JBoss JIRA] (ISPN-9150) Method RemoteCache.entrySet() works incorrectly
by Sergey Chernolyas (JIRA)
[ https://issues.jboss.org/browse/ISPN-9150?page=com.atlassian.jira.plugin.... ]
Sergey Chernolyas commented on ISPN-9150:
-----------------------------------------
Okey [~william.burns] .
Can the problem occurs if cluster have a network problems ?
> Method RemoteCache.entrySet() works incorrectly
> -----------------------------------------------
>
> Key: ISPN-9150
> URL: https://issues.jboss.org/browse/ISPN-9150
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 9.2.1.Final
> Environment: # Cluster contains 2 hosts (each host have one instance of Infinispan)
> # Configuration have cache "Models". The cache have 2 key owners and 2 entities
> Reporter: Sergey Chernolyas
> Assignee: William Burns
>
> Method RemoteCache.entrySet() returns empty stream. Method RemoteCache.retrieveEntries works correctly in same time
> But if I do :
> {code:java}
> System.out.println(modelRemoteCache.entrySet().stream().collect(Collectors.toSet()).size());
> modelRemoteCache.entrySet().forEach(longModelEntry -> {
> System.out.println(":"+longModelEntry.getKey()+":"+longModelEntry.getValue());
> });
> {code}
> First row show size 0. But method "entrySet" will work correctly.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months