[jira] [Updated] (ZOOKEEPER-2636) Fix C build break.

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

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