July 2017 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-8010) Data Management Operations through Console

by Pedro Zapata (JIRA)

[ https://issues.jboss.org/browse/ISPN-8010?page=com.atlassian.jira.plugin.... ] Pedro Zapata reassigned ISPN-8010: ---------------------------------- Assignee: Vladimir Blagojevic > Data Management Operations through Console > ------------------------------------------ > > Key: ISPN-8010 > URL: https://issues.jboss.org/browse/ISPN-8010 > Project: Infinispan > Issue Type: Feature Request > Components: Console > Reporter: Pedro Zapata > Assignee: Vladimir Blagojevic > > Users should be allowed to perform basic data operations over the grid, such as: > * Browsing the content of a cache, with pagination and result count > * Sending a Ickle query, and walk through the results - validate syntax > * Sending a GET and retrieving value > * Sending a PUT > * Download results of a query > The basic format for object representation will be JSON. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8010) Data Management Operations through Console

by Pedro Zapata (JIRA)

[ https://issues.jboss.org/browse/ISPN-8010?page=com.atlassian.jira.plugin.... ] Pedro Zapata updated ISPN-8010: ------------------------------- Description: Users should be allowed to perform basic data operations over the grid, such as: * Browsing the content of a cache, with pagination and result count * Sending a Ickle query, and walk through the results - validate syntax * Sending a GET and retrieving value * Sending a PUT * Download results of a query The basic format for object representation will be JSON. was: Users should be allowed to perform basic data operations over the grid, such as: * Browsing the content of a cache, with pagination * Sending a Ickle query, and walk through the results - validate syntax * Sending a GET and retrieving value * Sending a PUT * Download results of a query The basic format for object representation will be JSON. > Data Management Operations through Console > ------------------------------------------ > > Key: ISPN-8010 > URL: https://issues.jboss.org/browse/ISPN-8010 > Project: Infinispan > Issue Type: Feature Request > Components: Console > Reporter: Pedro Zapata > > Users should be allowed to perform basic data operations over the grid, such as: > * Browsing the content of a cache, with pagination and result count > * Sending a Ickle query, and walk through the results - validate syntax > * Sending a GET and retrieving value > * Sending a PUT > * Download results of a query > The basic format for object representation will be JSON. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8010) Data Management Operations through Console

by Pedro Zapata (JIRA)

Pedro Zapata created ISPN-8010: ---------------------------------- Summary: Data Management Operations through Console Key: ISPN-8010 URL: https://issues.jboss.org/browse/ISPN-8010 Project: Infinispan Issue Type: Feature Request Components: Console Reporter: Pedro Zapata Users should be allowed to perform basic data operations over the grid, such as: * Browsing the content of a cache, with pagination * Sending a Ickle query, and walk through the results - validate syntax * Sending a GET and retrieving value * Sending a PUT * Download results of a query The basic format for object representation will be JSON. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8008) Add Fault-tolerance to write-behind stores

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-8008?page=com.atlassian.jira.plugin.... ] Ryan Emerson commented on ISPN-8008: ------------------------------------ How we approach 2 depends on what failure conditions we tolerate for the store. If we only tolerate connection issues/write failures, then it should only be necessary to keep track of the keys modified during the outage and then flush the latest version of said keys on reconnect. However, if we assume that a store's content can be lost during the outage, then we will have to flush the entire cache. > Add Fault-tolerance to write-behind stores > ------------------------------------------ > > Key: ISPN-8008 > URL: https://issues.jboss.org/browse/ISPN-8008 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Reporter: Ryan Emerson > Assignee: Ryan Emerson > > Currently when a store is configured to be write-behind, three attempts are made to write the queued modifications to the store. If all three attempts fail, then this error is simply logged and the modifications are never written to the store. > We should allow users to configure a write-behind store so that: In the event that a write-behind fails, further operations on the cache are not allowed and the modifications which failed to write to the store are queued indefinitely. Once the underlying store becomes available, the queued modifications should be written and then the cache should become available. > To determine whether a store has become available again, the AsyncCacheWriter will have to poll the store's availability. Currently the CacheWriter interface does not allow such behaviour, therefore there are two options: > * Attempt a write and catch an exception if the store is not currently available > * Add a method to return the current status of a store to the CacheWriter interface -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8009) Add Fault-tolerance to write-behind stores

by Ryan Emerson (JIRA)

