[
https://issues.apache.org/jira/browse/ZOOKEEPER-1124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13064710#comment-13064710
]
Marshall McMullen commented on ZOOKEEPER-1124:
----------------------------------------------
I agree with Ted's comment regarding the default here is to fail (drop on
floor) when new op types are added. I thought of throwing an exception if it
wasn't in the switch so it would fail at runtime instead of silently failing as
it does now. But perhaps the better answer is to instead of enumerating all op
types, just pass them all through to the appropriate Observer/Follower. Then
let it deal with throwing an exception if the type isn't supported. That or if
there are explicit types not supported by an observer/follower, deal with those
explicitly then assume the rest are valid and pass them along.
> Multiop submitted to non-leader always fails due to timeout
> -----------------------------------------------------------
>
> Key: ZOOKEEPER-1124
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1124
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
> Affects Versions: 3.4.0
> Environment: all
> Reporter: Marshall McMullen
> Priority: Critical
> Fix For: 3.4.0
>
> Attachments: multi-non-observer.patch
>
>
> The new Multiop support added under zookeeper-965 fails every single time if
> the multiop is submitted to a non-leader in quorum mode. In standalone mode
> it always works properly and this bug only presents itself in quorum mode
> (with 2 or more nodes). After 12 hours of debugging (*sigh*) it turns out to
> be a really simple fix. There are a couple of missing case statements inside
> FollowerRequestProcessor.java and ObserverRequestProcessor.java to ensure
> that multiop is forwarded to the leader for commit. I've attached a patch
> that fixes this problem.
> It's probably worth nothing that zookeeper-965 has already been committed to
> trunk. But this is a fatal flaw that will prevent multiop support from
> working properly and as such needs to get committed to 3.4.0 as well. Is
> there a way to tie these two cases together in some way?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
