hadoop-zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Flavio Paiva Junqueira (JIRA)" <j...@apache.org>
Subject [jira] Commented: (ZOOKEEPER-335) zookeeper servers should commit the new leader txn to their logs.
Date Fri, 18 Jun 2010 20:49:24 GMT

    [ https://issues.apache.org/jira/browse/ZOOKEEPER-335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12880320#action_12880320

Flavio Paiva Junqueira commented on ZOOKEEPER-335:

Guys, I don't see enough information in these logs to determine what's going on. Let me tell
you what I'm seeing so that perhaps other folks can help me out here. 

One part of the log that is suspicious is this one:

=6693 [QuorumPeer:/] WARN  org.apache.zookeeper.server.quorum.Learner  - Got zxid
0x300000001 expected 0x1
=6693 [QuorumPeer:/] WARN  org.apache.zookeeper.server.quorum.Learner  - Got zxid
0x300000001 expected 0x1
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor30]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor27]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor22]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor23]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor18]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor20]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor19]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor31]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor21]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor26]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor25]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor33]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor29]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor28]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor24]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor32]

************* NODE RESTARTED HERE **********************

Before being restarted, the bad node receives a proposal with zxid <3,1> and it expects
<0,1>. Next in the logs after being restarted, I can see that it is complaining that
it has epoch 4 and the leader 3. Something strange apparently happened during the restart.
It also seems to be the case that the node was being able to talk to the others (first entries
in the log before the excerpt above).

Do you guys see anything I'm overlooking?

> zookeeper servers should commit the new leader txn to their logs.
> -----------------------------------------------------------------
>                 Key: ZOOKEEPER-335
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-335
>             Project: Zookeeper
>          Issue Type: Bug
>          Components: server
>    Affects Versions: 3.1.0
>            Reporter: Mahadev konar
>            Assignee: Mahadev konar
>            Priority: Blocker
>             Fix For: 3.4.0
>         Attachments: zk.log.gz, zklogs.tar.gz
> currently the zookeeper followers do not commit the new leader election. This will cause
problems in a failure scenarios with a follower acking to the same leader txn id twice, which
might be two different intermittent leaders and allowing them to propose two different txn's
of the same zxid.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message