[
https://issues.jboss.org/browse/WFCORE-1940?page=com.atlassian.jira.plugi...
]
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)