Company and Agency are example applications demonstrating the use of Circuit Breaker Dashboard for Pivotal Cloud Foundry. (For information on the Circuit Breaker Dashboard product, please see the documentation.)
-
Build the two projects from the root (
traveler
) directory. If using Maven, run:$ mvn package
If using Gradle, run
./gradlew build
(OS X, Linux) orgradlew.bat build
(Windows).$ ./gradlew build
-
Run the deployment script (if you used Maven,
scripts/deploy_mvn.sh
orscripts/deploy_mvn.bat
; if you used Gradle,scripts/deploy_gradle.sh
orscripts/deploy_gradle.bat
).$ ./scripts/deploy_gradle.sh
The script will create Circuit Breaker Dashboard and Service Registry service instances and then push the applications and bind them to the appropriate services.
-
When the script has finished, set the
TRUST_CERTS
environment variable to the API endpoint of your Elastic Runtime instance (as inapi.example.com
), then restage the applications so that the changes will take effect. SettingTRUST_CERTS
causes Spring Cloud Services to add the the SSL certificate at the specfied API endpoint to the JVM’s truststore, so that the client application can communicate with a Service Registry service instance even if your Elastic Runtime instance is using a self-signed SSL certificate (see the Service Registry documentation).$ cf set-env company TRUST_CERTS api.wise.com Setting env variable 'TRUST_CERTS' to 'api.wise.com' for app company in org myorg / space development as user... OK TIP: Use 'cf restage' to ensure your env variable changes take effect $ cf restage company
$ cf set-env agency TRUST_CERTS api.wise.com Setting env variable 'TRUST_CERTS' to 'api.wise.com' for app agency in org myorg / space development as user... OK TIP: Use 'cf restage' to ensure your env variable changes take effect $ cf restage agency
NoteBy default, the Spring Cloud Services Starters for Service Registry causes all application endpoints to be secured by HTTP Basic authentication. For more information or if you wish to disable this, see the documentation. (HTTP Basic authentication is disabled in these sample applications.)
-
Visit
[ROUTE]
, where[ROUTE]
is the route bound to the Agency application. In the Agency application, thegetGuide()
method on theTravelAgent
class will use the Service Registry to look up the Company application and get a guide name, which will be randomly selected from a pool of three.You can simulate load on the Agency application by using
curl
.$ while true; do curl http://agency.wise.com; done
-
To see the circuit breaker in action, stop the Company application. (You can do this either from Pivotal Cloud Foundry Apps Manager or using the cf Command Line Interface tool.)
$ cf stop company Stopping app company in org myorg / space development as user... OK
The Agency application’s calls to the Company application will begin failing. Once the failure rate reaches a threshold, the Circuit Breaker Dashboard will trip the
getGuide()
breaker. The calls will fall back to the Agency application’s owngetBackupGuide()
method and return a static backup guide name while the circuit is open. -
Check the dashboard to see the breaker status. Alongside the graph, the dashboard shows the status of calls made to
getGuide()
in the last 10 seconds. Call counts are color-coded. -
Start the Company application again (using either Apps Manager or the cf CLI).
$ cf start company Starting app company in org myorg / space development as user... 0 of 1 instances running, 1 starting 0 of 1 instances running, 1 starting 1 of 1 instances running App started
After the Company application has started and re-registered with the Service Registry instance and after the registration has trickled down to the Agency application, the Circuit Breaker Dashboard will close the
getGuide()
circuit.You should again see calls to the Company application going through.
For more information about the Circuit Breaker Dashboard and its use in a client application, see the Circuit Breaker Dashboard documentation.