[
https://issues.apache.org/jira/browse/ARTEMIS-2716?focusedWorklogId=607186&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-607186
]
ASF GitHub Bot logged work on ARTEMIS-2716:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 04/Jun/21 16:33
Start Date: 04/Jun/21 16:33
Worklog Time Spent: 10m
Work Description: franz1981 edited a comment on pull request #3555:
URL: https://github.com/apache/activemq-artemis/pull/3555#issuecomment-854860785
@gtully @michaelpearce-gain @clebertsuconic @jbertram @mattrpav
**The proposal for the community call is for next Wed (09) on 15 UK time:
will write here or on slack a link for the call.**
Some of the subjects of the call are about:
- key differences from "classic" replication process
- improvements to handle on this PR or delay as separate enhancements
eg Ideas about journal epoch/versioning: worth doing it now or later?
Discuss about issue and solutions
- some key decision/discussions on existing behaviours
The last one is very important to move on with this PR, and the behaviour I
was thinking are:
1. classic replication: single pair with pinger vs multiple pairs using
quorum -> former deactivate/activate master based on network availability,
latter just stop master on cluster connection drop (see
https://github.com/apache/activemq-artemis/blob/0b95cb7754e1ae732f1ae9a3ddef657ea13ac90d/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/SharedNothingLiveActivation.java#L263)
-> which behaviour to apply on the pluggable quorum vote? impl both and make
it configurable?
2. classic replication: failure during backup failover (including inability
to become live due to network split/majority agreement) cause it to restart as
a pure backup (it includes the failback case) -> what's I've impl now and what
should be better to do instead?
**If new things will popup on my head I'm going to drop them here, but first
replies if the time/day of the call is fine ;)**
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
-------------------
Worklog Id: (was: 607186)
Time Spent: 14.5h (was: 14h 20m)
> Implements pluggable Quorum Vote
> --------------------------------
>
> Key: ARTEMIS-2716
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2716
> Project: ActiveMQ Artemis
> Issue Type: New Feature
> Reporter: Francesco Nigro
> Assignee: Francesco Nigro
> Priority: Major
> Attachments: backup.png, primary.png
>
> Time Spent: 14.5h
> Remaining Estimate: 0h
>
> This task aim to ideliver a new Quorum Vote mechanism for artemis with the
> objectives:
> # to make it pluggable
> # to cleanly separate the election phase and the cluster member states
> # to simplify most common setups in both amount of configuration and
> requirements (eg "witness" nodes could be implemented to support single
> master-slave pairs)
> Post-actions to help people adopt it, but need to be thought upfront:
> # a clean upgrade path for current HA replication users
> # deprecate or integrate the current HA replication into the new version
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
