Vishal K updated ZOOKEEPER-335:

    Attachment: zklogs.tar.gz


I have attached the logs. The log entries are similar to those reported by 

We are testing with 3 nodes. Each node is run in a VM running SLES 11. All 3 
VMs are run on the same host. VMs are sharing the same disk. cpuinfo and 
meminfo for VM is in the attached file.
I have also tried to collect more info with -verbose:gc -Xloggc:/../ -Xprof 
options to java.

gc.lg contains the gc output
rest of the info should be in msgs.log
Default java heap size was used. java version  "1.6.0_18" was used.

One point to note - In my case, on the misbehaving node could not joing the 
cluster. Rest of the cluster was stable (except for the flood of log messages 
on the leader because the misbehaving follower kept terminating session).

Hope this helps.

> 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.

Reply via email to