February 2015 - infinispan-issues

[JBoss JIRA] (ISPN-5234) Implement single cluster view page (P1)

by Vladimir Blagojevic (JIRA)

Vladimir Blagojevic created ISPN-5234: ----------------------------------------- Summary: Implement single cluster view page (P1) Key: ISPN-5234 URL: https://issues.jboss.org/browse/ISPN-5234 Project: Infinispan Issue Type: Task Reporter: Vladimir Blagojevic In our admin console current single cluster view page does not contain the following functionality that should be implemented: * -Zoom in/out- * Node availability/detail * Filter by metrics (node view) * Filter by metrics (cache view) * Search node (search as you type) * Search cache (search as you type) * -Cluster switcher- * Cluster status view -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5234) Implement single cluster view page (P1)

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-5234?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic reassigned ISPN-5234: ----------------------------------------- Assignee: Vladimir Blagojevic > Implement single cluster view page (P1) > --------------------------------------- > > Key: ISPN-5234 > URL: https://issues.jboss.org/browse/ISPN-5234 > Project: Infinispan > Issue Type: Task > Reporter: Vladimir Blagojevic > Assignee: Vladimir Blagojevic > > In our admin console current single cluster view page does not contain the following functionality that should be implemented: > * -Zoom in/out- > * Node availability/detail > * Filter by metrics (node view) > * Filter by metrics (cache view) > * Search node (search as you type) > * Search cache (search as you type) > * -Cluster switcher- > * Cluster status view -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5233) Implement clusters view page (P1)

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-5233?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic updated ISPN-5233: -------------------------------------- Description: In our admin console the current clusters view page contains a list of available clusters. However, we are missing the number of nodes and caches per cluster. We also automatically append state "Available" while in fact we should check for clusters availability and set it accordingly. (was: Our current clusters view page contains a list of available clusters. However, we are missing the number of nodes and caches per cluster. We also automatically append state "Available" while in fact we should check for clusters availability and set it accordingly. ) > Implement clusters view page (P1) > --------------------------------- > > Key: ISPN-5233 > URL: https://issues.jboss.org/browse/ISPN-5233 > Project: Infinispan > Issue Type: Task > Components: JMX, reporting and management > Reporter: Vladimir Blagojevic > Assignee: Vladimir Blagojevic > Fix For: 8.0.0.Final > > > In our admin console the current clusters view page contains a list of available clusters. However, we are missing the number of nodes and caches per cluster. We also automatically append state "Available" while in fact we should check for clusters availability and set it accordingly. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5233) Implement clusters view page (P1)

by Vladimir Blagojevic (JIRA)

Vladimir Blagojevic created ISPN-5233: ----------------------------------------- Summary: Implement clusters view page (P1) Key: ISPN-5233 URL: https://issues.jboss.org/browse/ISPN-5233 Project: Infinispan Issue Type: Task Components: JMX, reporting and management Reporter: Vladimir Blagojevic Assignee: Vladimir Blagojevic Fix For: 8.0.0.Final Our current clusters view page contains a list of available clusters. However, we are missing the number of nodes and caches per cluster. We also automatically append state "Available" while in fact we should check for clusters availability and set it accordingly. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5232) Entry iterator returns entries created in current TX but does not apply the filter/converter

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-5232?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-5232: -------------------------------- Status: Open (was: New) > Entry iterator returns entries created in current TX but does not apply the filter/converter > -------------------------------------------------------------------------------------------- > > Key: ISPN-5232 > URL: https://issues.jboss.org/browse/ISPN-5232 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.0.0.Final > Reporter: Adrian Nistor > Assignee: William Burns > Fix For: 7.2.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5232) Entry iterator returns entries created in current TX but does not apply the filter/converter

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-5232?page=com.atlassian.jira.plugin.... ] Adrian Nistor commented on ISPN-5232: ------------------------------------- Some code to reproduce this here: https://github.com/anistor/infinispan/commit/32f3070b5080507c4e0991c11675... > Entry iterator returns entries created in current TX but does not apply the filter/converter > -------------------------------------------------------------------------------------------- > > Key: ISPN-5232 > URL: https://issues.jboss.org/browse/ISPN-5232 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.0.0.Final > Reporter: Adrian Nistor > Assignee: William Burns > Fix For: 7.2.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5232) Entry iterator returns entries created in current TX but does not apply the filter/converter

by Adrian Nistor (JIRA)