Ryan Emerson created ISPN-8009: ---------------------------------- Summary: Add Fault-tolerance to write-behind stores Key: ISPN-8009 URL: https://issues.jboss.org/browse/ISPN-8009 Project: Infinispan Issue Type: Enhancement Components: Loaders and Stores Reporter: Ryan Emerson Assignee: Ryan Emerson Currently when a store is configured to be write-behind, three attempts are made to write the queued modifications to the store. If all three attempts fail, then this error is simply logged and the modifications are never written to the store. We should allow users to configure a write-behind store so that: In the event that a write-behind fails, further operations on the cache are not allowed and the modifications which failed to write to the store are queued indefinitely. Once the underlying store becomes available, the queued modifications should be written and then the cache should become available. To determine whether a store has become available again, the AsyncCacheWriter will have to poll the store's availability. Currently the CacheWriter interface does not allow such behaviour, therefore there are two options: * Attempt a write and catch an exception if the store is not currently available * Add a method to return the current status of a store to the CacheWriter interface -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8008) Add Fault-tolerance to write-behind stores

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-8008?page=com.atlassian.jira.plugin.... ] Tristan Tarrant commented on ISPN-8008: --------------------------------------- I think we might want write-behind to have three behaviours: 1. block on error when queue is full 2. ignore errors, flush entire cache to the store on reconnect (could be tricky to implement) 3. ignore errors (the current behaviour) > Add Fault-tolerance to write-behind stores > ------------------------------------------ > > Key: ISPN-8008 > URL: https://issues.jboss.org/browse/ISPN-8008 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Reporter: Ryan Emerson > Assignee: Ryan Emerson > > Currently when a store is configured to be write-behind, three attempts are made to write the queued modifications to the store. If all three attempts fail, then this error is simply logged and the modifications are never written to the store. > We should allow users to configure a write-behind store so that: In the event that a write-behind fails, further operations on the cache are not allowed and the modifications which failed to write to the store are queued indefinitely. Once the underlying store becomes available, the queued modifications should be written and then the cache should become available. > To determine whether a store has become available again, the AsyncCacheWriter will have to poll the store's availability. Currently the CacheWriter interface does not allow such behaviour, therefore there are two options: > * Attempt a write and catch an exception if the store is not currently available > * Add a method to return the current status of a store to the CacheWriter interface -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7291) It should be possible to delete cache from Administration console

by Pedro Zapata (JIRA)

[ https://issues.jboss.org/browse/ISPN-7291?page=com.atlassian.jira.plugin.... ] Pedro Zapata updated ISPN-7291: ------------------------------- Component/s: Console (was: JMX, reporting and management) > It should be possible to delete cache from Administration console > ----------------------------------------------------------------- > > Key: ISPN-7291 > URL: https://issues.jboss.org/browse/ISPN-7291 > Project: Infinispan > Issue Type: Feature Request > Components: Console > Affects Versions: 9.0.0.Beta1 > Reporter: Roman Macor > Assignee: Vladimir Blagojevic > Priority: Minor > > Since we can create cache from administration console we should also be able to delete it. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7555) Originator node in launch new task dialog is not displayed correctly in standalone mode

by Pedro Zapata (JIRA)

[ https://issues.jboss.org/browse/ISPN-7555?page=com.atlassian.jira.plugin.... ] Pedro Zapata updated ISPN-7555: ------------------------------- Component/s: Console (was: JMX, reporting and management) > Originator node in launch new task dialog is not displayed correctly in standalone mode > --------------------------------------------------------------------------------------- > > Key: ISPN-7555 > URL: https://issues.jboss.org/browse/ISPN-7555 > Project: Infinispan > Issue Type: Bug > Components: Console > Affects Versions: 9.0.0.CR2 > Reporter: Roman Macor > Assignee: Vladimir Blagojevic > Priority: Minor > > - start server in standalone clustered mode - bin/standalone.sh -c clustered.xml > - click on cache container - Tasks execution tab -> Launch new task -> click on Originator node > result: the node is displayed like this: terminator:terminator, if we set the server name, e.g. server-one, it's displayed like this: server-one:server-one ("terminator" is hostname from /etc/hostname) > expected result: host-name:server-name (same as in domain mode) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7642) Administration console - remote sites are not displayed correctly on cache container page

by Pedro Zapata (JIRA)

[ https://issues.jboss.org/browse/ISPN-7642?page=com.atlassian.jira.plugin.... ] Pedro Zapata updated ISPN-7642: ------------------------------- Component/s: Console (was: JMX, reporting and management) > Administration console - remote sites are not displayed correctly on cache container page > ----------------------------------------------------------------------------------------- > > Key: ISPN-7642 > URL: https://issues.jboss.org/browse/ISPN-7642 > Project: Infinispan > Issue Type: Bug > Components: Console > Affects Versions: 9.0.0.CR2 > Reporter: Roman Macor > Assignee: Vladimir Blagojevic > Attachments: Screenshot-cacheContainer.png, Screenshot-detail-cache.png, clustered.xml > > > Have 2 caches each configured with a different remote site. > When you click on cache container, both remote sites are displayed on both cache cards. Clicking on a cache to see cache detail page shows correct remote site. Please see the attached screenshots. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5256) Deploy Ispn Management Console on OpenShift

by Pedro Zapata (JIRA)

[ https://issues.jboss.org/browse/ISPN-5256?page=com.atlassian.jira.plugin.... ] Pedro Zapata updated ISPN-5256: ------------------------------- Component/s: Cloud Integrations Console (was: JMX, reporting and management) > Deploy Ispn Management Console on OpenShift > ------------------------------------------- > > Key: ISPN-5256 > URL: https://issues.jboss.org/browse/ISPN-5256 > Project: Infinispan > Issue Type: Task > Components: Cloud Integrations, Console > Reporter: Tomas Sykora > Assignee: Tomas Sykora > Labels: console, jmx, management, openshift > > Deploy Infinispan Management Console on Red Hat OpenShift. > Benefits: Anyone on the internet will be able to see our web console in action without any need of local installation. > Infinispan server will be running behind in domain mode. > The idea is that we will re-deploy once we have another version (even minor) ready. The process: Checkout from upstream/master, commit, git push to OpenShift-based repo -- redeploy happens automatically. > Any ideas, concerns, workflow and progress will be discussed in this JIRA comments. > I've met some difficulties with Bower installation. Paths need to be slightly adjusted -- this is the first problem I need to solve to be able to proceed further. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues July 2017