May 2018 - infinispan-issues - Jboss List Archives

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

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-9155: -------------------------------------- Summary: 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 JCache does not emit notifications on clear(). We shouldn't either. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9153) Integration with OCP Operator

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-9153?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-9153: ----------------------------------- Component/s: OpenShift > Integration with OCP Operator > ----------------------------- > > Key: ISPN-9153 > URL: https://issues.jboss.org/browse/ISPN-9153 > Project: Infinispan > Issue Type: Feature Request > Components: OpenShift > Reporter: Galder Zamarreño > Labels: redhat-summit-18 > > 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)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9152) Transparent HTTP caching service

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-9152?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-9152: ----------------------------------- Component/s: OpenShift > Transparent HTTP caching service > -------------------------------- > > Key: ISPN-9152 > URL: https://issues.jboss.org/browse/ISPN-9152 > Project: Infinispan > Issue Type: Feature Request > Components: OpenShift > Reporter: Galder Zamarreño > Labels: redhat-summit-18 > > 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)

7 years, 10 months

1
0
0 / 0

[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)

7 years, 10 months

1
0
0 / 0

[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)

7 years, 10 months

1
0
0 / 0

[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)

7 years, 10 months

1
0
0 / 0

[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)

7 years, 10 months

1
0
0 / 0

[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)

7 years, 10 months

1
0
0 / 0

[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)

7 years, 10 months

1
0
0 / 0

[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)

7 years, 10 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 May 2018