[jira] Commented: (HBASE-2380) Update to zookeeper 3.3.0

["stack (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/HBASE-2380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12849919#action_12849919 ] 

stack commented on HBASE-2380:
------------------------------

Of note, new clients are not supported working with older ensemble members (Thanks to Patrick Hunt for clarification on this one):

{code}
14:35 < phunt> stack: I compared the jute files and a new api method (new marshalling object) was added to 3.3, so if you don't use that in general it will work.
14:36 < phunt> stack: but we don't test this, and some changes at the semantic/timing/etc... level of the protocol may cause issues.
14:36 < stack> phunt: do I have to call new api to use new marshaller?
14:36 < phunt> stack: so "officially" we don't support, but if you did your own testing....
14:36 < phunt> stack: new object type, same marshaller
14:37 < stack> phunt: I was just reporting an observation made eval'ing 3.3.0
14:37 < stack> Didn't realize it wasn't supported
14:37 < phunt> stack: new api call I'm saying (getchildren2)
14:37 < stack> Thanks for update
14:37 < phunt> stack: understood. Just wanted to make sure you were aware.
14:37 < stack> thanks.
14:37 < stack> let me respond to your prompting over on zk-dev
14:37 < phunt> stack: you could always test it and verify for your use cases....
14:38 < phunt> stack: but officially we always support b/w compat on the servers, but not necess the clients.
14:38 < phunt> stack: for example in 3.1->3.2 I believe that the clients will not work... we added some fields to the Stat object
14:39 < phunt> stack: but in this case we addeed a whole new api method, if you tried to use this specific method it would fail, but otw might be fine.
14:39 < jdcryans> civascu: hard to tell, fsck?
14:39 < phunt> stack: but then the issue just falls to the fact that we don't specifically test this case.
14:40 < civascu> jdcryans: yeah, moving the edits to the cluster now, and will run diag first thing
14:40 < civascu> jdcryans: it will take a while
14:41 < stack> phunt: my cluster uses extant zk ensemble... it was just odd to me that it 'worked'.. but it did
14:41 -!- mivert [~mivert@208.78.39.48] has joined #hbase
14:41 < stack> thanks for heads-up phunt 
14:41 < phunt> stack: "unofficially" it might be fine. ;-)
14:42 < phunt> stack: any issue other than the obv? ie you need to upgrade the server then the client?
14:42 < phunt> stack: re hbase use I mean.
14:42 < phunt> stack: good to get out there on the zk dev list if there is. to help shape future changes.
14:45 < stack> phunt: let me add this fact to the hbase issue for upgrading... see if a reaction.   we might want to wait if it requires ensembleis updated
14:46  * jdcryans reacts
14:46 < phunt> stack: upgrading the ensemble means rolling upgrade (servers are b/w compat at the quourm level as well) - so really just shutdown, upgrade code, bringup. that's it.
14:47 < jdcryans> I think it won't be a problem for those that let hbase manage ZK
14:47 < phunt> stack: once that's done clients can similarly be upgraded (incrementally I mean)
14:47 < jdcryans> phunt: 0.20.4 is breaking compat, so that won't be a problem
14:48 < jdcryans> the only issue I see is ppl putting ZK on a separate cluster and who forgot about it
14:48 < jdcryans> (maybe that reminds you of a certain crew :P )
14:48 < phunt> jdcryans: any user could upgrade ZK ensemble today. w/o upgrading hbase
14:49 < phunt> jdcryans: and it should work
14:49 < phunt> jdcryans: so there's def an upgrade path, but not "any client works with any server". unfort to keep things sane we need to limit some variables.
14:50  * stack jdcryans yes it reminds me of a certain cowboy outfit
14:50 < phunt> jdcryans: at the same time we want to encourage ppl to upgrade (fixes in particular) so hopefully we are doing enough in this area. this is why I suggest stack messaging our dev list.
{code}

> Update to zookeeper 3.3.0
> -------------------------
>
>                 Key: HBASE-2380
>                 URL: https://issues.apache.org/jira/browse/HBASE-2380
>             Project: Hadoop HBase
>          Issue Type: Improvement
>            Reporter: stack
>         Attachments: zk330.patch
>
>
> It has:
> {code}
>   ZOOKEEPER-593.  java client api does not allow client to access negotiated
>   session timeout (phunt via mahadev)
>   ZOOKEEPER-587.  client should log timeout negotiated with server
>   (phunt via mahadev)
> {code}
> among a bunch of other fixes, as well some cleaned up logging and it'll be published to a maven repo.

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