[jira] Updated: (ZOOKEEPER-59) Synchronized block in NIOServerCnxn
[
https://issues.apache.org/jira/browse/ZOOKEEPER-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Flavio Paiva Junqueira updated ZOOKEEPER-59:
Attachment: ZOOKEEPER-59.patch
Synchronized block in NIOServerCnxn
---
Key: ZOOKEEPER-59
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-59
Project: Zookeeper
Issue Type: Bug
Components: server
Reporter: Flavio Paiva Junqueira
Assignee: Flavio Paiva Junqueira
Fix For: 3.3.0
Attachments: ZOOKEEPER-59.patch, ZOOKEEPER-59.patch,
ZOOKEEPER-59.patch
There are two synchronized blocks locking on different objects, and to me
they should be guarded by the same object. Here are the parts of the code I'm
talking about:
{noformat}
nioservercnxn.readrequ...@444
...
synchronized (this) {
outstandingRequests++;
// check throttling
if (zk.getInProcess() factory.outstandingLimit) {
disableRecv();
// following lines should not be needed since we are
already
// reading
// } else {
// enableRecv();
}
}
{noformat}
{noformat}
nioservercnxn.sendrespo...@740
...
synchronized (this.factory) {
outstandingRequests--;
// check throttling
if (zk.getInProcess() factory.outstandingLimit
|| outstandingRequests 1) {
sk.selector().wakeup();
enableRecv();
}
}
{noformat}
I think the second one is correct, and the first synchronized block should be
guarded by this.factory.
This could be related to issue ZOOKEEPER-57, but I have no concrete
indication that this is the case so far.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-59) Synchronized block in NIOServerCnxn
[
https://issues.apache.org/jira/browse/ZOOKEEPER-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Flavio Paiva Junqueira updated ZOOKEEPER-59:
Status: Open (was: Patch Available)
Updating patch according to Ben's comment.
Synchronized block in NIOServerCnxn
---
Key: ZOOKEEPER-59
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-59
Project: Zookeeper
Issue Type: Bug
Components: server
Reporter: Flavio Paiva Junqueira
Assignee: Flavio Paiva Junqueira
Fix For: 3.3.0
Attachments: ZOOKEEPER-59.patch, ZOOKEEPER-59.patch,
ZOOKEEPER-59.patch
There are two synchronized blocks locking on different objects, and to me
they should be guarded by the same object. Here are the parts of the code I'm
talking about:
{noformat}
nioservercnxn.readrequ...@444
...
synchronized (this) {
outstandingRequests++;
// check throttling
if (zk.getInProcess() factory.outstandingLimit) {
disableRecv();
// following lines should not be needed since we are
already
// reading
// } else {
// enableRecv();
}
}
{noformat}
{noformat}
nioservercnxn.sendrespo...@740
...
synchronized (this.factory) {
outstandingRequests--;
// check throttling
if (zk.getInProcess() factory.outstandingLimit
|| outstandingRequests 1) {
sk.selector().wakeup();
enableRecv();
}
}
{noformat}
I think the second one is correct, and the first synchronized block should be
guarded by this.factory.
This could be related to issue ZOOKEEPER-57, but I have no concrete
indication that this is the case so far.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-59) Synchronized block in NIOServerCnxn
[
https://issues.apache.org/jira/browse/ZOOKEEPER-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Flavio Paiva Junqueira updated ZOOKEEPER-59:
Status: Patch Available (was: Open)
Synchronized block in NIOServerCnxn
---
Key: ZOOKEEPER-59
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-59
Project: Zookeeper
Issue Type: Bug
Components: server
Reporter: Flavio Paiva Junqueira
Assignee: Flavio Paiva Junqueira
Fix For: 3.3.0
Attachments: ZOOKEEPER-59.patch, ZOOKEEPER-59.patch,
ZOOKEEPER-59.patch
There are two synchronized blocks locking on different objects, and to me
they should be guarded by the same object. Here are the parts of the code I'm
talking about:
{noformat}
nioservercnxn.readrequ...@444
...
synchronized (this) {
outstandingRequests++;
// check throttling
if (zk.getInProcess() factory.outstandingLimit) {
disableRecv();
// following lines should not be needed since we are
already
// reading
// } else {
// enableRecv();
}
}
{noformat}
{noformat}
nioservercnxn.sendrespo...@740
...
synchronized (this.factory) {
outstandingRequests--;
// check throttling
if (zk.getInProcess() factory.outstandingLimit
|| outstandingRequests 1) {
sk.selector().wakeup();
enableRecv();
}
}
{noformat}
I think the second one is correct, and the first synchronized block should be
guarded by this.factory.
This could be related to issue ZOOKEEPER-57, but I have no concrete
indication that this is the case so far.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-59) Synchronized block in NIOServerCnxn
[
https://issues.apache.org/jira/browse/ZOOKEEPER-59?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12842403#action_12842403
]
Hadoop QA commented on ZOOKEEPER-59:
-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12438130/ZOOKEEPER-59.patch
against trunk revision 919706.
+1 @author. The patch does not contain any @author tags.
-1 tests included. The patch doesn't appear to include any new or modified
tests.
Please justify why no tests are needed for this patch.
+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 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:
http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h8.grid.sp2.yahoo.net/135/testReport/
Findbugs warnings:
http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h8.grid.sp2.yahoo.net/135/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Console output:
http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h8.grid.sp2.yahoo.net/135/console
This message is automatically generated.
Synchronized block in NIOServerCnxn
---
Key: ZOOKEEPER-59
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-59
Project: Zookeeper
Issue Type: Bug
Components: server
Reporter: Flavio Paiva Junqueira
Assignee: Flavio Paiva Junqueira
Fix For: 3.3.0
Attachments: ZOOKEEPER-59.patch, ZOOKEEPER-59.patch,
ZOOKEEPER-59.patch
There are two synchronized blocks locking on different objects, and to me
they should be guarded by the same object. Here are the parts of the code I'm
talking about:
{noformat}
nioservercnxn.readrequ...@444
...
synchronized (this) {
outstandingRequests++;
// check throttling
if (zk.getInProcess() factory.outstandingLimit) {
disableRecv();
// following lines should not be needed since we are
already
// reading
// } else {
// enableRecv();
}
}
{noformat}
{noformat}
nioservercnxn.sendrespo...@740
...
synchronized (this.factory) {
outstandingRequests--;
// check throttling
if (zk.getInProcess() factory.outstandingLimit
|| outstandingRequests 1) {
sk.selector().wakeup();
enableRecv();
}
}
{noformat}
I think the second one is correct, and the first synchronized block should be
guarded by this.factory.
This could be related to issue ZOOKEEPER-57, but I have no concrete
indication that this is the case so far.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-660) Clean up scripts need to change to clean up transaction logs only for a max timeout period.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-660: Fix Version/s: (was: 3.3.0) 3.4.0 moving it to 3.4 since it is not a blocker and is only important with ZOOKEEPER-22. Clean up scripts need to change to clean up transaction logs only for a max timeout period. --- Key: ZOOKEEPER-660 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-660 Project: Zookeeper Issue Type: Task Components: scripts Reporter: Mahadev konar Assignee: Mahadev konar Fix For: 3.4.0 As a part of ZOOKEEPER-22, the cleanup scripts will have to change to only clean up transaction logs within a max timeout period of the last transaction. This is necessary to replay any client reconnection requests that the servers will get. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-657) Cut down the running time of ZKDatabase corruption.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-657: Fix Version/s: (was: 3.3.0) 3.4.0 moving it to 3.4 since its not a blocker. Cut down the running time of ZKDatabase corruption. --- Key: ZOOKEEPER-657 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-657 Project: Zookeeper Issue Type: Improvement Reporter: Mahadev konar Assignee: Mahadev konar Fix For: 3.4.0 THe zkdatabasecorruption test takes around 180 seconds right now. It just bring down a quorum cluster up and down and corrupts some snapshots. We need to investigate why it takes that long and make it shorter so that our test run times are smaller. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-605) remove datatreebuilder classes from the codebase.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-605: Fix Version/s: (was: 3.3.0) 3.4.0 moving this to 3.4 since its not a blocker. remove datatreebuilder classes from the codebase. - Key: ZOOKEEPER-605 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-605 Project: Zookeeper Issue Type: Improvement Reporter: Mahadev konar Assignee: Mahadev konar Fix For: 3.4.0 the current trunk has datatreebuilder classes which adds an unnecessary layer of abastraction without any need for it. It just causes confusion and unreadable code. We should get rid of these classes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-310) Coverity report on issues in C client code
[
https://issues.apache.org/jira/browse/ZOOKEEPER-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mahadev konar updated ZOOKEEPER-310:
Fix Version/s: (was: 3.3.0)
3.4.0
moving this to 3.4 since its not a blocker
Coverity report on issues in C client code
--
Key: ZOOKEEPER-310
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-310
Project: Zookeeper
Issue Type: Bug
Components: c client
Affects Versions: 3.1.0
Reporter: Patrick Hunt
Assignee: Mahadev konar
Priority: Minor
Fix For: 3.4.0
Coverity found the following issues in the c code thatwe should look
at/resolve:
1) zookeeper.c
Event unterminated_case: This case (value 0) is not terminated by a 'break'
statement.
717 case 0:
718 errno = EHOSTDOWN;
Event fallthrough: The above case falls through to this one.
719 case -1:
Event unterminated_case: This case (value 0) is not terminated by a 'break'
statement.
739 case 0:
740 errno = EHOSTDOWN;
Event fallthrough: The above case falls through to this one.
741 case -1:
Event negative_return_fn: Called negative-returning function socket(2, 1, 0)
Event var_assign: NEGATIVE return value of socket assigned to signed
variable zh-fd
1099 zh-fd = socket(PF_INET, SOCK_STREAM, 0);
Event negative_returns: Tracked variable zh-fd was passed to a negative
sink.
1100 setsockopt(zh-fd, IPPROTO_TCP, TCP_NODELAY, on,
sizeof(int));
Event deref_ptr: Directly dereferenced pointer cptr-buffer
1308 cptr-buffer-curr_offset = get_buffer_len(oa);
Event check_after_deref: Pointer cptr-buffer dereferenced before NULL check
1309 if (!cptr-buffer) {
cli.c
Event returned_null: Function strchr returned NULL value (checked 4 out of
5 times)
Event var_assigned: Variable ptr assigned to NULL return value from strchr
532 char *ptr = strchr(buffer, '\n');
Event dereference: Dereferencing NULL value ptr
recordio.c
Event alloc_fn: Called allocation function malloc
Event var_assign: Assigned variable buff to storage returned from
malloc(12U)
284 struct buff_struct *buff = malloc(sizeof(struct buff_struct));
Event leaked_storage: Variable buff goes out of scope
At conditional (1): !(ia != NULL) taking true path
285 if (!ia) return 0;
Event alloc_fn: Called allocation function malloc
Event var_assign: Assigned variable buff to storage returned from
malloc(12U)
301 struct buff_struct *buff = malloc(sizeof(struct buff_struct));
Event leaked_storage: Variable buff goes out of scope
At conditional (1): !(oa != NULL) taking true path
302 if (!oa) return 0;
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (ZOOKEEPER-321) optmize session tracking in zookeeper.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar resolved ZOOKEEPER-321. - Resolution: Won't Fix resolving this as wont fix! optmize session tracking in zookeeper. -- Key: ZOOKEEPER-321 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-321 Project: Zookeeper Issue Type: New Feature Components: c client, java client, server Reporter: Mahadev konar Assignee: Mahadev konar Fix For: 3.3.0 sometimes a lot of zookeeper clients are read only. For such clients we do not need the session tracking in zookeeper. Getting rid of session tracking for such clients will help us sclae much better. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-207) All the threads should have names so that its easier to see throguh a stack trace.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-207: Fix Version/s: (was: 3.3.0) 3.4.0 moving this to 3.4 since its not a blocker. All the threads should have names so that its easier to see throguh a stack trace. -- Key: ZOOKEEPER-207 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-207 Project: Zookeeper Issue Type: Improvement Components: server Affects Versions: 3.0.0 Reporter: Mahadev konar Assignee: Mahadev konar Priority: Minor Fix For: 3.4.0 the threads should have names so that its easier to look through the stack trace. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