Adrian Nistor created ISPN-5232: ----------------------------------- Summary: Entry iterator returns entries created in current TX but does not apply the filter/converter Key: ISPN-5232 URL: https://issues.jboss.org/browse/ISPN-5232 Project: Infinispan Issue Type: Bug Components: Core Affects Versions: 7.0.0.Final Reporter: Adrian Nistor Assignee: William Burns Fix For: 7.2.0.Final -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5192) infinispan-remote uber jar contains 2x versions of shaded javassist packages

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-5192?page=com.atlassian.jira.plugin.... ] Work on ISPN-5192 started by Adrian Nistor. ------------------------------------------- > infinispan-remote uber jar contains 2x versions of shaded javassist packages > ----------------------------------------------------------------------------- > > Key: ISPN-5192 > URL: https://issues.jboss.org/browse/ISPN-5192 > Project: Infinispan > Issue Type: Bug > Components: Build process, Remote Protocols > Affects Versions: 7.1.0.CR2 > Reporter: Tristan Tarrant > Assignee: Adrian Nistor > Fix For: 7.2.0.Alpha1 > > > Both the shaded protostream library and the infinispan-remote uberjar package javassist. The latter should be removed. The package should be relocated to avoid conflict with containers which expose the library (i.e. weblogic) -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5222) Perform Remote Filtering/Conversion in a single step

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5222?page=com.atlassian.jira.plugin.... ] Galder Zamarreño reassigned ISPN-5222: -------------------------------------- Assignee: Galder Zamarreño > Perform Remote Filtering/Conversion in a single step > ---------------------------------------------------- > > Key: ISPN-5222 > URL: https://issues.jboss.org/browse/ISPN-5222 > Project: Infinispan > Issue Type: Feature Request > Components: Listeners > Affects Versions: 7.1.0.Final > Reporter: Stylianos Koussouris > Assignee: Galder Zamarreño > Fix For: 7.2.0.Final > > > I want to have filter and convert take place in one step ie. do filtering and conversion applied to REMOTE LISTENERS in one step > a) I define CacheEventConverterFactory which implements CacheEventConverterFactory, Serializable > b) I register on the server org.infinispan.notifications.cachelistener.filter.CacheEventConverterFactory the cache event converter > which returns (CacheEventConverter<K, V, C>) new SharesDynamicFilterConverter(params); > c) I then define CacheEventFilterFactory which implements CacheEventFilterFactory, Serializable { > and returns(CacheEventFilter<K, V>) new SharesDynamicFilterConverter(params); > d) The CustomeDynamicFilterConverter extends AbstractCacheEventFilterConverter<String, Share, ShareProgress> implements Serializable { > and has the implementation of > public Share filterAndConvert(String key, Share oldValue, Metadata oldMetadata, Share newValue, Metadata newMetadata, EventType eventType) { > e) finally I define a listener binding it to the filter and converter > @ClientListener(filterFactoryName = "custom-dynamic-filter", > converterFactoryName = "custom-dynamic-converter", > includeCurrentState = true) > and register it along with params for the filter on the client side > cache.addClientListener(listener, new Object[]{"NYX", 50f}, null); > The result of this is that certainly both accept and convert methods are run and both call the same filterAndConvert method on SharesDynamicFilterConverter > However, this is not desirable as I don't want 2 steps which will effectively do the same thing but a single step. TBH I am not happy with the solution but what I did (in absence of better understanding of how to combine the steps -NOTE there is no single Factory for both Converter and Filter and even if it did we would probably have to implement accept & convert inside so the end result would have been the same) > So what I did was to change the last step > ie. > e) finally I define a listener binding ONLY the converter > @ClientListener(converterFactoryName = "murex-dynamic-converter", includeCurrentState = true) > and register it along with params ONLY for the converter on the client side > cache.addClientListener(listener, null, new Object[]{"NYX", 50f}); > This works as it actually does the filter during the convert step BUT is there another way and am I missing something? If not this would be a feature request -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5222) Perform Remote Filtering/Conversion in a single step

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5222?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-5222: ----------------------------------- Fix Version/s: 7.2.0.Final > Perform Remote Filtering/Conversion in a single step > ---------------------------------------------------- > > Key: ISPN-5222 > URL: https://issues.jboss.org/browse/ISPN-5222 > Project: Infinispan > Issue Type: Feature Request > Components: Listeners > Affects Versions: 7.1.0.Final > Reporter: Stylianos Koussouris > Assignee: Galder Zamarreño > Fix For: 7.2.0.Final > > > I want to have filter and convert take place in one step ie. do filtering and conversion applied to REMOTE LISTENERS in one step > a) I define CacheEventConverterFactory which implements CacheEventConverterFactory, Serializable > b) I register on the server org.infinispan.notifications.cachelistener.filter.CacheEventConverterFactory the cache event converter > which returns (CacheEventConverter<K, V, C>) new SharesDynamicFilterConverter(params); > c) I then define CacheEventFilterFactory which implements CacheEventFilterFactory, Serializable { > and returns(CacheEventFilter<K, V>) new SharesDynamicFilterConverter(params); > d) The CustomeDynamicFilterConverter extends AbstractCacheEventFilterConverter<String, Share, ShareProgress> implements Serializable { > and has the implementation of > public Share filterAndConvert(String key, Share oldValue, Metadata oldMetadata, Share newValue, Metadata newMetadata, EventType eventType) { > e) finally I define a listener binding it to the filter and converter > @ClientListener(filterFactoryName = "custom-dynamic-filter", > converterFactoryName = "custom-dynamic-converter", > includeCurrentState = true) > and register it along with params for the filter on the client side > cache.addClientListener(listener, new Object[]{"NYX", 50f}, null); > The result of this is that certainly both accept and convert methods are run and both call the same filterAndConvert method on SharesDynamicFilterConverter > However, this is not desirable as I don't want 2 steps which will effectively do the same thing but a single step. TBH I am not happy with the solution but what I did (in absence of better understanding of how to combine the steps -NOTE there is no single Factory for both Converter and Filter and even if it did we would probably have to implement accept & convert inside so the end result would have been the same) > So what I did was to change the last step > ie. > e) finally I define a listener binding ONLY the converter > @ClientListener(converterFactoryName = "murex-dynamic-converter", includeCurrentState = true) > and register it along with params ONLY for the converter on the client side > cache.addClientListener(listener, null, new Object[]{"NYX", 50f}); > This works as it actually does the filter during the convert step BUT is there another way and am I missing something? If not this would be a feature request -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 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 February 2015