[ https://issues.apache.org/jira/browse/ZOOKEEPER-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608988#action_12608988 ]
fpj edited comment on ZOOKEEPER-45 at 6/28/08 2:10 AM: -------------------------------------------------------------------------- It's not clear to me whether this patch works fine. The problem that I see is that under solaris the predicate: ((k.readyOps() & SelectionKey.OP_CONNECT) != 0) will never be true, which means that we don't make the calls inside the if block. Now, you have added a line to change state to CONNECTED to the end of primeConnection, which is called in two places: startConnect() and run(). The one in startConnect is predicated by sock.connect(addr). As the channel is in non-blocking mode, the behavior of SocketChannel.connect() says that it may return false if connection is in progress. The call or run() may never happen either because of the problem Pat pointed out. The bottom line is that we again may never reach a connected state. I wonder what is wrong with changing the predicate of the "if" block on run() to test also if state is not connected and sock is ready to read. was (Author: fpj): It's not clear to me weather this patch works fine. The problem that I see is that under solaris the predicate: ((k.readyOps() & SelectionKey.OP_CONNECT) != 0) will never be true, which means that we don't make the calls inside the if block. Now, you have added a line to change state to CONNECTED to the end of primeConnection, which is called in two places: startConnect() and run(). The one in startConnect is predicated by sock.connect(addr). As the channel is in non-blocking mode, the behavior of SocketChannel.connect() says that it may return false if connection is in progress. The call or run() may never happen either because of the problem Pat pointed out. The bottom line is that we again may never reach a connected state. I wonder what is wrong with changing the predicate of the "if" block on run() to test also if state is not connected and sock is ready to read. > Restructure the SVN repository after initial import > --------------------------------------------------- > > Key: ZOOKEEPER-45 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-45 > Project: Zookeeper > Issue Type: Task > Components: build > Reporter: Patrick Hunt > Assignee: Patrick Hunt > Fix For: 3.0.0 > > Attachments: add_timestamp_log4j.patch, build_fixlog4j.patch, > fix_solaris_tests.patch > > > SVN and the ant build have to be updated after the initial import from > SourceForge (see INFRA-1644) in order to get us aligned with Apache release > process/collateral and some general cleanup of the repository. Please > review/comment on the following: > I intend to follow these steps: > 1) collapse svn hadoop/zookeeper/trunk/zookeeper/... down to > hadoop/zookeeper/trunk/... (remove unnecessary zk dir under trunk) > 2) change the java package prefix from com.yahoo to org.apache > 3) update the license headers in all source files > 4) replace LICENSE file in root dir with Apache LICENSE file > 5) add attribution NOTICE file to root dir > 6) update the README file appropriately > 7) create a new "src" directory in the zk root > 8) move root "c" directory into src > 9) move root "java" directory into src > 10) create root "docs" directory > 11) create src/docs directory > 12) rename src/java/src to src/java/main > 13) move root "test" directory to src/java/test > 14) build.xml will be updated appropriately for all the moves. it will also > be updated with apache specific targets similar to what exists in hadoop > (such as building the forrest documentation). > steps 10&11 are required for zk documentation storage. src/docs is the > location of all documentation in "forrest xml" format - the documentation > source/originals (what you edit when you change the docs). the ant script is > setup to build docs (forrest) into the root docs directory. these files are > also committed to svn (both docs and src/docs). later, during a release > process, the files in the root docs directory are checked out onto the system > hosting the apache web site and pushed to the mirrors. > I'll submit patches for any changes/additions of files. However I suspect > that the directory move operations in SVN will not have an accompanying patch > - this "script" is the documentation of what will be changed (comments added > for any deviation). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.