[jira] [Created] (ZOOKEEPER-3528) Revisit AsyncCallback javadoc
TisonKun created ZOOKEEPER-3528: --- Summary: Revisit AsyncCallback javadoc Key: ZOOKEEPER-3528 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3528 Project: ZooKeeper Issue Type: Sub-task Components: documentation Affects Versions: 3.6.0 Reporter: TisonKun Assignee: TisonKun Fix For: 3.6.0 -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (ZOOKEEPER-3523) Replace dummy watcher with a unified singleton
TisonKun created ZOOKEEPER-3523:
---
Summary: Replace dummy watcher with a unified singleton
Key: ZOOKEEPER-3523
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3523
Project: ZooKeeper
Issue Type: Improvement
Components: server, tests
Affects Versions: 3.6.0
Reporter: TisonKun
Assignee: TisonKun
Fix For: 3.6.0
Currently we have many anonymous subclasses of {{Watch}} all of which is just
{{event -> \{ }}}. We can reduce many subclasses in inherit tree by add a
{{DUMMY_WATCHER}} in {{Watcher}} interface and replace all of those usages.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (ZOOKEEPER-3521) equals generate by jute potentially cause NPE
TisonKun created ZOOKEEPER-3521:
---
Summary: equals generate by jute potentially cause NPE
Key: ZOOKEEPER-3521
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3521
Project: ZooKeeper
Issue Type: Bug
Components: jute
Affects Versions: 3.6.0
Reporter: TisonKun
Assignee: TisonKun
Fix For: 3.6.0
jute generate {{equals}} as follow
{code:java}
String genJavaEquals(String fname, String peer) {
return "ret = " + fname + ".equals(" + peer + ");\n";
}
{code}
if {{fname}} is null at the runtime, then a {{NullPointerException}} would be
thrown, see [this
report|https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build-maven/org.apache.zookeeper$zookeeper/1167/testReport/junit/org.apache.zookeeper.server/PrepRequestProcessorTest/testPRequest/]
for instance.
Java already solved this problem by using {{java.util.Objetcs.equals}}, I
address this issue along with ZOOKEEPER-3290 in GH-839. But I need input from
CPP and CSharp side.
BTW, is there anybody use jute's CSharp version or even CPP version?
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (ZOOKEEPER-3520) KeeperException is good to have a error message field besides path
TisonKun created ZOOKEEPER-3520:
---
Summary: KeeperException is good to have a error message field
besides path
Key: ZOOKEEPER-3520
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3520
Project: ZooKeeper
Issue Type: Bug
Components: server
Reporter: TisonKun
We trickily set a diagnosis msg as {{path}} of {{KeeperException}} in
{{CreateMode}}(see code snippet below) because {{KeeperException}} doesn't have
a dedicated error message field. It is good to have a {{diagnosis}} field
beside {{path}} for error message beyond a path.
{code:java}
// CreateMode#L136
String errMsg = "Received an invalid flag value: " + flag + " to convert to a
CreateMode";
LOG.error(errMsg);
throw new KeeperException.BadArgumentsException(errMsg);
{code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (ZOOKEEPER-3517) Turn on BookKeeper checkstyle configuration at project level
TisonKun created ZOOKEEPER-3517:
---
Summary: Turn on BookKeeper checkstyle configuration at project
level
Key: ZOOKEEPER-3517
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3517
Project: ZooKeeper
Issue Type: Sub-task
Components: build
Reporter: TisonKun
Assignee: TisonKun
Fix For: 3.6.0
while still use the simple for {{zookeeper-contrib}} because it is not worth to
be applied.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (ZOOKEEPER-3509) Revisit log format
TisonKun created ZOOKEEPER-3509: --- Summary: Revisit log format Key: ZOOKEEPER-3509 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3509 Project: ZooKeeper Issue Type: Improvement Components: server Reporter: TisonKun Currently ZooKeeper mixes up different log format and even a number of log statements are buggy. It is an opportunity that we revisit log format in ZooKeeper and do a pass to fix all log format related issues. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (ZOOKEEPER-3508) Strategy on line break
TisonKun created ZOOKEEPER-3508: --- Summary: Strategy on line break Key: ZOOKEEPER-3508 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3508 Project: ZooKeeper Issue Type: Improvement Reporter: TisonKun While enabling checkstyle configuration on zookeeper-server module, it raises the discussion that how we generally break/wrap long lines. Whether or not we introduce a standard and if so, how we ensure it is obeyed. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (ZOOKEEPER-3507) Revisit name patterns
TisonKun created ZOOKEEPER-3507: --- Summary: Revisit name patterns Key: ZOOKEEPER-3507 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3507 Project: ZooKeeper Issue Type: Improvement Reporter: TisonKun While enabling checkstyle configuration on zookeeper-server, it raises the discussion that how we treat variable/type names out of suggested pattern. Backward compatibility and a consistent view should be taken into consideration. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (ZOOKEEPER-3475) Enable BookKeeper checkstyle configuration on zookeeper-server
TisonKun created ZOOKEEPER-3475: --- Summary: Enable BookKeeper checkstyle configuration on zookeeper-server Key: ZOOKEEPER-3475 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3475 Project: ZooKeeper Issue Type: Sub-task Components: build Affects Versions: 3.6.0 Reporter: TisonKun Assignee: TisonKun Fix For: 3.6.0 Enable BookKeeper checkstyle configuration on zookeeper-server -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (ZOOKEEPER-3474) Enable BookKeeper checkstyle configuration on zookeeper-promethus
TisonKun created ZOOKEEPER-3474: --- Summary: Enable BookKeeper checkstyle configuration on zookeeper-promethus Key: ZOOKEEPER-3474 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3474 Project: ZooKeeper Issue Type: Sub-task Components: build Affects Versions: 3.6.0 Reporter: TisonKun Assignee: TisonKun Fix For: 3.6.0 Enable BookKeeper checkstyle configuration on zookeeper-promethus -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (ZOOKEEPER-3469) Enable checkEmptyJavadoc checkstyle rule
TisonKun created ZOOKEEPER-3469: --- Summary: Enable checkEmptyJavadoc checkstyle rule Key: ZOOKEEPER-3469 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3469 Project: ZooKeeper Issue Type: Improvement Components: build Reporter: TisonKun While introducing BookKeeper checkstyle rules(see ZOOKEEPER-3431), we find it worth to have a rule about javadocs of public classes. Specifically, check the javadocs of public class not empty but valid. However, providing valid javadocs for public classes those do not have one at the moment is not a trivial work. Thus we file this issue to track another pass for doing so. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (ZOOKEEPER-3468) Enable BookKeeper checkstyle configuration on zookeeper-jute
TisonKun created ZOOKEEPER-3468: --- Summary: Enable BookKeeper checkstyle configuration on zookeeper-jute Key: ZOOKEEPER-3468 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3468 Project: ZooKeeper Issue Type: Sub-task Components: build Reporter: TisonKun Assignee: TisonKun Enable BookKeeper checkstyle configuration on zookeeper-jute -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (ZOOKEEPER-3465) Introduce Google checkstyle configuration
TisonKun created ZOOKEEPER-3465: --- Summary: Introduce Google checkstyle configuration Key: ZOOKEEPER-3465 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3465 Project: ZooKeeper Issue Type: Sub-task Reporter: TisonKun Fix For: 3.6.0 For enable Google checkstyle configuration, we introduce a silent configuration. [~maoling] I'm not familiar with google checkstyle configuration, and it would be great if you can take over this jira. Otherwise I'd like to process it this weekend. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (ZOOKEEPER-3446) Enable UnusedImports checkstyle rules
TisonKun created ZOOKEEPER-3446:
---
Summary: Enable UnusedImports checkstyle rules
Key: ZOOKEEPER-3446
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3446
Project: ZooKeeper
Issue Type: Improvement
Components: build
Affects Versions: 3.5.6
Reporter: TisonKun
Assignee: TisonKun
Fix For: 3.5.6
Propose enabling {{UnusedImports}} checkstyle rules in all modules.
cc [~andorm] [~eolivelli] for decision.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (ZOOKEEPER-3391) Drop unused CSVInputArchive and XMLInputArchive
TisonKun created ZOOKEEPER-3391: --- Summary: Drop unused CSVInputArchive and XMLInputArchive Key: ZOOKEEPER-3391 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3391 Project: ZooKeeper Issue Type: Improvement Components: jute Reporter: TisonKun As described in http://zookeeper-user.578899.n2.nabble.com/Deprecated-CSVInputArchive-and-XMLInputArchive-td7584086.html these 2 input archives are not actively maintained and we probably don't have test coverage for them either, so keeping them in the codebase could be questionable. So this is the ticket to track dropping unused CSVInputArchive and XMLInputArchive -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ZOOKEEPER-3370) Remove SVN specific revision generation
TisonKun created ZOOKEEPER-3370: --- Summary: Remove SVN specific revision generation Key: ZOOKEEPER-3370 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3370 Project: ZooKeeper Issue Type: Improvement Components: build Reporter: TisonKun Assignee: TisonKun Continue the SVN to Git Port -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ZOOKEEPER-3350) Get rid of CommonNames
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16820725#comment-16820725
]
TisonKun commented on ZOOKEEPER-3350:
-
Well, I can see the evolution. Now DataTreeKey has gone into
{{DataTreeBean#getName}} and similarly "StandaloneServer" has gone into
{{ZooKeeperServerBean#getName}}.
Regarding the DOMAIN field usage I'd like to move it as
{{MBeanRegistry.DOMAIN}} and remove CommonNames.
> Get rid of CommonNames
> --
>
> Key: ZOOKEEPER-3350
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3350
> Project: ZooKeeper
> Issue Type: Improvement
> Components: jmx
>Affects Versions: 3.5.4
>Reporter: TisonKun
>Assignee: TisonKun
>Priority: Major
> Fix For: 3.5.5
>
>
> Inside {{CommonNames}} it says {{TODO: will get rid of it eventually.}}.
> However, I don't see the reason of such removal and since it came from over
> ten years ago I'd like to know whether it is still valid.
> cc [~phunt] [~anmolnar]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ZOOKEEPER-3350) Get rid of CommonNames
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16820721#comment-16820721
]
TisonKun commented on ZOOKEEPER-3350:
-
Technically I agree with [~maoling].
However, it confuses me the TODO comment says "will get rid of it eventually".
{{CommonNames.DOMAIN}} is a constance that used to be shown on JMX. I'd prefer
learn the evolution of JMX usage in ZK.
> Get rid of CommonNames
> --
>
> Key: ZOOKEEPER-3350
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3350
> Project: ZooKeeper
> Issue Type: Improvement
> Components: jmx
>Affects Versions: 3.5.4
>Reporter: TisonKun
>Assignee: TisonKun
>Priority: Major
> Fix For: 3.5.5
>
>
> Inside {{CommonNames}} it says {{TODO: will get rid of it eventually.}}.
> However, I don't see the reason of such removal and since it came from over
> ten years ago I'd like to know whether it is still valid.
> cc [~phunt] [~anmolnar]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ZOOKEEPER-3351) Migrate qa-test-pullrequest ant task to maven
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816853#comment-16816853
]
TisonKun commented on ZOOKEEPER-3351:
-
[~eolivelli] is there an umbrella issue about drop ANT?
> Migrate qa-test-pullrequest ant task to maven
> -
>
> Key: ZOOKEEPER-3351
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3351
> Project: ZooKeeper
> Issue Type: Improvement
> Components: build
>Affects Versions: 3.5.5
>Reporter: Enrico Olivelli
>Assignee: Enrico Olivelli
>Priority: Major
> Labels: pull-request-available
> Fix For: 3.6.0
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> In order to drop ANT we have to migrate task qa-test-pullrequest to Maven.
> That task is currently called this way in ASF Jenkins:
> {code:java}
> #!/bin/bash
> set +x
> #export JAVA_HOME=/home/jenkins/tools/java/jdk1.7.0-64
> export ANT_HOME=/home/jenkins/tools/ant/apache-ant-1.9.9
> #export PATH=$PATH:$JAVA_HOME/bin:$ANT_HOME/bin:
> export PATH=$PATH:$LATEST1_8_HOME/bin:$ANT_HOME/bin:
> export PATCH_DIR=${WORKSPACE}/patchprocess
> if [ ! -e "$PATCH_DIR" ] ; then
> mkdir -p $PATCH_DIR
> fi
> pwd
> git status
> git rev-parse HEAD
> which java
> java -version
> ulimit -a
> env
> ${ANT_HOME}/bin/ant \
> -Dpatch.file=foobar \
> -Dscratch.dir=$PATCH_DIR \
> -Dps.cmd=/bin/ps \
> -Dwget.cmd=/usr/bin/wget \
> -Djiracli.cmd=/home/jenkins/tools/jiracli/latest/jira.sh \
> -Dgit.cmd=/usr/bin/git \
> -Dgrep.cmd=/bin/grep \
> -Dpatch.cmd=/usr/bin/patch \
> -Dfindbugs.home=/home/jenkins/tools/findbugs/latest/ \
> -Dforrest.home=/home/jenkins/tools/forrest/latest/ \
> -Djira.passwd= \
> -Djava5.home=/home/jenkins/tools/java5/latest/ \
> -Dcurl.cmd=/usr/bin/curl \
> -Dtest.junit.maxmem=2g \
> qa-test-pullrequest{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (ZOOKEEPER-3350) Get rid of CommonNames
TisonKun created ZOOKEEPER-3350:
---
Summary: Get rid of CommonNames
Key: ZOOKEEPER-3350
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3350
Project: ZooKeeper
Issue Type: Improvement
Components: jmx
Affects Versions: 3.5.4
Reporter: TisonKun
Fix For: 3.5.5
Inside {{CommonNames}} it says {{TODO: will get rid of it eventually.}}.
However, I don't see the reason of such removal and since it came from over ten
years ago I'd like to know whether it is still valid.
cc [~phunt] [~anmolnar]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ZOOKEEPER-3289) Throw KeeperException with path in DataTree operations
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1604#comment-1604
]
TisonKun commented on ZOOKEEPER-3289:
-
[~maoling] I closed this JIRA because its description is quite specific, and
create ZOOKEEPER-3290 (Throw detailed KeeperException when a transaction
failed) for filing the original user problem and sharing my analysis.
Sorry for the noise and I would be glad to listen to your advice there.
> Throw KeeperException with path in DataTree operations
> --
>
> Key: ZOOKEEPER-3289
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3289
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
>Affects Versions: 3.5.4, 3.4.13
>Reporter: TisonKun
>Priority: Major
> Fix For: 3.5.5, 3.4.14
>
>
> Currently, if ZooKeeper delete a znode that does not exist. It throws a
> {{KeeperException.NoNodeException}} without path message. It causes
> difficulty when user debug with ZooKeeper. For example,
> Assume we try to do a transaction(with Curator encapsulation)
> {code:java}
> client.inTransaction()
>.check().forPath(path1).and()
>.delete().forPath(path2).and()
>.commit()
> {code}
> if the statement throw an exception {{KeeperException.NoNodeException}}
> without path information, we can hardly know that it failed at {{check}} or
> {{delete}}.
> Thus I propose throws KeeperException with path in DataTree operations. We
> can achieve this without burden.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (ZOOKEEPER-3289) Throw KeeperException with path in DataTree operations
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
TisonKun resolved ZOOKEEPER-3289.
-
Resolution: Not A Problem
See ZOOKEEPER-3290 for the origin user problem and analysis.
> Throw KeeperException with path in DataTree operations
> --
>
> Key: ZOOKEEPER-3289
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3289
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
>Affects Versions: 3.5.4, 3.4.13
>Reporter: TisonKun
>Priority: Major
> Fix For: 3.5.5, 3.4.14
>
>
> Currently, if ZooKeeper delete a znode that does not exist. It throws a
> {{KeeperException.NoNodeException}} without path message. It causes
> difficulty when user debug with ZooKeeper. For example,
> Assume we try to do a transaction(with Curator encapsulation)
> {code:java}
> client.inTransaction()
>.check().forPath(path1).and()
>.delete().forPath(path2).and()
>.commit()
> {code}
> if the statement throw an exception {{KeeperException.NoNodeException}}
> without path information, we can hardly know that it failed at {{check}} or
> {{delete}}.
> Thus I propose throws KeeperException with path in DataTree operations. We
> can achieve this without burden.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (ZOOKEEPER-3290) Throw detailed KeeperException when a transaction failed
TisonKun created ZOOKEEPER-3290:
---
Summary: Throw detailed KeeperException when a transaction failed
Key: ZOOKEEPER-3290
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3290
Project: ZooKeeper
Issue Type: Improvement
Components: server
Affects Versions: 3.4.13, 3.5.4
Reporter: TisonKun
Fix For: 3.5.5, 3.4.14
Assume we execute the follow statements
{code:java}
ZooKeeper zk = ...;
zk.multi(Arrays.asList(
Op.check(path1, -1),
Op.delete(path2, -1)));
{code}
If path1 or path2 didn't exist, we got an exception
{{KeeperException.NoNodeException}} without which of them doesn't exist.
The reason is when we executed {{PrepRequestProccessor#pRequest}} in
{{PrepRequestProccessor#L804}}, it processed
{{KeeperException.NoNodeException}} which contained path info.
However, we generated {{ErrorTxn}} which only contains {{err}} field
represented error code and lost path info. Maybe a reasonable resolution is
extend {{ErrorTxn}} to contain path info or a general {{data}} byte array.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ZOOKEEPER-3289) Throw KeeperException with path in DataTree operations
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16777699#comment-16777699
]
TisonKun commented on ZOOKEEPER-3289:
-
Anyway, under this JIRA discussion, we can always throw KeeperException with
path in DataTree operations. But I don't think it helps anything. Because all
failed actions will have {{Opcode.error}} and actually doesn't run into our
{{createNode}} / {{deleteNode}} etc. methods. Moreover, we cache node path in
{{rc.path}}.
> Throw KeeperException with path in DataTree operations
> --
>
> Key: ZOOKEEPER-3289
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3289
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
>Affects Versions: 3.5.4, 3.4.13
>Reporter: TisonKun
>Priority: Major
> Fix For: 3.5.5, 3.4.14
>
>
> Currently, if ZooKeeper delete a znode that does not exist. It throws a
> {{KeeperException.NoNodeException}} without path message. It causes
> difficulty when user debug with ZooKeeper. For example,
> Assume we try to do a transaction(with Curator encapsulation)
> {code:java}
> client.inTransaction()
>.check().forPath(path1).and()
>.delete().forPath(path2).and()
>.commit()
> {code}
> if the statement throw an exception {{KeeperException.NoNodeException}}
> without path information, we can hardly know that it failed at {{check}} or
> {{delete}}.
> Thus I propose throws KeeperException with path in DataTree operations. We
> can achieve this without burden.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ZOOKEEPER-3289) Throw KeeperException with path in DataTree operations
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16777681#comment-16777681
]
TisonKun commented on ZOOKEEPER-3289:
-
After digging our codes, I think the root of this issue isn't code snippet
above. Since we update {{DataTree}} after the request succeeded.
Assume we execute the follow statements
{code:java}
ZooKeeper zk = ...;
zk.multi(Arrays.asList(
Op.check(path1, -1),
Op.delete(path2, -1)));
{code}
If path1 or path2 didn't exist, when we executed
{{PrepRequestProccessor#pRequest}} in {{PrepRequestProccessor#L804}}, it
processed {{KeeperException.NoNodeException}} which contained path info.
However, we generated {{ErrorTxn}} which only contains {{err}} field
represented error code. Maybe a reasonable resolution is extend {{ErrorTxn}} to
contain path info or a general {{data}} byte array.
> Throw KeeperException with path in DataTree operations
> --
>
> Key: ZOOKEEPER-3289
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3289
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
>Affects Versions: 3.5.4, 3.4.13
>Reporter: TisonKun
>Priority: Major
> Fix For: 3.5.5, 3.4.14
>
>
> Currently, if ZooKeeper delete a znode that does not exist. It throws a
> {{KeeperException.NoNodeException}} without path message. It causes
> difficulty when user debug with ZooKeeper. For example,
> Assume we try to do a transaction(with Curator encapsulation)
> {code:java}
> client.inTransaction()
>.check().forPath(path1).and()
>.delete().forPath(path2).and()
>.commit()
> {code}
> if the statement throw an exception {{KeeperException.NoNodeException}}
> without path information, we can hardly know that it failed at {{check}} or
> {{delete}}.
> Thus I propose throws KeeperException with path in DataTree operations. We
> can achieve this without burden.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (ZOOKEEPER-3289) Throw KeeperException with path in DataTree operations
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
TisonKun updated ZOOKEEPER-3289:
Comment: was deleted
(was: I'd like to file a pr about pass path info if meaningful when
{{KeeperException}}s thrown in {{DataTree}}.
Maybe in recent days. I'll appreciate it if you or others can review it :))
> Throw KeeperException with path in DataTree operations
> --
>
> Key: ZOOKEEPER-3289
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3289
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
>Affects Versions: 3.5.4, 3.4.13
>Reporter: TisonKun
>Priority: Major
> Fix For: 3.5.5, 3.4.14
>
>
> Currently, if ZooKeeper delete a znode that does not exist. It throws a
> {{KeeperException.NoNodeException}} without path message. It causes
> difficulty when user debug with ZooKeeper. For example,
> Assume we try to do a transaction(with Curator encapsulation)
> {code:java}
> client.inTransaction()
>.check().forPath(path1).and()
>.delete().forPath(path2).and()
>.commit()
> {code}
> if the statement throw an exception {{KeeperException.NoNodeException}}
> without path information, we can hardly know that it failed at {{check}} or
> {{delete}}.
> Thus I propose throws KeeperException with path in DataTree operations. We
> can achieve this without burden.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (ZOOKEEPER-3289) Throw KeeperException with path in DataTree operations
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16777574#comment-16777574
]
TisonKun edited comment on ZOOKEEPER-3289 at 2/26/19 4:40 AM:
--
I'd like to file a pr about pass path info if meaningful when
{{KeeperException}} s threw in {{DataTree}}.
Maybe in recent days. I'll appreciate it if you or others can review it :-)
was (Author: tison):
I'd like to file a pr about pass path info if meaningful when
{{KeeperException}}s threw in {{DataTree}}.
Maybe in recent days. I'll appreciate it if you or others can review it :-)
> Throw KeeperException with path in DataTree operations
> --
>
> Key: ZOOKEEPER-3289
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3289
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
>Affects Versions: 3.5.4, 3.4.13
>Reporter: TisonKun
>Priority: Major
> Fix For: 3.5.5, 3.4.14
>
>
> Currently, if ZooKeeper delete a znode that does not exist. It throws a
> {{KeeperException.NoNodeException}} without path message. It causes
> difficulty when user debug with ZooKeeper. For example,
> Assume we try to do a transaction(with Curator encapsulation)
> {code:java}
> client.inTransaction()
>.check().forPath(path1).and()
>.delete().forPath(path2).and()
>.commit()
> {code}
> if the statement throw an exception {{KeeperException.NoNodeException}}
> without path information, we can hardly know that it failed at {{check}} or
> {{delete}}.
> Thus I propose throws KeeperException with path in DataTree operations. We
> can achieve this without burden.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (ZOOKEEPER-3289) Throw KeeperException with path in DataTree operations
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16777574#comment-16777574
]
TisonKun edited comment on ZOOKEEPER-3289 at 2/26/19 4:41 AM:
--
I'd like to file a pr about pass path info if meaningful when
{{KeeperException}}s thrown in {{DataTree}}.
Maybe in recent days. I'll appreciate it if you or others can review it :)
was (Author: tison):
I'd like to file a pr about pass path info if meaningful when
{{KeeperException}} s threw in {{DataTree}}.
Maybe in recent days. I'll appreciate it if you or others can review it :-)
> Throw KeeperException with path in DataTree operations
> --
>
> Key: ZOOKEEPER-3289
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3289
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
>Affects Versions: 3.5.4, 3.4.13
>Reporter: TisonKun
>Priority: Major
> Fix For: 3.5.5, 3.4.14
>
>
> Currently, if ZooKeeper delete a znode that does not exist. It throws a
> {{KeeperException.NoNodeException}} without path message. It causes
> difficulty when user debug with ZooKeeper. For example,
> Assume we try to do a transaction(with Curator encapsulation)
> {code:java}
> client.inTransaction()
>.check().forPath(path1).and()
>.delete().forPath(path2).and()
>.commit()
> {code}
> if the statement throw an exception {{KeeperException.NoNodeException}}
> without path information, we can hardly know that it failed at {{check}} or
> {{delete}}.
> Thus I propose throws KeeperException with path in DataTree operations. We
> can achieve this without burden.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ZOOKEEPER-3289) Throw KeeperException with path in DataTree operations
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16777574#comment-16777574
]
TisonKun commented on ZOOKEEPER-3289:
-
I'd like to file a pr about pass path info if meaningful when
{{KeeperException}}s threw in {{DataTree}}.
Maybe in recent days. I'll appreciate it if you or others can review it :-)
> Throw KeeperException with path in DataTree operations
> --
>
> Key: ZOOKEEPER-3289
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3289
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
>Affects Versions: 3.5.4, 3.4.13
>Reporter: TisonKun
>Priority: Major
> Fix For: 3.5.5, 3.4.14
>
>
> Currently, if ZooKeeper delete a znode that does not exist. It throws a
> {{KeeperException.NoNodeException}} without path message. It causes
> difficulty when user debug with ZooKeeper. For example,
> Assume we try to do a transaction(with Curator encapsulation)
> {code:java}
> client.inTransaction()
>.check().forPath(path1).and()
>.delete().forPath(path2).and()
>.commit()
> {code}
> if the statement throw an exception {{KeeperException.NoNodeException}}
> without path information, we can hardly know that it failed at {{check}} or
> {{delete}}.
> Thus I propose throws KeeperException with path in DataTree operations. We
> can achieve this without burden.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ZOOKEEPER-3289) Throw KeeperException with path in DataTree operations
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16777555#comment-16777555
]
TisonKun commented on ZOOKEEPER-3289:
-
I try directly {{zk.delete(...)}} and {{curator.delete().forPath(..)}}. Both of
them can throw exception with path info. But when in transaction, we lost the
info. Since Curator just re-throw the exception threw from ZooKeeper, I think
it might be an issue about {{zk.multi}}.
> Throw KeeperException with path in DataTree operations
> --
>
> Key: ZOOKEEPER-3289
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3289
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
>Affects Versions: 3.5.4, 3.4.13
>Reporter: TisonKun
>Priority: Major
> Fix For: 3.5.5, 3.4.14
>
>
> Currently, if ZooKeeper delete a znode that does not exist. It throws a
> {{KeeperException.NoNodeException}} without path message. It causes
> difficulty when user debug with ZooKeeper. For example,
> Assume we try to do a transaction(with Curator encapsulation)
> {code:java}
> client.inTransaction()
>.check().forPath(path1).and()
>.delete().forPath(path2).and()
>.commit()
> {code}
> if the statement throw an exception {{KeeperException.NoNodeException}}
> without path information, we can hardly know that it failed at {{check}} or
> {{delete}}.
> Thus I propose throws KeeperException with path in DataTree operations. We
> can achieve this without burden.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ZOOKEEPER-3289) Throw KeeperException with path in DataTree operations
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16777548#comment-16777548
]
TisonKun commented on ZOOKEEPER-3289:
-
hmmm...I don't think so. Let me take a snippet from
{{DataTree#deleteNode(...)}}.
{code:java}
DataNode parent = nodes.get(parentName);
if (parent == null) {
throw new KeeperException.NoNodeException();
}
//...
DataNode node = nodes.get(path);
if (node == null) {
throw new KeeperException.NoNodeException();
}
{code}
at this point we throw {{KeeperException.NoNodeException}} without path
information. Curator simply re-throws the exception.
Could we, as an improvement, throw {{new
KeeperException.NoNodeException(parentName)}} and {{new
KeeperException.NoNodeException(path)}} here?
> Throw KeeperException with path in DataTree operations
> --
>
> Key: ZOOKEEPER-3289
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3289
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
>Affects Versions: 3.5.4, 3.4.13
>Reporter: TisonKun
>Priority: Major
> Fix For: 3.5.5, 3.4.14
>
>
> Currently, if ZooKeeper delete a znode that does not exist. It throws a
> {{KeeperException.NoNodeException}} without path message. It causes
> difficulty when user debug with ZooKeeper. For example,
> Assume we try to do a transaction(with Curator encapsulation)
> {code:java}
> client.inTransaction()
>.check().forPath(path1).and()
>.delete().forPath(path2).and()
>.commit()
> {code}
> if the statement throw an exception {{KeeperException.NoNodeException}}
> without path information, we can hardly know that it failed at {{check}} or
> {{delete}}.
> Thus I propose throws KeeperException with path in DataTree operations. We
> can achieve this without burden.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ZOOKEEPER-3289) Throw KeeperException with path in DataTree operations
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16777500#comment-16777500
]
TisonKun commented on ZOOKEEPER-3289:
-
{code:none}
for the snippet you provided, it will not throw an exception
KeeperException.NoNodeException:/path1
or KeeperException.NoNodeException:/path2 ???
{code}
If {{path1}} or {{path2}} deleted or not created before, it should throw a
{{KeeperException.NoNodeException}}. My concern is, such an exception should
contain which path cause NoNodeException.
> Throw KeeperException with path in DataTree operations
> --
>
> Key: ZOOKEEPER-3289
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3289
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
>Affects Versions: 3.5.4, 3.4.13
>Reporter: TisonKun
>Priority: Major
> Fix For: 3.5.5, 3.4.14
>
>
> Currently, if ZooKeeper delete a znode that does not exist. It throws a
> {{KeeperException.NoNodeException}} without path message. It causes
> difficulty when user debug with ZooKeeper. For example,
> Assume we try to do a transaction(with Curator encapsulation)
> {code:java}
> client.inTransaction()
>.check().forPath(path1).and()
>.delete().forPath(path2).and()
>.commit()
> {code}
> if the statement throw an exception {{KeeperException.NoNodeException}}
> without path information, we can hardly know that it failed at {{check}} or
> {{delete}}.
> Thus I propose throws KeeperException with path in DataTree operations. We
> can achieve this without burden.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ZOOKEEPER-3289) Throw KeeperException with path in DataTree operations
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16776527#comment-16776527
]
TisonKun commented on ZOOKEEPER-3289:
-
If we can reach a consensus, I volunteer to implement it.
> Throw KeeperException with path in DataTree operations
> --
>
> Key: ZOOKEEPER-3289
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3289
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
>Affects Versions: 3.5.4, 3.4.13
>Reporter: TisonKun
>Priority: Major
> Fix For: 3.5.5, 3.4.14
>
>
> Currently, if ZooKeeper delete a znode that does not exist. It throws a
> {{KeeperException.NoNodeException}} without path message. It causes
> difficulty when user debug with ZooKeeper. For example,
> Assume we try to do a transaction(with Curator encapsulation)
> {code:java}
> client.inTransaction()
>.check().forPath(path1).and()
>.delete().forPath(path2).and()
>.commit()
> {code}
> if the statement throw an exception {{KeeperException.NoNodeException}}
> without path information, we can hardly know that it failed at {{check}} or
> {{delete}}.
> Thus I propose throws KeeperException with path in DataTree operations. We
> can achieve this without burden.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (ZOOKEEPER-3289) Throw KeeperException with path in DataTree operations
TisonKun created ZOOKEEPER-3289:
---
Summary: Throw KeeperException with path in DataTree operations
Key: ZOOKEEPER-3289
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3289
Project: ZooKeeper
Issue Type: Improvement
Components: server
Affects Versions: 3.4.13, 3.5.4
Reporter: TisonKun
Fix For: 3.5.5, 3.4.14
Currently, if ZooKeeper delete a znode that does not exist. It throws a
{{KeeperException.NoNodeException}} without path message. It causes difficulty
when user debug with ZooKeeper. For example,
Assume we try to do a transaction(with Curator encapsulation)
{code:java}
client.inTransaction()
.check().forPath(path1).and()
.delete().forPath(path2).and()
.commit()
{code}
if the statement throw an exception {{KeeperException.NoNodeException}} without
path information, we can hardly know that it failed at {{check}} or {{delete}}.
Thus I propose throws KeeperException with path in DataTree operations. We can
achieve this without burden.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
