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.
