[JBoss JIRA] (ISPN-11412) Documentation for the console
by Donald Naro (Jira)
[ https://issues.redhat.com/browse/ISPN-11412?page=com.atlassian.jira.plugi... ]
Donald Naro updated ISPN-11412:
-------------------------------
Comment: was deleted
(was: [~karesti] what if we embed documentation in the console itself? any help text/doc should be available where the user expects it. right now if I open the console I can see some "?" icons that don't open help pages or provide hover text.
!screenshot-1.png|thumbnail!
I think we should add some text there and provide inline help rather than a standalone doc. is that possible?)
> Documentation for the console
> -----------------------------
>
> Key: ISPN-11412
> URL: https://issues.redhat.com/browse/ISPN-11412
> Project: Infinispan
> Issue Type: Feature Request
> Components: Documentation
> Affects Versions: 10.1.3.Final
> Reporter: Katia Aresti
> Assignee: Donald Naro
> Priority: Major
> Labels: console-ng
> Attachments: screenshot-1.png
>
>
> Currently the documentation of the web console does not exist.
> The current console is very simple but it should be listed in
> https://infinispan.org/docs/stable/index.html
> at this point.
> Some screenshots and a couple of features could be nice to be explained.
> Not much needed at this point
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 6 months
[JBoss JIRA] (ISPN-12350) Persistent UUIDs are only used for initial consistent hash
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/ISPN-12350?page=com.atlassian.jira.plugi... ]
Dan Berindei updated ISPN-12350:
--------------------------------
Status: Open (was: New)
> Persistent UUIDs are only used for initial consistent hash
> ----------------------------------------------------------
>
> Key: ISPN-12350
> URL: https://issues.redhat.com/browse/ISPN-12350
> Project: Infinispan
> Issue Type: Bug
> Components: Core, State Transfer
> Affects Versions: 12.0.0.Dev03, 11.0.3.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 12.0.0.Final
>
>
> After a graceful restart, the persisted UUIDs are used to re-create the consistent hash of the cache before shutdown. This initial CH will not be rebalanced, so there is no state transfer immediately after cluster restart.
> However, if something then triggers a rebalance (e.g. a node join/leave), the persistent UUIDs are ignored, and {{SyncConsistentHashFactory}} allocates segments based on the new JGroups addresses instead of the persistent UUIDs.
> I modified {{ThreeNodeDistGlobalStateRestartTest}} to force a rebalance after restart, and I got
> {noformat}
> 11:24:07,424 TRACE (jgroups-7,Test-NodeD:[]) [ClusterCacheStatus] Cache testCache topology updated: CacheTopology{id=1, phase=NO_REBALANCE, rebalanceId=1, currentCH=DefaultConsistentHash{ns=256, owners = (3)[Test-NodeD: 83+0, Test-NodeE: 87+0, Test-NodeF: 86+0]}, pendingCH=null, unionCH=null, actualMembers=[Test-NodeD, Test-NodeE, Test-NodeF], persistentUUIDs=[1ba71c04-a6b9-4a5c-9f51-e5e358081dc6, 6d3ff549-aafa-4d8a-8617-84ac6f119549, f37f6a8c-32a4-4dda-b1b0-876c24f42c6a]}, members = [Test-NodeD, Test-NodeE, Test-NodeF], joiners = []
> 11:24:07,889 TRACE (testng-Test:[]) [ClusterCacheStatus] Rebalancing consistent hash for cache testCache, members are [Test-NodeD, Test-NodeE, Test-NodeF]
> 11:24:07,909 TRACE (testng-Test:[]) [ClusterCacheStatus] Updating cache testCache topology for rebalance: CacheTopology{id=2, phase=READ_OLD_WRITE_ALL, rebalanceId=2, currentCH=DefaultConsistentHash{ns=256, owners = (3)[Test-NodeD: 83+0, Test-NodeE: 87+0, Test-NodeF: 86+0]}, pendingCH=DefaultConsistentHash{ns=256, owners = (3)[Test-NodeD: 87+0, Test-NodeE: 83+0, Test-NodeF: 86+0]}, unionCH=null, actualMembers=[Test-NodeD, Test-NodeE, Test-NodeF], persistentUUIDs=[1ba71c04-a6b9-4a5c-9f51-e5e358081dc6, 6d3ff549-aafa-4d8a-8617-84ac6f119549, f37f6a8c-32a4-4dda-b1b0-876c24f42c6a]}
> 11:24:07,910 TRACE (testng-Test:[]) [ClusterCacheStatus] Moved segments: [Test-NodeD added 72 removed 68, Test-NodeE added 49 removed 53, Test-NodeF added 59 removed 59]
> {noformat}
> This issue does not affect caches using {{DefaultConsistentHashFactory}}, because it doesn't care about member UUIDs. Since there is no {{SyncScatteredConsistentHashFactory}}, scattered cache are not affected at all. Replicated caches with the default {{SyncReplicateedConsistentHashFactory}} will change primary owners, but they won't need any state transfer.
> {{TestingUtil.waitForNoRebalance()}} works around the issue by not checking whether the initial consistent hash (with topologyId==1) is balanced.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 6 months
[JBoss JIRA] (ISPN-12221) Add zero-capacity-node support for Replicated caches
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/ISPN-12221?page=com.atlassian.jira.plugi... ]
Dan Berindei updated ISPN-12221:
--------------------------------
Status: Open (was: New)
> Add zero-capacity-node support for Replicated caches
> ----------------------------------------------------
>
> Key: ISPN-12221
> URL: https://issues.redhat.com/browse/ISPN-12221
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Affects Versions: 12.0.0.Dev01
> Reporter: Ryan Emerson
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 12.0.0.Dev04
>
>
> Currently if a container is configured to have {{zero-capacity-node=true}} this only applies to distributed caches. To prevent state-transfer for replicated caches, we should modify {{ReplicatedConsistentHashFactory}} and {{ReplicatedConsistentHash}} to allow a node to be a member without also being an owner.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 6 months