-
Type:
Bug
-
Status: Resolved
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 0.6.0
-
Fix Version/s: 0.6.0
-
Component/s: None
-
Labels:None
Previously, ComputeCache used a stringified Key to ensure we don't create another ComputeService for the same provider. At some point, Key was modified to use both a string and a commons configuration object. Since commons configuration doesn't implement hashCode in a predictable way, the ComputeCache creates a new ComputeServiceContext each time it is used. Since we don't log or test this, it was easy to miss.
Adding a simple log statement inside ComputeCache shows this:
2011-08-13 12:29:22,532 INFO [org.apache.whirr.service.hbase.integration.HBaseServiceController] (main) Starting up cluster...
2011-08-13 12:29:37,760 INFO [org.apache.whirr.service.ComputeCache] (main) created new ComputeServiceContext [id=aws-ec2, endpoint=https://ec2.us-east-1.amazonaws.com, apiVersion=2010-06-15, identity=067PW7Z9P0FNH7JDPE82, iso3166Codes=[US-VA, US-CA, IE, SG, JP-13]]
2011-08-13 12:29:46,115 INFO [org.apache.whirr.service.ComputeCache] (main) created new ComputeServiceContext [id=aws-ec2, endpoint=https://ec2.us-east-1.amazonaws.com, apiVersion=2010-06-15, identity=067PW7Z9P0FNH7JDPE82, iso3166Codes=[US-VA, US-CA, IE, SG, JP-13]]
2011-08-13 12:29:46,118 INFO [org.apache.whirr.actions.BootstrapClusterAction] (main) Bootstrapping cluster
-snip-
- is blocked by
-
WHIRR-361 refactor jclouds dependencies
-
- Resolved
-