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

Todd Lipcon commented on HBASE-2791:
------------------------------------

I agree, warning and continuing is almost always the wrong thing to do.

Last weekend I took an hour or so and prototyped some wrapper APIs here:
http://github.com/toddlipcon/hbase/blob/zk-cleanup/src/main/java/org/apache/hadoop/hbase/zookeeper/ZKAction.java

These APIs let you do stuff like:
{code}
ZKAction.create("/foo").doOrThrowRTE() vs
ZKAction.create("/foo").withWatcher(this).onExceptionReturn(KeeperException.Foo.class,
 false).doOrThrowIOE()
{code}
Having convenient shorthand to "do the right thing" will probably discourage 
people from the lazy IDE autocomplete exception ignoring that we often do.

> Stop dumping exceptions coming from ZK and do nothing about them
> ----------------------------------------------------------------
>
>                 Key: HBASE-2791
>                 URL: https://issues.apache.org/jira/browse/HBASE-2791
>             Project: HBase
>          Issue Type: Improvement
>            Reporter: Jean-Daniel Cryans
>             Fix For: 0.21.0
>
>
> I think this is part of the Master/ZooKeeper refactoring project but I'm 
> putting it up here to be sure we cover it. Currently in ZKW (and other places 
> around the code base) we do ZK operations and we don't really handle the 
> exceptions, for example in ZKW.setClusterState:
> {code}
>     } catch (InterruptedException e) {
>       LOG.warn("<" + instanceName + ">" + "Failed to set state node in 
> ZooKeeper", e);
>     } catch (KeeperException e) {
>       if(e.code() == KeeperException.Code.NODEEXISTS) {
>         LOG.debug("<" + instanceName + ">" + "State node exists.");
>       } else {
>         LOG.warn("<" + instanceName + ">" + "Failed to set state node in 
> ZooKeeper", e);
>       }
> {code}
> This has been always like that since we started using ZK.
> What if the session was expired? What if it was only the connection that had 
> a blip? Do we handle it correctly? We need to have this discussion.

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