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

Tom White commented on WHIRR-361:
---------------------------------

Thanks for the patch Adrian. ZK starts up correctly (I can use a 4 letter word 
to interrogate both instances in a cluster), and shuts down correctly. The 
integration test is still failing for me however, with the following error 
repeating indefinitely:

{noformat}
2011-08-16 10:21:06,376 WARN  [org.apache.zookeeper.ClientCnxn] 
(main-SendThread(ec2-107-20-63-131.compute-1.amazonaws.com:2181)) Session 0x0 
for server null, unexpected error, closing socket connection and attempting 
reconnect
java.net.ConnectException: Connection refused
        at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
        at 
sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:567)
        at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1078)
{noformat}


> refactor jclouds dependencies
> -----------------------------
>
>                 Key: WHIRR-361
>                 URL: https://issues.apache.org/jira/browse/WHIRR-361
>             Project: Whirr
>          Issue Type: Improvement
>          Components: core
>    Affects Versions: 0.6.0
>            Reporter: Adrian Cole
>            Assignee: Adrian Cole
>            Priority: Blocker
>             Fix For: 0.6.0
>
>         Attachments: ConfigureClusterAction.java, WHIRR-361-fixguava.patch, 
> WHIRR-361.patch, WHIRR-361.patch, WHIRR-361.patch, WHIRR-361.patch, 
> org.apache.whirr.service.hbase.integration.HBase089ServiceTest.txt
>
>   Original Estimate: 0.5h
>  Remaining Estimate: 0.5h
>
> There are a few problems in our maven configuration, and a couple places 
> where we aren't using the best jclouds configuration.
>   * in our pom files, we needlessly declare transitive dependencies modules.  
> this is unnecessary maintenance, as jclouds version/dependency configuration 
> is scoped to whirr core
>   * we've switched to SLF4J, yet haven't configured jclouds to use it
>   * especially considering we are uploading large blobs, we should be using 
> the jclouds EnterpriseConfigurationModule which handles file slicing much 
> more effectively.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to