[
https://issues.apache.org/jira/browse/ZOOKEEPER-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Han updated ZOOKEEPER-2636:
-----------------------------------
Description:
C client build is broken after ZOOKEEPER-2628 is merged in. After a little
debug, I find out that the build is broken because the zookeeper.jute.h and
zookeeper.jute.c are not completely generated.
* The culprit is the code change introduced in ZOOKEEPER-2628, where we wraps
{code}JRecord.genCCode{code} with a try / catch / finally block and the file
writers were prematurely closed in finally block which prevents remaining of
the zookeeper.jute.h/c file being generated.
* The fix to {code}JRecord.genCCode{code} in ZOOKEEPER-2628 was made because a
find bug warning was directly associated with the code. Due to the subtlety of
the file writer ownership, we did not capture the issue during code review.
* The build break was not captured in pre-commit builds as well ([an
example|https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/72//console]),
where we get all tests passed including C client tests. I suspect we might
have another bug with cached generated files that should be regenerated but we
don't - need more investigation on this one.
* The fix is simple by revert the change to this specific method. Findbug does
not complain anymore because the previous warning that appertain to this code
block was fixed at the call site of {code}JRecord.genCCode{code}. So by
reverting the change we still have zero find bug warnings.
was:
C client build is broken after ZOOKEEPER-2628 is merged in. After a little
debug, I find out that the build is broken because the zookeeper.jute.h and
zookeeper.jute.c are not completely generated.
* The culprit is the code change introduced in ZOOKEEPER-2628, where we wraps
{code}JRecord.genCCode{code} with a try / catch / finally block and the file
writers were prematurely closed in finally block which prevents remaining of
the zookeeper.jute.h/c file being generated.
* This fix is made because a find bug warning was directly associated with the
code. Due to the subtlety of the file writer ownership, we did not capture the
issue during code review.
* The build break was not captured in pre-commit builds as well ([an
example|https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/72//console]),
where we get all tests passed including C client tests. I suspect we might
have another bug with cached generated files that should be regenerated but we
don't - need more investigation on this one.
* The fix is simple by revert the change to this specific method. Findbug does
not complain anymore because the previous warning that appertain to this code
block was fixed at the call site of {code}JRecord.genCCode{code}. So by
reverting the change we still have zero find bug warnings.
> Fix C build break.
> ------------------
>
> Key: ZOOKEEPER-2636
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2636
> Project: ZooKeeper
> Issue Type: Bug
> Components: jute
> Affects Versions: 3.5.3
> Reporter: Michael Han
> Assignee: Michael Han
> Priority: Blocker
> Fix For: 3.5.3, 3.6.0
>
>
> C client build is broken after ZOOKEEPER-2628 is merged in. After a little
> debug, I find out that the build is broken because the zookeeper.jute.h and
> zookeeper.jute.c are not completely generated.
> * The culprit is the code change introduced in ZOOKEEPER-2628, where we wraps
> {code}JRecord.genCCode{code} with a try / catch / finally block and the file
> writers were prematurely closed in finally block which prevents remaining of
> the zookeeper.jute.h/c file being generated.
> * The fix to {code}JRecord.genCCode{code} in ZOOKEEPER-2628 was made because
> a find bug warning was directly associated with the code. Due to the subtlety
> of the file writer ownership, we did not capture the issue during code
> review.
> * The build break was not captured in pre-commit builds as well ([an
> example|https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/72//console]),
> where we get all tests passed including C client tests. I suspect we might
> have another bug with cached generated files that should be regenerated but
> we don't - need more investigation on this one.
> * The fix is simple by revert the change to this specific method. Findbug
> does not complain anymore because the previous warning that appertain to this
> code block was fixed at the call site of {code}JRecord.genCCode{code}. So by
> reverting the change we still have zero find bug warnings.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
