[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13483725#comment-13483725
 ] 

Patrick Hunt commented on ZOOKEEPER-1560:
-----------------------------------------

bq. PDH: similar to what it was before - write as much as possible and then use 
the selector to wait for the socket to become writeable again

bq. Ted: I looked at svn log for ClientCnxnSocketNIO.java back to 2011-04-12 
and didn't seem to find the above change. FYI

Hi Ted, the following is what I was referring to. This is from latest on 
branch-3.3, 3.4.4 has a similar (although broken) block where it's a bit less 
obvious what's happening. branch-3.3 is more clear.

Notice that we first attempt to write, if !remaining them we remove from the 
queue, otw we'll wait till the next time the selector wakes us up (the final 
isempty check is pretty criticial here as well to set interest correctly) and 
retry until the buffer is drained.

{noformat}
            if (sockKey.isWritable()) {
                synchronized (outgoingQueue) {
                    if (!outgoingQueue.isEmpty()) {
                        ByteBuffer pbb = outgoingQueue.getFirst().bb;
                        sock.write(pbb);
                        if (!pbb.hasRemaining()) {
                            sentCount++;
                            Packet p = outgoingQueue.removeFirst();
                            if (p.header != null
                                    && p.header.getType() != OpCode.ping
                                    && p.header.getType() != OpCode.auth) {
                                pendingQueue.add(p);
                            }
                        }
                    }
                }
            }
            if (outgoingQueue.isEmpty()) {
                disableWrite();
            } else {
                enableWrite();
            }
{noformat}

                
> Zookeeper client hangs on creation of large nodes
> -------------------------------------------------
>
>                 Key: ZOOKEEPER-1560
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1560
>             Project: ZooKeeper
>          Issue Type: Bug
>          Components: java client
>    Affects Versions: 3.4.4, 3.5.0
>            Reporter: Igor Motov
>            Assignee: Ted Yu
>             Fix For: 3.5.0, 3.4.5
>
>         Attachments: ZOOKEEPER-1560.patch, zookeeper-1560-v1.txt, 
> zookeeper-1560-v2.txt, zookeeper-1560-v3.txt, zookeeper-1560-v4.txt, 
> zookeeper-1560-v5.txt, zookeeper-1560-v6.txt, zookeeper-1560-v7.txt
>
>
> To reproduce, try creating a node with 0.5M of data using java client. The 
> test will hang waiting for a response from the server. See the attached patch 
> for the test that reproduces the issue.
> It seems that ZOOKEEPER-1437 introduced a few issues to 
> {{ClientCnxnSocketNIO.doIO}} that prevent {{ClientCnxnSocketNIO}} from 
> sending large packets that require several invocations of 
> {{SocketChannel.write}} to complete. The first issue is that the call to 
> {{outgoingQueue.removeFirstOccurrence(p);}} removes the packet from the queue 
> even if the packet wasn't completely sent yet.  It looks to me that this call 
> should be moved under {{if (!pbb.hasRemaining())}} The second issue is that 
> {{p.createBB()}} is reinitializing {{ByteBuffer}} on every iteration, which 
> confuses {{SocketChannel.write}}. And the third issue is caused by extra 
> calls to {{cnxn.getXid()}} that increment xid on every iteration and confuse 
> the server.

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

Reply via email to