info used for something upon restart that is necessary
for correctness? Is it mainly important for telemetry? If it is not needed
for correctness could skipping this snapshotting step during leader
election be made a configurable option?
As per my knowledge, If session info is not persisted, sessions wil
Ivo Vrdoljak created ZOOKEEPER-4771:
---
Summary: Fast leader election taking too long
Key: ZOOKEEPER-4771
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4771
Project: ZooKeeper
Issue
Rishabh Rai created ZOOKEEPER-4766:
--
Summary: Ensure leader election time does not unnecessarily scale
with tree size due to snapshotting
Key: ZOOKEEPER-4766
URL: https://issues.apache.org/jira/browse/ZOOKEEPER
Benton Liang created ZOOKEEPER-4620:
---
Summary: zookeeper leader election time metric not reported
correctly
Key: ZOOKEEPER-4620
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4620
Project
xiongjianbo created ZOOKEEPER-4502:
--
Summary: SyncRequestProcessor leak when leader election occurred
Key: ZOOKEEPER-4502
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4502
Project: ZooKeeper
Arun Subramanian R created ZOOKEEPER-4316:
-
Summary: Leader election fails due to SocketTimeoutException in
QuorumCnxManager
Key: ZOOKEEPER-4316
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4316
Alex Mirgorodskiy created ZOOKEEPER-4220:
Summary: Redundant connection attempts during leader election
Key: ZOOKEEPER-4220
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4220
Project
Julian Chow created ZOOKEEPER-4185:
--
Summary: Addition of new ZooTrace Mask LEADER_ELECTION_MASK and
related log lines for better leader election telemetry
Key: ZOOKEEPER-4185
URL: https://issues.apache.org/jira
Harald Musum created ZOOKEEPER-4183:
---
Summary: Leader election not working when using hostname in server
config and hostname resolves to an internal IP addresses
Key: ZOOKEEPER-4183
URL: https
Matteo Merli created ZOOKEEPER-3923:
---
Summary: Leader election issues with Istio
Key: ZOOKEEPER-3923
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3923
Project: ZooKeeper
Issue Type
Lasaro Camargos created ZOOKEEPER-3769:
--
Summary: fast leader election does not end if leader is taken down
Key: ZOOKEEPER-3769
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3769
Project
Alex Kaiser created ZOOKEEPER-3757:
--
Summary: Transaction log sync can take 20+ seconds after leader
election when there is a large snapCount
Key: ZOOKEEPER-3757
URL: https://issues.apache.org/jira/browse
Karolos Antoniadis created ZOOKEEPER-3537:
-
Summary: Leader election - Use of out of election messages
Key: ZOOKEEPER-3537
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3537
Project
Karolos Antoniadis created ZOOKEEPER-3479:
-
Summary: Logging false leader election times
Key: ZOOKEEPER-3479
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3479
Project: ZooKeeper
w long the conventional FLE actually took.
On Mon, Jul 29, 2019 at 7:13 PM Alexander Shraer wrote:
> Please see comments inline.
>
> Thanks,
> Alex
>
> On Mon, Jul 29, 2019 at 5:29 PM Karolos Antoniadis
> wrote:
>
> > Hi ZooKeeper developers,
> >
> > ZooKee
Please see comments inline.
Thanks,
Alex
On Mon, Jul 29, 2019 at 5:29 PM Karolos Antoniadis
wrote:
> Hi ZooKeeper developers,
>
> ZooKeeper seems to be logging a "*LEADER ELECTION TOOK*" message even
> though no leader election takes place during a reconfiguration.
>
Hi ZooKeeper developers,
ZooKeeper seems to be logging a "*LEADER ELECTION TOOK*" message even
though no leader election takes place during a reconfiguration.
This can be reproduced by following these steps:
1) start a ZooKeeper cluster (e.g., 3 participants)
2) start a client tha
Marzieh created ZOOKEEPER-3456:
--
Summary: Service temporarily unavailable due to an ongoing leader
election. Please refresh
Key: ZOOKEEPER-3456
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3456
election from the beginning.
I mean it is not an infinite sequence of message passing and I just provide 3
slices of this infinite sequence.
Therefore each case is just one leader election protocol which starts with 3
nodes and finishes when there was no enabled message. Therefore in case 2
changed it's state to
following, it received vote from 4, and changed mind to vote for 4, so 3 and 4
will keep voting 4 and in LOOKING state.
> Leader election terminated, two leaders or not following leader or not having
>
Lagrang edited a comment on issue #863: ZOOKEEPER-3320: Leader election port
stop listen when hostname unresolvable for some time
URL: https://github.com/apache/zookeeper/pull/863#issuecomment-477946006
Zookeeper binds to LE port on start, if you can't bind to it, I think
fail-fast
Lagrang commented on issue #863: ZOOKEEPER-3320: Leader election port stop
listen when hostname unresolvable for some time
URL: https://github.com/apache/zookeeper/pull/863#issuecomment-477946006
Zookeeper binds to LE port on start, if you can't bind to it, I think
fail-fast is more
and I appreciate your time.
Then what about the other two conditions I mentioned?
2) There are some nodes that follow nodes other than the leaders.
3) There are some nodes that neither following nor leading
> Leader election terminated, two leaders or not following leader or not having
>
maoling commented on issue #863: ZOOKEEPER-3320: Leader election port stop
listen when hostname unresolvable for some time
URL: https://github.com/apache/zookeeper/pull/863#issuecomment-477893575
After extending the `ZooKeeperCriticalThread`, When
`QuorumCnxManager.Listener `had failed
Lagrang commented on issue #863: ZOOKEEPER-3320: Leader election port stop
listen when hostname unresolvable for some time
URL: https://github.com/apache/zookeeper/pull/863#issuecomment-477882906
@maoling Can you please describe your concerns
maoling commented on issue #863: ZOOKEEPER-3320: Leader election port stop
listen when hostname unresolvable for some time
URL: https://github.com/apache/zookeeper/pull/863#issuecomment-477839636
I have reservations about extending `QuorumCnxManager.Listener
enixon commented on issue #863: ZOOKEEPER-3320: Leader election port stop
listen when hostname unresolvable for some time
URL: https://github.com/apache/zookeeper/pull/863#issuecomment-477804567
Good find @maoling ! I don't see any discussion in ZOOKEEPER-602 about
criteria for what
of leader election
# node 4 and 5 mentioned 5 is leader, but 1, 2, 3 only following 5 when there
is another majority confirmed it, which is not
# node 1, 2, 3 voted for 3, 3 gets majority so it's start leading, meanwhile 5
is still waiting for another peer to join before it's timed out
> Lea
maoling commented on issue #863: ZOOKEEPER-3320: Leader election port stop
listen when hostname unresolvable for some time
URL: https://github.com/apache/zookeeper/pull/863#issuecomment-477471802
- There was a
[sum-up](https://issues.apache.org/jira/browse/ZOOKEEPER-602?focusedCommentId
enixon commented on issue #863: ZOOKEEPER-3320: Leader election port stop
listen when hostname unresolvable for some time
URL: https://github.com/apache/zookeeper/pull/863#issuecomment-477303890
Thanks for the new test
Lagrang edited a comment on issue #863: ZOOKEEPER-3320: Leader election port
stop listen when hostname unresolvable for some time
URL: https://github.com/apache/zookeeper/pull/863#issuecomment-477172489
Push changes which extend `QuorumCnxManager.Listener` from
`ZookeeperCriticalThread
Lagrang commented on issue #863: ZOOKEEPER-3320: Leader election port stop
listen when hostname unresolvable for some time
URL: https://github.com/apache/zookeeper/pull/863#issuecomment-477172489
Push changes to extends QuorumCnxManager.Listener from
ZookeeperCriticalThread. Plus test
enixon commented on issue #863: ZOOKEEPER-3320: Leader election port stop
listen when hostname unresolvable for some time
URL: https://github.com/apache/zookeeper/pull/863#issuecomment-476324387
Thanks for adding docs!
I'm wary of adding an infinite loop for the same reasons
Lagrang commented on issue #863: ZOOKEEPER-3320: Leader election port stop
listen when hostname unresolvable for some time
URL: https://github.com/apache/zookeeper/pull/863#issuecomment-476284089
Add doc for introduced property to `zookeeperAdmin.md` file, `Cluster
Options` section
Lagrang commented on issue #863: ZOOKEEPER-3320: Leader election port stop
listen when hostname unresolvable for some time
URL: https://github.com/apache/zookeeper/pull/863#issuecomment-475969622
> An infinite loop is a better option, especially for the availability?
because the contai
maoling commented on issue #863: ZOOKEEPER-3320: Leader election port stop
listen when hostname unresolvable for some time
URL: https://github.com/apache/zookeeper/pull/863#issuecomment-475965281
@Lagrang
- you also need to doc this property in the `zookeeperAdmin.md`
- Look back
Lagrang commented on issue #863: ZOOKEEPER-3320: Leader election port stop
listen when hostname unresolvable for some time
URL: https://github.com/apache/zookeeper/pull/863#issuecomment-475885134
retest maven build
eolivelli commented on issue #863: ZOOKEEPER-3320: Leader election port stop
listen when hostname unresolvable for some time
URL: https://github.com/apache/zookeeper/pull/863#issuecomment-475788393
retest maven build
eolivelli commented on issue #863: ZOOKEEPER-3320: Leader election port stop
listen when hostname unresolvable for some time
URL: https://github.com/apache/zookeeper/pull/863#issuecomment-475767323
Even Travis
enixon commented on issue #863: ZOOKEEPER-3320: Leader election port stop
listen when hostname unresolvable for some time
URL: https://github.com/apache/zookeeper/pull/863#issuecomment-475741434
Some thing is wrong with JenkinsMaven here
Lagrang opened a new pull request #863: ZOOKEEPER-3320: Leader election port
stop listen when hostname unresolvable for some time
URL: https://github.com/apache/zookeeper/pull/863
This is an automated message from
Lagrang closed pull request #863: ZOOKEEPER-3320: Leader election port stop
listen when hostname unresolvable for some time
URL: https://github.com/apache/zookeeper/pull/863
This is an automated message from the Apache Git
Lagrang closed pull request #863: ZOOKEEPER-3320: Leader election port stop
listen when hostname unresolvable for some time
URL: https://github.com/apache/zookeeper/pull/863
This is an automated message from the Apache Git
Lagrang opened a new pull request #863: ZOOKEEPER-3320: Leader election port
stop listen when hostname unresolvable for some time
URL: https://github.com/apache/zookeeper/pull/863
This is an automated message from
enixon commented on issue #863: ZOOKEEPER-3320: Leader election port stop
listen when hostname unresolvable for some time
URL: https://github.com/apache/zookeeper/pull/863#issuecomment-475707431
LGTM! The test failure
(NonRecoverableErrorTest::testZooKeeperServiceAvailableOnLeader) looks
maoling commented on issue #863: ZOOKEEPER-3320: Leader election port stop
listen when hostname unresolvable for some time
URL: https://github.com/apache/zookeeper/pull/863#issuecomment-475644114
@Lagrang if you're interested in the same issue, you can step into [this
](https
Lagrang commented on a change in pull request #863: ZOOKEEPER-3320: Leader
election port stop listen when hostname unresolvable for some time
URL: https://github.com/apache/zookeeper/pull/863#discussion_r268053495
##
File path:
zookeeper-server/src/main/java/org/apache/zookeeper
enixon commented on a change in pull request #863: ZOOKEEPER-3320: Leader
election port stop listen when hostname unresolvable for some time
URL: https://github.com/apache/zookeeper/pull/863#discussion_r267946154
##
File path:
zookeeper-server/src/main/java/org/apache/zookeeper
-3.5, but as far as a know,
this error can happen on master branch. If needed, I can create another pull
request for master.
> Leader election port stop listen when hostname unresolvable for some t
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated ZOOKEEPER-3320:
--
Labels: pull-request-available (was: )
> Leader election port stop listen w
Lagrang opened a new pull request #863: ZOOKEEPER-3320: Leader election port
stop listen when hostname unresolvable for some time
URL: https://github.com/apache/zookeeper/pull/863
This is an automated message from
. Either something like
"election port bind time" or "dns unavailable time" if we want to be more
general. Do you want to contribute a short diff?
This may also be related to ZOOKEEPER-2982 (or may not, making a note to check
later).
> Leader election port stop listen whe
server will
continue to run without leader election participation:)
??Looking at this from the opposite direction, can you add the desired delay in
the startup sequence of your Kubernetes container? My concern is that the
pattern of "DNS is currently unreliable but will be reliable soon&q
in
the startup sequence of your Kubernetes container? My concern is that the
pattern of "DNS is currently unreliable but will be reliable soon" seems
specific to the container management and may result in strange behavior when
applied to other environments.
> Leader election port sto
that in
some circumstances Zookeeper node stop listening on leader election port. This
cause unavailability of ZK cluster.
Zookeeper deployed as StatefulSet in term of Kubernetes and has following
dynamic configuration:
{code:java}
zookeeper-0.zookeeper:2182:2183:participant;2181
zookeeper-1
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Skokov updated ZOOKEEPER-3320:
---
Summary: Leader election port stop listen when hostname unresolvable for
some time
Igor Skokov created ZOOKEEPER-3320:
--
Summary: Don't give up on bind of leader election port
Key: ZOOKEEPER-3320
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3320
Project: ZooKeeper
cluster, we restarted one node and after an hour it still has not
joined the quorum.
stat and mntr show "This ZooKeeper instance is not currently serving requests".
> fast leader election keeps failing
> --
>
> Key: ZOOKEEPER-2164
Dinesh Appavoo created ZOOKEEPER-3247:
-
Summary: New lest admin command to get leader election time
Key: ZOOKEEPER-3247
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3247
Project: ZooKeeper
>> Can we reduce this time by configuring "syncLimit" and "tickTime" to
let's say 5 seconds? Can we have a strong
guarantee on this time bound?
It's not possible to guarantee the time bound, because of FLP impossibility
(reliable failure detection is not possible in async environment). Though
hat all replicas only
> acknowledge writes with their idea of the current epoch for an object.
>
> What happens in the even of partition is that we have a few possible cases,
> but in any case where data replicas are split by a partition, writes will
> fail triggering a new leader election. Only
een the observer and the participants in the
> leader election algorithm
> -
>
> Key: ZOOKEEPER-2461
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2461
>
will
fail triggering a new leader election. Only replicas on the side of the new
ZK quorum (which may be the old quorum) have a chance of succeeding here.
If the replicas are split away from the ZK quorum, writes may not be
possible until the partition heals. If a new leader is elected
Thanks, Maciej. That sounds good. We will try playing with the parameters
and have at least a known upper limit on the inconsistency interval.
On Fri, Dec 7, 2018 at 2:11 AM Maciej Smoleński wrote:
> On Fri, Dec 7, 2018 at 3:03 AM Michael Borokhovich
> wrote:
>
> > We are planning to run
her ZK nodes. So, another client may take leadership while the
> > current leader still unaware of the change. Is it true?
> >
> > Another follow up question. If Zookeeper can guarantee a single leader,
> is
> > it worth using it just for leader election? Maybe
Makes sense. Thanks, Ted. We will design our system to cope with the short
periods where we might have two leaders.
On Thu, Dec 6, 2018 at 11:03 PM Ted Dunning wrote:
> ZK is able to guarantee that there is only one leader for the purposes of
> updating ZK data. That is because all commits have
On Fri, Dec 7, 2018 at 3:03 AM Michael Borokhovich
wrote:
> We are planning to run Zookeeper nodes embedded with the client nodes.
> I.e., each client runs also a ZK node. So, network partition will
> disconnect a ZK node and not only the client.
> My concern is about the following statement
ZK is able to guarantee that there is only one leader for the purposes of
updating ZK data. That is because all commits have to originate with the
current quorum leader and then be acknowledged by a quorum of the current
cluster. IF the leader can't get enough acks, then it has de facto lost
We are planning to run Zookeeper nodes embedded with the client nodes.
I.e., each client runs also a ZK node. So, network partition will
disconnect a ZK node and not only the client.
My concern is about the following statement from the ZK documentation:
"Timeliness: The clients view of the system
Tweak timeout is tempting as your solution might work most of the time yet
fail in certain cases (which others have pointed out). If the goal is
absolute correctness then we should avoid timeout, which does not guarantee
correctness as it only makes the problem hard to manifest. Fencing is the
> Old service leader will detect network partition max 15 seconds after it
> happened.
If the old service leader is in a very long GC it will not detect the
partition. In the face of VM pauses, etc. it's not possible to avoid 2 leaders
for a short period of time.
-JZ
er" client is connected to the partitioned ZK
> node,
> > it may be notified not at the same time as the other clients connected to
> > the other ZK nodes. So, another client may take leadership while the
> > current leader still unaware of the change. Is it true?
> >
> >
nt may take leadership while the
> current leader still unaware of the change. Is it true?
>
> Another follow up question. If Zookeeper can guarantee a single leader, is
> it worth using it just for leader election? Maybe we can use a more
> lightweight Hazelcast for example?
>
&g
same time as the other clients connected to
the other ZK nodes. So, another client may take leadership while the
current leader still unaware of the change. Is it true?
Another follow up question. If Zookeeper can guarantee a single leader, is
it worth using it just for leader election? Maybe
e have a service that runs on 3 hosts for high availability. However, at
> any given time, exactly one instance must be active. So, we are thinking to
> use Leader election using Zookeeper.
> To this goal, on each service host we also start a ZK server, so we have a
> 3-nodes ZK cluster and e
> suggest you use the ready-made implements of curator:
> http://curator.apache.org/curator-recipes/leader-election.html
> - 原始邮件 -
> 发件人：Michael Borokhovich
> 收件人："dev@zookeeper.apache.org"
> 主题：Leader election
> 日期：2018年12月06日 07点29分
>
> Hello,
Michael,
Leader election is not enough.
You must have some mechanism to fence off the partitioned leader.
If you are building a replicated state machine Apache Zookeeper + Apache
Bookkeeper can be a good choice
See this just an example:
https://github.com/ivankelly/bookkeeper-tutorial
ade implements of curator:
> http://curator.apache.org/curator-recipes/leader-election.html
> - 原始邮件 -
> 发件人：Michael Borokhovich
> 收件人："dev@zookeeper.apache.org"
> 主题：Leader election
> 日期：2018年12月06日 07点29分
>
> Hello,
> We have a service that runs o
suggest you use the ready-made implements of curator:
http://curator.apache.org/curator-recipes/leader-election.html
- 原始邮件 -
发件人：Michael Borokhovich
收件人："dev@zookeeper.apache.org"
主题：Leader election
日期：2018年12月06日 07点29分
Hello,
We have a service that runs on 3 host
Hello,
We have a service that runs on 3 hosts for high availability. However, at
any given time, exactly one instance must be active. So, we are thinking to
use Leader election using Zookeeper.
To this goal, on each service host we also start a ZK server, so we have a
3-nodes ZK cluster and each
ing time during Fast Leader Election
> -
>
> Key: ZOOKEEPER-1814
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1814
> Project: ZooKeeper
> Issue Type: Bug
> Co
or modified tests.
-1 patch. The patch command could not apply the patch.
Console output:
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3715//console
This message is automatically generated.
> Reduction of waiting time during Fast Leader Elect
branch-3.5?
> Reduction of waiting time during Fast Leader Election
> -
>
> Key: ZOOKEEPER-1814
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1814
> Project: ZooKeeper
>
branch-3.5 code?
> fast leader election keeps failing
> --
>
> Key: ZOOKEEPER-2164
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2164
> Project: ZooKeeper
> Issue Type: Bug
ain database in leader election
> --
>
> Key: ZOOKEEPER-2845
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2845
> Project: ZooKeeper
> Issue Type: Bug
again for moving this forward!
> Data inconsistency issue due to retain database in leader election
> --
>
> Key: ZOOKEEPER-2845
> URL: https://issues.apache.org/jira/browse
heavier and complexity, we may change to use
this simpler solution as well. Thanks again for moving this forward!
> Data inconsistency issue due to retain database in leader election
> --
>
> Key: ZO
://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/1932//console
This message is automatically generated.
> Exit when ZooKeeper cannot bind to the leader election port
> ---
>
> Key: ZOOKEEPER-3084
>
a separate pull request for the 3.5
branch?
I think that would be the easiest to get this done.
> Exit when ZooKeeper cannot bind to the leader election port
> ---
>
> Key: ZOOKEEPER-3084
>
[https://builds.apache.org/job/ZooKeeper-trunk/95/])
ZOOKEEPER-3084: Exit when ZooKeeper cannot bind to the leader election (hanm:
rev c2e7ed1e6f8f2de48778db7f3d63f9629c086ea8)
* (edit) src/java/main/org/apache/zookeeper/server/quorum/QuorumCnxManager.java
> Exit when ZooKeeper cannot b
/zookeeper/commit/c2e7ed1e6f8f2de48778db7f3d63f9629c086ea8]
tried to merge to 3.5 but there are merge conflicts. have this on record so we
can get this into 3.5 at some point before next release.
> Exit when ZooKeeper cannot bind to the leader election p
not bind to the leader election port
> ---
>
> Key: ZOOKEEPER-3084
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3084
> Project: ZooKeeper
> Issue Type: Improvement
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Han resolved ZOOKEEPER-3084.
Resolution: Fixed
> Exit when ZooKeeper cannot bind to the leader election p
per cannot bind to the leader election port
> ---
>
> Key: ZOOKEEPER-3084
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3084
> Project: ZooKeeper
> Is
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fangmin Lv updated ZOOKEEPER-3084:
--
Summary: Exit when ZooKeeper cannot bind to the leader election port (was:
Exit when zeus
Console output:
https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/1898//console
This message is automatically generated.
> Exit when zeus cannot bind to the leader election port
> --
>
> Key: ZO
not bind to the leader election port
> --
>
> Key: ZOOKEEPER-3084
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3084
> Project: ZooKeeper
> Issue Type: Improvement
>
Fangmin Lv created ZOOKEEPER-3084:
-
Summary: Exit when zeus cannot bind to the leader election port
Key: ZOOKEEPER-3084
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3084
Project: ZooKeeper
:
https://github.com/apache/zookeeper/pull/453
Thanks @afine I closed them.
> Data inconsistency issue due to retain database in leader election
> --
>
> Key: ZOOKEEPER-2845
>
at:
https://github.com/apache/zookeeper/pull/455
> Data inconsistency issue due to retain database in leader election
> --
>
> Key: ZOOKEEPER-2845
> URL: https://issues.apache.
1 - 100 of 588 matches
Mail list logo
