[jira] [Commented] (ZOOKEEPER-1328) Misplaced assertion for the test case 'FLELostMessageTest' and not identifying misfunctions
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13446604#comment-13446604
]
Rakesh R commented on ZOOKEEPER-1328:
-
Thanks a lot Mahadev. QA Report has been generated, could you please have a
look at the report.
> Misplaced assertion for the test case 'FLELostMessageTest' and not
> identifying misfunctions
> ---
>
> Key: ZOOKEEPER-1328
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1328
> Project: ZooKeeper
> Issue Type: Test
> Components: leaderElection
>Affects Versions: 3.4.0
>Reporter: Rakesh R
>Assignee: Rakesh R
> Fix For: 3.5.0
>
> Attachments: ZOOKEEPER-1328.1.patch, ZOOKEEPER-1328.2.patch,
> ZOOKEEPER-1328.patch
>
>
> Assertion for testLostMessage is kept inside the thread.run() method. Due to
> this the assertion failure will not be reflected in the main testcase.
> I have observed the test case is still passing in case of the assert failure
> or misfunction. Instead, the assertion can be moved to the test case -
> testLostMessage.
> {noformat}
> class LEThread extends Thread {
> public void run(){
> peer.setCurrentVote(v);
> LOG.info("Finished election: " + i + ", " + v.getId());
> Assert.assertTrue("State is not leading.",
> peer.getPeerState() == ServerState.LEADING);
> }
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ZOOKEEPER-1503) remove redundant JAAS configuration code in SaslAuthTest and SaslAuthFailTest
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paolo Calabro updated ZOOKEEPER-1503: - Description: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1120//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html > remove redundant JAAS configuration code in SaslAuthTest and SaslAuthFailTest > - > > Key: ZOOKEEPER-1503 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1503 > Project: ZooKeeper > Issue Type: Improvement > Environment: In SaslAuthTest and SaslAuthFail test, we set the JAAS > configuration twice with the same text string. This is confusing and > redundant, since we need only set it once. >Reporter: Eugene Koontz >Assignee: Eugene Koontz > Fix For: 3.4.4, 3.5.0 > > Attachments: ZOOKEEPER-1503.patch > > > https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1120//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ZOOKEEPER-1497) Allow server-side SASL login with JAAS configuration to be programmatically set (rather than only by reading JAAS configuration file)
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paolo Calabro updated ZOOKEEPER-1497:
-
Attachment: guavacourt-hooke1-qrcode-SMALL.png
guavacourt-bonusbag-qrcode-SMALL.png
guavacourt-hooke1-qrcode-SMALL-1.png
guavacourt-bonusbag-qrcode-SMALL-1.png
guavacourt-teaebooks-qrcode-SMALL.png
guavacourt-hooke1-qrcode-SMALL.png
guavacourt-bonusbag-qrcode-SMALL-1.png
guavacourt-btbet-qrcode-SMALL-1.png
guavacourt-btbet-qrcode-SMALL-2.png
guavacourt-hooke1-qrcode-SMALL.png
> Allow server-side SASL login with JAAS configuration to be programmatically
> set (rather than only by reading JAAS configuration file)
> -
>
> Key: ZOOKEEPER-1497
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1497
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
>Affects Versions: 3.4.3, 3.5.0
>Reporter: Matteo Bertozzi
>Assignee: Matteo Bertozzi
> Labels: security
> Fix For: 3.4.4, 3.5.0
>
> Attachments: guavacourt-bonusbag-qrcode-SMALL-1.png,
> guavacourt-bonusbag-qrcode-SMALL-1.png, guavacourt-bonusbag-qrcode-SMALL.png,
> guavacourt-btbet-qrcode-SMALL-1.png, guavacourt-btbet-qrcode-SMALL-2.png,
> guavacourt-hooke1-qrcode-SMALL-1.png, guavacourt-hooke1-qrcode-SMALL.png,
> guavacourt-hooke1-qrcode-SMALL.png, guavacourt-hooke1-qrcode-SMALL.png,
> guavacourt-teaebooks-qrcode-SMALL.png, ZOOKEEPER-1497-v1.patch,
> ZOOKEEPER-1497-v2.patch, ZOOKEEPER-1497-v3.patch, ZOOKEEPER-1497-v4.patch,
> ZOOKEEPER-1497-v5.patch
>
>
> Currently the CnxnFactory checks for "java.security.auth.login.config" to
> decide whether or not enable SASL.
> * zookeeper/server/NIOServerCnxnFactory.java
> * zookeeper/server/NettyServerCnxnFactory.java
> ** configure() checks for "java.security.auth.login.config"
> *** If present start the new Login("Server", SaslServerCallbackHandler(conf))
> But since the SaslServerCallbackHandler does the right thing just checking if
> getAppConfigurationEntry() is empty, we can allow SASL with JAAS
> configuration to be programmatically just checking weather or not a
> configuration entry is present instead of "java.security.auth.login.config".
> (Something quite similar was done for the SaslClient in ZOOKEEPER-1373)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (BOOKKEEPER-325) Delay the replication of a ledger if RW found that its last fragment is in underReplication.
[
https://issues.apache.org/jira/browse/BOOKKEEPER-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13446227#comment-13446227
]
Uma Maheswara Rao G commented on BOOKKEEPER-325:
In this case, we may schedule many timerTasks, if there are many open ledgers
within that grace period right?
I felt that, simple thread would be better for processing them, because there
can be multiple ledgers got added to the pending replications list. I just
borrowed this concept from HDFS pending replication processing :-)
{quote}
check if last ledger fragment is still open (will require a call to checker
again).
{quote}
Yes, I have to check again. this added in my previous
[comment|https://issues.apache.org/jira/browse/BOOKKEEPER-325?focusedCommentId=13444840&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13444840]
as well.
{quote}
If so, then open with fencing.
In all cases, release the lock.
{quote}
I think patch doing the same, it is releasing the lock in all the cases.
If you don't mind, could you please list the comments which are expecting to
change from this patch? :-) ( small confusions for me from above comments)
Thanks a lot,
Uma
> Delay the replication of a ledger if RW found that its last fragment is in
> underReplication.
>
>
> Key: BOOKKEEPER-325
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-325
> Project: Bookkeeper
> Issue Type: Sub-task
> Components: bookkeeper-auto-recovery
>Affects Versions: 4.2.0
>Reporter: Uma Maheswara Rao G
>Assignee: Uma Maheswara Rao G
> Attachments: BOOKKEEPER-325.patch
>
>
> When RW found that ledger's last fragment is in underReplication state, then
> we should delay that ledger replication for some grace period. optimally we
> can replicate other fragments.
> The idea is, Whenever it finds the last fragement is under replicated, It can
> add into PendingReplication list.
> There will be a small daemon, which will check for the timeouts of this
> ledgers.
> Once it timed out , it will trigger the normal replication process if it is
> not in last fragment. Otherwise, it will fence the ledger and will trigger
> the replication nomally.
> see the discussion for more info:
> http://markmail.org/message/ruhhxxgvuqnjlu2s#query:+page:1+mid:f6ifo4sizulwiaem+state:results
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (ZOOKEEPER-1543) Bad sessionId/password combo should return auth failure
Ben Bangert created ZOOKEEPER-1543: -- Summary: Bad sessionId/password combo should return auth failure Key: ZOOKEEPER-1543 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1543 Project: ZooKeeper Issue Type: Improvement Components: server Affects Versions: 3.3.6, 3.4.3, 3.5.0 Environment: All Reporter: Ben Bangert When connecting to a server with a valid session id, but invalid password, Zookeeper disconnects with a SESSION_EXPIRED error. This is blatantly false, its actually the wrong password. Returning a SESSION_EXPIRED in this case is also not documented anywhere. This makes debugging this issue an absolute nightmare, since the server has already lead you down the wrong track (trying to figure out why the session is expired, but it isn't). There's already an AUTH_FAILURE error, why not return that? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: 3.4.4 Release.
Thanks Pat! On Fri, Aug 31, 2012 at 9:59 AM, Patrick Hunt wrote: > On Wed, Aug 29, 2012 at 11:09 PM, Mahadev Konar > wrote: >> Hi folks, >> I took a first pass at the jiras marked for 3.4.4 and cleaned up the >> list. Here is the sanitized list for 3.4.4: >> >> http://s.apache.org/zk_3.4.4_open_jiras >> >> Some of them are Patch Available and some of them are open but have >> patches. I will be reviewing through some of them tonight/tomorrow. >> Committers/others please do chime in. Please do review the list and >> see if we can get these jira's in for 3.4.4 or we need to move them >> out. >> >> >> The big ones in the list are: >> >> https://issues.apache.org/jira/browse/ZOOKEEPER-1437 >> https://issues.apache.org/jira/browse/ZOOKEEPER-1497 (Does this need >> to go into 3.4? ) > > I've committed 1497 for branch34 and trunk. > > Patrick
[jira] [Commented] (BOOKKEEPER-325) Delay the replication of a ledger if RW found that its last fragment is in underReplication.
[
https://issues.apache.org/jira/browse/BOOKKEEPER-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13446132#comment-13446132
]
Uma Maheswara Rao G commented on BOOKKEEPER-325:
{code}
while (workerRunning) {
long ledgerIdToReplicate = getDeferredLedger();
if (ledgerIdToReplicate == -1) {
ledgerIdToReplicate = underreplManager.getLedgerToRereplicate();
}
}{code}
I think here the issue is,
if I have one ledger in under replicated and that last fragment is in open
state, I may add that ledger to differedLedger list with holding the lock
right. But getLedgerToRereplicate is a blocking call right. So, RW loop will
not comeback again until some one releases lock or new underReplicated ledger
added in ZK. That might be one reason for me to push that work to diff thread,
that can check the status.
Am i missed something from your suggestion here?
> Delay the replication of a ledger if RW found that its last fragment is in
> underReplication.
>
>
> Key: BOOKKEEPER-325
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-325
> Project: Bookkeeper
> Issue Type: Sub-task
> Components: bookkeeper-auto-recovery
>Affects Versions: 4.2.0
>Reporter: Uma Maheswara Rao G
>Assignee: Uma Maheswara Rao G
> Attachments: BOOKKEEPER-325.patch
>
>
> When RW found that ledger's last fragment is in underReplication state, then
> we should delay that ledger replication for some grace period. optimally we
> can replicate other fragments.
> The idea is, Whenever it finds the last fragement is under replicated, It can
> add into PendingReplication list.
> There will be a small daemon, which will check for the timeouts of this
> ledgers.
> Once it timed out , it will trigger the normal replication process if it is
> not in last fragment. Otherwise, it will fence the ledger and will trigger
> the replication nomally.
> see the discussion for more info:
> http://markmail.org/message/ruhhxxgvuqnjlu2s#query:+page:1+mid:f6ifo4sizulwiaem+state:results
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: 3.4.4 Release.
On Wed, Aug 29, 2012 at 11:09 PM, Mahadev Konar wrote: > Hi folks, > I took a first pass at the jiras marked for 3.4.4 and cleaned up the > list. Here is the sanitized list for 3.4.4: > > http://s.apache.org/zk_3.4.4_open_jiras > > Some of them are Patch Available and some of them are open but have > patches. I will be reviewing through some of them tonight/tomorrow. > Committers/others please do chime in. Please do review the list and > see if we can get these jira's in for 3.4.4 or we need to move them > out. > > > The big ones in the list are: > > https://issues.apache.org/jira/browse/ZOOKEEPER-1437 > https://issues.apache.org/jira/browse/ZOOKEEPER-1497 (Does this need > to go into 3.4? ) I've committed 1497 for branch34 and trunk. Patrick
Success: ZOOKEEPER-1328 PreCommit Build #1175
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-1328 Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1175/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 261768 lines...] [exec] BUILD SUCCESSFUL [exec] Total time: 0 seconds [exec] [exec] [exec] [exec] [exec] +1 overall. Here are the results of testing the latest attachment [exec] http://issues.apache.org/jira/secure/attachment/12543228/ZOOKEEPER-1328.2.patch [exec] against trunk revision 1379123. [exec] [exec] +1 @author. The patch does not contain any @author tags. [exec] [exec] +1 tests included. The patch appears to include 9 new or modified tests. [exec] [exec] +1 javadoc. The javadoc tool did not generate any warning messages. [exec] [exec] +1 javac. The applied patch does not increase the total number of javac compiler warnings. [exec] [exec] +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings. [exec] [exec] +1 release audit. The applied patch does not increase the total number of release audit warnings. [exec] [exec] +1 core tests. The patch passed core unit tests. [exec] [exec] +1 contrib tests. The patch passed contrib unit tests. [exec] [exec] Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1175//testReport/ [exec] Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1175//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html [exec] Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1175//console [exec] [exec] This message is automatically generated. [exec] [exec] [exec] == [exec] == [exec] Adding comment to Jira. [exec] == [exec] == [exec] [exec] [exec] Comment added. [exec] 9OH7U9KSKs logged out [exec] [exec] [exec] == [exec] == [exec] Finished build. [exec] == [exec] == [exec] [exec] BUILD SUCCESSFUL Total time: 27 minutes 5 seconds Archiving artifacts Recording test results Description set: ZOOKEEPER-1328 Email was triggered for: Success Sending email for trigger: Success ### ## FAILED TESTS (if any) ## All tests passed
[jira] [Commented] (ZOOKEEPER-1328) Misplaced assertion for the test case 'FLELostMessageTest' and not identifying misfunctions
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13446055#comment-13446055
]
Hadoop QA commented on ZOOKEEPER-1328:
--
+1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12543228/ZOOKEEPER-1328.2.patch
against trunk revision 1379123.
+1 @author. The patch does not contain any @author tags.
+1 tests included. The patch appears to include 9 new or modified tests.
+1 javadoc. The javadoc tool did not generate any warning messages.
+1 javac. The applied patch does not increase the total number of javac
compiler warnings.
+1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9)
warnings.
+1 release audit. The applied patch does not increase the total number of
release audit warnings.
+1 core tests. The patch passed core unit tests.
+1 contrib tests. The patch passed contrib unit tests.
Test results:
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1175//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1175//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Console output:
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1175//console
This message is automatically generated.
> Misplaced assertion for the test case 'FLELostMessageTest' and not
> identifying misfunctions
> ---
>
> Key: ZOOKEEPER-1328
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1328
> Project: ZooKeeper
> Issue Type: Test
> Components: leaderElection
>Affects Versions: 3.4.0
>Reporter: Rakesh R
>Assignee: Rakesh R
> Fix For: 3.5.0
>
> Attachments: ZOOKEEPER-1328.1.patch, ZOOKEEPER-1328.2.patch,
> ZOOKEEPER-1328.patch
>
>
> Assertion for testLostMessage is kept inside the thread.run() method. Due to
> this the assertion failure will not be reflected in the main testcase.
> I have observed the test case is still passing in case of the assert failure
> or misfunction. Instead, the assertion can be moved to the test case -
> testLostMessage.
> {noformat}
> class LEThread extends Thread {
> public void run(){
> peer.setCurrentVote(v);
> LOG.info("Finished election: " + i + ", " + v.getId());
> Assert.assertTrue("State is not leading.",
> peer.getPeerState() == ServerState.LEADING);
> }
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ZOOKEEPER-1328) Misplaced assertion for the test case 'FLELostMessageTest' and not identifying misfunctions
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13446038#comment-13446038
]
Mahadev konar commented on ZOOKEEPER-1328:
--
Thanks for fixing that Rakesh. Ill run it through hudson again and will commit
as soon as it +1's.
> Misplaced assertion for the test case 'FLELostMessageTest' and not
> identifying misfunctions
> ---
>
> Key: ZOOKEEPER-1328
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1328
> Project: ZooKeeper
> Issue Type: Test
> Components: leaderElection
>Affects Versions: 3.4.0
>Reporter: Rakesh R
>Assignee: Rakesh R
> Fix For: 3.5.0
>
> Attachments: ZOOKEEPER-1328.1.patch, ZOOKEEPER-1328.2.patch,
> ZOOKEEPER-1328.patch
>
>
> Assertion for testLostMessage is kept inside the thread.run() method. Due to
> this the assertion failure will not be reflected in the main testcase.
> I have observed the test case is still passing in case of the assert failure
> or misfunction. Instead, the assertion can be moved to the test case -
> testLostMessage.
> {noformat}
> class LEThread extends Thread {
> public void run(){
> peer.setCurrentVote(v);
> LOG.info("Finished election: " + i + ", " + v.getId());
> Assert.assertTrue("State is not leading.",
> peer.getPeerState() == ServerState.LEADING);
> }
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ZOOKEEPER-1029) C client bug in zookeeper_init (if bad hostname is given)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13445933#comment-13445933 ] Dheeraj Agrawal commented on ZOOKEEPER-1029: Is it possible to submit a patch for this if it has been fixed? > C client bug in zookeeper_init (if bad hostname is given) > - > > Key: ZOOKEEPER-1029 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1029 > Project: ZooKeeper > Issue Type: Bug > Components: c client >Affects Versions: 3.3.2 >Reporter: Dheeraj Agrawal > > If you give invalid hostname to zookeeper_init method, it's not able to > resolve it, and it tries to do the cleanup (free buffer/completion lists/etc) > . The adaptor_init() is not called for this code path, so the lock,cond > variables (for adaptor, completion lists) are not initialized. > As part of the cleanup it's trying to clean up some buffers and acquires > locks and unlocks (where the locks have not yet been initialized, so > unlocking fails) > lock_completion_list(&zh->sent_requests); - pthread_mutex/cond not > initialized > tmp_list = zh->sent_requests; > zh->sent_requests.head = 0; > zh->sent_requests.last = 0; > unlock_completion_list(&zh->sent_requests); trying to broadcast here > on uninitialized cond > It should do error checking to see if locking succeeds before unlocking it. > If Locking fails, then appropriate error handling has to be done. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ZOOKEEPER-1481) allow the C cli to run exists with a watcher
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13445838#comment-13445838 ] Hudson commented on ZOOKEEPER-1481: --- Integrated in ZooKeeper-trunk #1665 (See [https://builds.apache.org/job/ZooKeeper-trunk/1665/]) ZOOKEEPER-1481 allow the C cli to run exists with a watcher (phunt via michim) (Revision 1379123) Result = SUCCESS michim : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1379123 Files : * /zookeeper/trunk/CHANGES.txt * /zookeeper/trunk/src/c/src/cli.c > allow the C cli to run exists with a watcher > > > Key: ZOOKEEPER-1481 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1481 > Project: ZooKeeper > Issue Type: Improvement > Components: c client >Affects Versions: 3.4.3 >Reporter: Patrick Hunt >Assignee: Patrick Hunt > Fix For: 3.4.4, 3.5.0 > > Attachments: ZOOKEEPER-1481.patch > > > Adds a wexists command and also improves the stdout (type string rather than > just the number). Granted wexists is more for testing purposes than strictly > necessary (we have exists already) but but still worthwhile to add imo. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ZOOKEEPER-1536) c client : memory leak in winport.c
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13445837#comment-13445837 ] Hudson commented on ZOOKEEPER-1536: --- Integrated in ZooKeeper-trunk #1665 (See [https://builds.apache.org/job/ZooKeeper-trunk/1665/]) ZOOKEEPER-1536 c client : memory leak in winport.c (brooklin via michim) (Revision 1379046) Result = SUCCESS michim : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1379046 Files : * /zookeeper/trunk/CHANGES.txt * /zookeeper/trunk/src/c/src/winport.c > c client : memory leak in winport.c > --- > > Key: ZOOKEEPER-1536 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1536 > Project: ZooKeeper > Issue Type: Bug > Components: c client >Affects Versions: 3.4.3 > Environment: windows7 >Reporter: brooklin >Assignee: brooklin > Fix For: 3.4.4, 3.5.0 > > Attachments: winport.c.patch > > > At line 99 in winport.c, use windows API "InitializeCriticalSection" but > never call "DeleteCriticalSection" -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
