[
https://issues.apache.org/jira/browse/ZOOKEEPER-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12745372#action_12745372
]
Flavio Paiva Junqueira commented on ZOOKEEPER-512:
--------------------------------------------------
I'm not convinced this is a bug. Right now it sounds to me that the problem is
with the way you're injecting faults. More concretely, it sounds like some
threads are getting IOException, but the corresponding socket is not closing.
As recv and sender come in pairs, if one dies and the other doesn't, we have a
problem. At the same time, I believe the current code would eventually
terminate a pair of workers send/recv if the socket closes. It is true, though,
that the current code assumes that if RecvWorker catches an IOException when
performing an socket operation, then the corresponding SendWorker will also
catch an exception when trying to write to the socket. This is where I think
your framework is broken, but please correct me if I'm missing anything.
> FLE election fails to elect leader
> ----------------------------------
>
> Key: ZOOKEEPER-512
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-512
> Project: Zookeeper
> Issue Type: Bug
> Components: quorum, server
> Affects Versions: 3.2.0
> Reporter: Patrick Hunt
> Priority: Blocker
> Fix For: 3.2.1, 3.3.0
>
> Attachments: jst.txt, logs.tar.gz
>
>
> I was doing some fault injection testing of 3.2.1 with ZOOKEEPER-508 patch
> applied and noticed that after some time the ensemble failed to re-elect a
> leader.
> See the attached log files - 5 member ensemble. typically 5 is the leader
> Notice that after 16:23:50,525 no quorum is formed, even after 20 minutes
> elapses w/no quorum
> environment:
> I was doing fault injection testing using aspectj. The faults are injected
> into socketchannel read/write, I throw exceptions randomly at a 1/200 ratio
> (rand.nextFloat() <= .005 => throw IOException
> You can see when a fault is injected in the log via:
> 2009-08-19 16:57:09,568 - INFO [Thread-74:readrequestfailsintermitten...@38]
> - READPACKET FORCED FAIL
> vs a read/write that didn't force fail:
> 2009-08-19 16:57:09,568 - INFO [Thread-74:readrequestfailsintermitten...@41]
> - READPACKET OK
> otw standard code/config (straight fle quorum with 5 members)
> also see the attached jstack trace. this is for one of the servers. Notice in
> particular that the number of sendworkers != the number of recv workers.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
