November 2016 - infinispan-issues

[JBoss JIRA] (ISPN-7190) Administration console - when adding new cache, base configuration shouldn't show existing caches

by Roman Macor (JIRA)

[ https://issues.jboss.org/browse/ISPN-7190?page=com.atlassian.jira.plugin.... ] Roman Macor closed ISPN-7190. ----------------------------- Resolution: Done [~vblagojevic] I was testing it with latest snapshot of Infinispan which is using 9.0.0.Alpha4 version of management console, (I'm always clearing cache before management console tests). I will be using 9.0.0 of management console from now on, which is the current latest version in https://github.com/infinispan/infinispan-management-console. It is indeed resolved there, so I'm closing this issue. > Administration console - when adding new cache, base configuration shouldn't show existing caches > ------------------------------------------------------------------------------------------------- > > Key: ISPN-7190 > URL: https://issues.jboss.org/browse/ISPN-7190 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management > Affects Versions: 9.0.0.Alpha4 > Reporter: Roman Macor > Assignee: Vladimir Blagojevic > Attachments: Screen Shot 2016-11-13 at 8.05.40 AM.png, Screenshot from 2016-11-11.png > > > Click on cache container -> Add cache -> expand "base configuration" drop down > Result: The drop down offers cache configurations and existing caches > Expected result: The drop down should only offer cache configurations. ("default" and "memcachedCache" shouldn't be there ) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5021) Nodes that finish the rebalance later can see outdated values

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-5021?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-5021: ------------------------------ Labels: consistency testsuite_stability (was: testsuite_stability) > Nodes that finish the rebalance later can see outdated values > ------------------------------------------------------------- > > Key: ISPN-5021 > URL: https://issues.jboss.org/browse/ISPN-5021 > Project: Infinispan > Issue Type: Bug > Components: Core, State Transfer > Affects Versions: 7.0.2.Final > Reporter: Dan Berindei > Assignee: Pedro Ruivo > Priority: Critical > Labels: consistency, testsuite_stability > > Copied from [ISPN-4444|https://issues.jboss.org/browse/ISPN-4444?focusedCommentId=1302...] > If the CH_UPDATE command is delayed on the old owner, the new owners might update the key without the old owner knowing, and a locality check on the old owner won't help. > I remember one thing that struck me when reading the Raft algorithm was that they install configuration changes symmetrically, in 3 phases. We might need to do the same for our rebalance: > 1. T0: read_ch=old, write_ch=old > 2. start a rebalance > 3. T1: read_ch=old, write_ch=old+new > 4. new owners have all the data > 5. T2: read_ch=new, write_ch=old+new > 6. remove old cache entries and ignore further writes > 7. T3: read_ch=new, write_ch=new -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3918) Inconsistent view of the cache with putIfAbsent in a non-tx cache during state transfer

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-3918?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-3918: ------------------------------ Labels: consistency (was: ) > Inconsistent view of the cache with putIfAbsent in a non-tx cache during state transfer > --------------------------------------------------------------------------------------- > > Key: ISPN-3918 > URL: https://issues.jboss.org/browse/ISPN-3918 > Project: Infinispan > Issue Type: Bug > Components: Core, State Transfer > Affects Versions: 6.0.0.Final > Reporter: Dan Berindei > Labels: consistency > Fix For: 9.0.0.Beta1 > > Attachments: ntpiadjst.log.gz > > > In a non-tx cache, sometimes it's possible for a {{get(k)}} to return {{null}} even though a previous {{putIfAbsent(k, v)}} returned a non-null value and the only concurrent operations on the cache are concurrent putIfAbsent calls. > Say \[B, A, C] are the owners of k (C just joined) > 1. A starts a {{putIfAbsent(k, v1)}} command, sends it to B > 2. B forwards the command to A and C > 3. C writes {{k=v1}} > 4. C becomes the primary owner of k (owners are now \[C, A]) > 5. A/B see the new topology before committing and throw an outdatedTopologyException > 6. A retries the command, sends it to C > 7. C forwards the command to A, which writes {{k=v1}} > 8. C doesn't have to update the entry, returns null > If, between steps 3 and 7, another thread on A starts a {{putIfAbsent(k, v2)}} command, the command will fail and return {{v1}} (because the primary owner already has a value). However, a subsequent {{get(k)}} command will return {{null}}, because A is an owner and doesn't have the value. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4286) Two concurrent putIfAbsent operations can both return null during rebalance

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-4286?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-4286: ------------------------------ Labels: consistency (was: consistence) > Two concurrent putIfAbsent operations can both return null during rebalance > --------------------------------------------------------------------------- > > Key: ISPN-4286 > URL: https://issues.jboss.org/browse/ISPN-4286 > Project: Infinispan > Issue Type: Bug > Components: Core, State Transfer > Affects Versions: 6.0.2.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Labels: consistency > Fix For: 9.0.0.Beta1 > > > If the cache topology changes while executing a putIfAbsent operation, the old primary owner will throw an OutdatedTopologyException, and the originator will retry on the new owner. > When retrying the PutKeyValueCommand on the new primary owner, we compare the current value with the command's new value. If they are equal, we assume that the initial command wrote the old value, and we return {{null}}. > However, the value might have been written by another putIfAbsent operation. So we could have two {{putIfAbsent(k, v)}} operations, both returning {{null}}. > {code} > A is the originator, B is the primary owner, k = null > A -> B: putIfAbsent(k, v1) > B dies before writing v, C is now primary owner > D -> C: putIfAbsent(k, v1) // another put operation from D, with the same value > C -> D: null // correct > A -> C: retry_putIfAbsent(k, v1) > C -> A: null // C assumes A is overwriting its own value, so it's also returning null > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4286) Two concurrent putIfAbsent operations can both return null during rebalance

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-4286?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-4286: ------------------------------ Labels: consistence (was: ) > Two concurrent putIfAbsent operations can both return null during rebalance > --------------------------------------------------------------------------- > > Key: ISPN-4286 > URL: https://issues.jboss.org/browse/ISPN-4286 > Project: Infinispan > Issue Type: Bug > Components: Core, State Transfer > Affects Versions: 6.0.2.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Labels: consistence > Fix For: 9.0.0.Beta1 > > > If the cache topology changes while executing a putIfAbsent operation, the old primary owner will throw an OutdatedTopologyException, and the originator will retry on the new owner. > When retrying the PutKeyValueCommand on the new primary owner, we compare the current value with the command's new value. If they are equal, we assume that the initial command wrote the old value, and we return {{null}}. > However, the value might have been written by another putIfAbsent operation. So we could have two {{putIfAbsent(k, v)}} operations, both returning {{null}}. > {code} > A is the originator, B is the primary owner, k = null > A -> B: putIfAbsent(k, v1) > B dies before writing v, C is now primary owner > D -> C: putIfAbsent(k, v1) // another put operation from D, with the same value > C -> D: null // correct > A -> C: retry_putIfAbsent(k, v1) > C -> A: null // C assumes A is overwriting its own value, so it's also returning null > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3309) EntryWrappingInterceptor should not wrap entries on the originator in non-tx mode

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-3309?page=com.atlassian.jira.plugin.... ] Radim Vansa commented on ISPN-3309: ----------------------------------- ISPN-7029 should make this JIRA outdated. > EntryWrappingInterceptor should not wrap entries on the originator in non-tx mode > --------------------------------------------------------------------------------- > > Key: ISPN-3309 > URL: https://issues.jboss.org/browse/ISPN-3309 > Project: Infinispan > Issue Type: Task > Components: Transactions > Affects Versions: 5.3.0.Final > Reporter: Dan Berindei > > EntryWrappingInterceptor assumes that lock delegation is only enabled in dist caches, so in a repl cache it will wrap the entry twice. This may mean that the entry is also written to the data container twice. > I have tried changing this assumption in the context of ISPN-3289, but it caused some failures in ClusteredCacheWithRamDirIndexManagerTest and ClusteredCacheWithInfinispanDirectoryTest. The query interceptor may be assuming that the entries are committed to the data container when {{ctx.isOriginLocal() == true}}, so it warrants a more thorough investigation. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7185) Confirmation dialog is not displayed when changing configuration

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-7185?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic updated ISPN-7185: -------------------------------------- Priority: Minor (was: Major) > Confirmation dialog is not displayed when changing configuration > ---------------------------------------------------------------- > > Key: ISPN-7185 > URL: https://issues.jboss.org/browse/ISPN-7185 > Project: Infinispan > Issue Type: Bug > Components: Console > Affects Versions: 9.0.0.Alpha4 > Reporter: Vladimir Blagojevic > Assignee: Vladimir Blagojevic > Priority: Minor > Attachments: Screen Shot 2016-11-10 at 7.41.57 AM.png > > > When changing configuration there should be confirmation pop-up dialog. > (Confirmation: Update configuration template distributedCache? "Cancel" "Confirm") > Steps to reproduce: > click on cache container -> Configuration -> Transport -> change lock timeout -> click save -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6784) Facilitate access to task deployment

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-6784?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic updated ISPN-6784: -------------------------------------- Priority: Minor (was: Major) > Facilitate access to task deployment > ------------------------------------ > > Key: ISPN-6784 > URL: https://issues.jboss.org/browse/ISPN-6784 > Project: Infinispan > Issue Type: Enhancement > Components: Console > Reporter: Pedro Zapata > Assignee: Vladimir Blagojevic > Priority: Minor > > Admins would be able to add new task definitions, add new deployments, cache templates and so on. Currently that's ‘buried’ in the cache configuration page and users are unable to find the pages and add new tasks, deployments, and cache configurations templates. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6891) Create a generic Properties Table Directive

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-6891?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic updated ISPN-6891: -------------------------------------- Priority: Minor (was: Major) > Create a generic Properties Table Directive > ------------------------------------------- > > Key: ISPN-6891 > URL: https://issues.jboss.org/browse/ISPN-6891 > Project: Infinispan > Issue Type: Enhancement > Components: Console > Affects Versions: 9.0.0.Alpha3 > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Minor > > Currently we only have a basic implementation of a properties table for indexing, however properties will definitely be required elsewhere eventually. > It makes sense to create a generic directive that handles the input of properties. The key requirements being that it allows properties to be added/removed as well as allowing for default properties to be available to the user (dropdown etc). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7112) Allow Filtering of Containers by Profile

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-7112?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic updated ISPN-7112: -------------------------------------- Priority: Minor (was: Major) > Allow Filtering of Containers by Profile > ---------------------------------------- > > Key: ISPN-7112 > URL: https://issues.jboss.org/browse/ISPN-7112 > Project: Infinispan > Issue Type: Enhancement > Components: Console > Affects Versions: 9.0.0.Alpha4 > Reporter: Ryan Emerson > Priority: Minor > > Currently the Cache Container screen will display all containers from all profiles, it would be nice if each containers profile was explicitly stated[1] and if the list of available containers could be filtered by their associated profile. > [1] We could do this by simply dividing the container list into foldable sections based upon their profile e.g: > profile 1 > -> Container 1 > -> Container 2 > profile 2 > -> Container ... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 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 November 2016