Reliability / HA

Because it uses JMS queues internally and consumes messages transactionally, RSB exhibits a reliable behavior as far as guaranteed job processing and result delivery (up to the HTTP, email or file system interaction) are concerned.

In order to roll-out a highly available deployment, several instances of RSB running in parallel must be deployed. The following must be considered:

• RSB polls email resources: refer to this discussion for more information.

• The REST API supports network level load balancing natively: nothing particular must be done to run RSB behind an HTTP load balancer. The job URIs generated by the REST API are built by using the host name of the incoming request, which guarantees that these URIs are respectful of any network-level indirection mechanism that could exist in front of RSB.

• Each RSB node embeds a JMS provider: if an RSB node is down, all the jobs pending processing or the results pending delivery will not be accessible until the node is restarted. To be truly highly-available, the embedded JMS providers should be replaced with an external highly-available JMS provider to which all RSB nodes would connect. If this is pursued, keep in mind the following drawback (described here): RSB uses the local file system for handling multi-file jobs.