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

Diego Ongaro commented on ZOOKEEPER-1105:
-----------------------------------------

I think I've encountered a client-visible manifestation of this issue.

The ZooKeeper FAQ entry [1] titled "Is there an easy way to expire a session 
for testing?" explains that when one client closes a session, all other 
sessions using that same session ID will be expired. This feature appears to 
work with Java clients but not with C clients.

I've attached a C and a Java version of the test case. The basic idea is this:

1) Connect to ZooKeeper.
2) Create a test znode ("/test") if it doesn't exist.
3) Write to the znode.
4) Connect to ZooKeeper with the first connection's session ID and password.
5) Close this new connection.
6) Try to write to the znode again on the first connection.

The write in (6) should never succeed. Using the Java client, the write first 
returns a ConnectionLossException. Retrying it then returns a 
SessionExpiredException, as expected. However, when using the C client, the 
write returns ZOK; this is the wrong behavior.

I've also attached the relevant parts of the server's log file when running 
against both the Java client and the C client. They diverge in the way jiang 
guangran originally reported. The key thing to see in these logs is that, in 
the C client, the session is not terminated cleanly. The client library 
transparently reconnects a new socket using the same session ID, and the server 
accepts the session ID that should have been expired.

Based on this behavior, I think there may be two issues with the C client 
library:
* First, it does not cleanly close its sessions. This prevents C clients from 
forcefully closing each others' sessions.
* Second, it attempts to reconnect over a new socket without returning a 
ZCONNECTIONLOSS to the client. This doesn't matter much to me, but could it 
affect correctness for some applications?

If you need more info or clarification, feel free to ask by commenting on this 
issue. I'm also on IRC as 'ongardie'.

Cheers,
Diego

[1] http://wiki.apache.org/hadoop/ZooKeeper/FAQ#A4
                
> c client zookeeper_close not send CLOSE_OP request to server
> ------------------------------------------------------------
>
>                 Key: ZOOKEEPER-1105
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1105
>             Project: ZooKeeper
>          Issue Type: Bug
>          Components: c client
>    Affects Versions: 3.3.2
>            Reporter: jiang guangran
>         Attachments: zklog.txt, zktest.c, zktest.java
>
>
> in zookeeper_close function,  do adaptor_finish before send CLOSE_OP request 
> to server
> so the CLOSE_OP request can not be sent to server
> in server zookeeper.log have many
> 2011-06-22 00:23:02,323 - WARN  
> [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@634] - 
> EndOfStreamException: Unable to read additional data from client sessionid 
> 0x1305970d66d2224, likely client has closed socket
> 2011-06-22 00:23:02,324 - INFO  
> [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@1435] - Closed 
> socket connection for client /10.250.8.123:60257 which had sessionid 
> 0x1305970d66d2224
> 2011-06-22 00:23:02,325 - ERROR [CommitProcessor:1:NIOServerCnxn@445] - 
> Unexpected Exception:
> java.nio.channels.CancelledKeyException
>         at sun.nio.ch.SelectionKeyImpl.ensureValid(SelectionKeyImpl.java:55)
>         at sun.nio.ch.SelectionKeyImpl.interestOps(SelectionKeyImpl.java:59)
>         at 
> org.apache.zookeeper.server.NIOServerCnxn.sendBuffer(NIOServerCnxn.java:418)
>         at 
> org.apache.zookeeper.server.NIOServerCnxn.sendResponse(NIOServerCnxn.java:1509)
>         at 
> org.apache.zookeeper.server.FinalRequestProcessor.processRequest(FinalRequestProcessor.java:367)
>         at 
> org.apache.zookeeper.server.quorum.CommitProcessor.run(CommitProcessor.java:73)
> and java client not have this problem

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to