[jboss-jira] [JBoss JIRA] (WFCORE-1940) Propagate a persistent domain config revision number and time stamp around the domain

[Brian Stansberry (JIRA)]

    [ https://issues.jboss.org/browse/WFCORE-1940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13317747#comment-13317747 ] 

Brian Stansberry commented on WFCORE-1940:
------------------------------------------

[2:48 PM] Ken Wills: hmm
[2:48 PM] Ken Wills: @BrianStansberry do you think we really should be incremeanting it vs just taking whatever the master says it should be?
[2:48 PM] Ken Wills: that'd make it a bit more complicated i guess
[2:49 PM] Brian Stansberry: I think it will be cleaner to increment
[2:49 PM] Brian Stansberry: we'll see as I do it, but right now i think it's cleaner
[2:49 PM] Brian Stansberry: incrementing will always be done under the exclusive lock
[2:50 PM] Brian Stansberry: so once per op
[2:50 PM] Brian Stansberry: and on a slave any op that would trigger an increment will have the master's current value sent along with it (#4 in the JIRA description)
[2:50 PM] Ken Wills: yah
[2:51 PM] Ken Wills: that seems fine to me then
[2:51 PM] Brian Stansberry: my thinking now is that can kind of separate the "do an increment" bit from the "increment what" bit
[2:52 PM] Brian Stansberry: if that doesn't prove out in practice i'll gladly abandon ship though ;)
[2:53 PM] Brian Stansberry: partly the idea is doing the increment as part of tx commit
[2:53 PM] Brian Stansberry: so it only gets updated when the op succeeds
[2:53 PM] Ken Wills: yeah, that seems like the right approach
[2:54 PM] Brian Stansberry: but the DC sends the last-successful revision, i.e. unincremented
[2:54 PM] Brian Stansberry: so if the slave updates its version to that value, it's always correct, regardless of whether the current op will succeed
[2:55 PM] Ken Wills: wouldn't the slave always already have that value due to join & sync?
[2:55 PM] Brian Stansberry: in theory yes :)
[2:55 PM] Ken Wills: if it was some other value, something bad has happened i think
[2:55 PM] Brian Stansberry: yeah
[2:56 PM] Brian Stansberry: so perhaps it doesn't need to be sent on each op
[2:57 PM] Brian Stansberry: otoh sending it is simple and would be a safeguard in case we forgot something
[2:57 PM] Ken Wills: yah
[2:57 PM] Ken Wills: i was thinking more on the slave side, it could use that to validate its in the expected state or something
[2:57 PM] Brian Stansberry: true, it could

> Propagate a persistent domain config revision number and time stamp around the domain
> -------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1940
>                 URL: https://issues.jboss.org/browse/WFCORE-1940
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>
> This is a subtask of WFCORE-338 and should not be done independent of that overall work.
> The election algorithm we are planning for WFCORE-338 depends on tracking the revision number for changes to the persistent domain-wide model (i.e. what gets written to domain.xml). The revision number will be a simple counter, but we will also track a revision timestamp. The timestamp is solely meant to be an aid to users in understanding when a revision occurred and is not itself relevant to the election algorithm
> Task here is to 
> 1) Read the revision # and timestamp from domain.xml when it is parsed
> 2) Increment it locally on any HC when an operation updates the domain-wide persistent config.
> 3) Persist the local values in domain.xml whenever an operation updates the domain-wide persistent config.
> 4) For the master HC, propagate its current revision # and timestamp along with any multistep write operations pushed to slave HCs.
> 5) For the master HC, propagate its current revision # and timestamp along with the resource model data provided to newly connected HCs.
> 6) For slave HCs, use the revision # and timestamp provided by the master via 4) and 5) as the base value before incrementing in 2).



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)