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

Reply via email to