[jira] [Commented] (ZOOKEEPER-1495) ZK client hangs when using a function not available on the server.

["Skye Wanderman-Milne (JIRA)" <ji...@apache.org>]

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

Skye Wanderman-Milne commented on ZOOKEEPER-1495:
-------------------------------------------------

This overall looks good to me. I'm not convinced a separate UnimplementedRequestProcessor is necessary since you could just do the work inline in ZooKeeperServer.submitRequest, but it doesn't make a big difference either way.  The chroot business in your test seems unnecessary -- you're not creating a client with a chroot, and the request shouldn't be processed anyway. You're also creating an ExistsRequest and then a SetDataResponse (although the net result is the same). Maybe clean up the test and resubmit?

One thing to note is that if ZOOKEEPER-1599 is fixed, it will still be possible for 3.4 leaders to send multis to 3.3 followers. We can consider a solution for that problem depending on how ZOOKEEPER-1599 is resolved.
                
> ZK client hangs when using a function not available on the server.
> ------------------------------------------------------------------
>
>                 Key: ZOOKEEPER-1495
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1495
>             Project: ZooKeeper
>          Issue Type: Bug
>          Components: server
>    Affects Versions: 3.4.2, 3.3.5
>         Environment: all
>            Reporter: nkeywal
>            Assignee: nkeywal
>            Priority: Minor
>         Attachments: 1495.br33.v3.patch
>
>
> This happens for example when using zk#multi with a 3.4 client but a 3.3 server.
> The issue seems to be on the server side: the servers drops the packets with an unknown OpCode in ZooKeeperServer#submitRequest
> {noformat}
> public void submitRequest(Request si) {
>     // snip
>     try {
>         touch(si.cnxn);
>         boolean validpacket = Request.isValid(si.type); // ===> Check on case OpCode.*
>         if (validpacket) {
>             // snip
>         } else {
>             LOG.warn("Dropping packet at server of type " + si.type);
>             // if invalid packet drop the packet.
>         }
>     } catch (MissingSessionException e) {
>         if (LOG.isDebugEnabled()) {
>             LOG.debug("Dropping request: " + e.getMessage());
>         }
>     }
> }
> {noformat}
> The solution discussed in ZOOKEEPER-1381 would be to get an exception on the client side then & close the session.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira