[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)
8 years, 1 month
[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)
8 years, 1 month
[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)
8 years, 1 month
[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)
8 years, 1 month
[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)
8 years, 1 month
[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)
8 years, 1 month
[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)
8 years, 1 month
[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)
8 years, 1 month
[JBoss JIRA] (ISPN-6397) Expose DMR operation that returns caches using a certain template
by Vladimir Blagojevic (JIRA)
[ https://issues.jboss.org/browse/ISPN-6397?page=com.atlassian.jira.plugin.... ]
Vladimir Blagojevic updated ISPN-6397:
--------------------------------------
Priority: Minor (was: Major)
> Expose DMR operation that returns caches using a certain template
> -----------------------------------------------------------------
>
> Key: ISPN-6397
> URL: https://issues.jboss.org/browse/ISPN-6397
> Project: Infinispan
> Issue Type: Feature Request
> Components: Console
> Affects Versions: 8.2.0.Final
> Reporter: Vladimir Blagojevic
> Assignee: Tristan Tarrant
> Priority: Minor
>
> In order to trigger server restart we need to know not only if a certain template field requires a restart or not (in conf metadata) but we also need to know if a certain template is being used to configure caches or not. We could do this with a series of DMR calls from Admin console but it would be simpler to add DMR op that given a template returns caches it configures. In the case when the list of caches is empty we can safely conclude that changing the template does not require server restart even if some fields requiring restart are changed.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 1 month