Proxy

The Proxy classes are intended to abstract the Redis communication into types of actors who perform specific actions. The types of actors are dispatchers, requestors, and backgrounders and are defined as follows

• Dispatcher - A dispatcher is the object executing inside the Runner thread(s) whose responsibilities include
  • Maintaining the connection to the WAMP router using the Wamp::Client which executes on an Event Machine Loop
  • Dispatching WAMP "requests" and "events" to the appropriate handlers
  • Pushing background handler jobs to backgrounders
  • Receiving "call" and "publish" commands from requestors
  • Processing responses from requestor commands
  • Processing responses from backgrounder handlers
• Requestor - A requestor is any object executing outside of the Runner that is making a "call" or "publish" request
• Backgrounder - A backgrounder is a handler that has been pushed to Sidekiq for processing

The proxies use a custom Queue class that provides push/pop operations using Redis.

The following workflows are defined between the different proxies.

Command/Response Workflow

This workflow is used by a requestor to make a "call" or "publish" request to the dispatcher. The flow is as follows

• requestor performs a "push" operation with the following parameters
  • queue_name - The "command queue"
  • command - The command ("call" or "publish")
  • params - The parameters for the command (args/kwargs/etc.)
  • handle - A unique "response queue" name that the dispatcher will provide the response on
• requestor blocks (with timeout) awaiting the response
• meanwhile
  • dispatcher performs a "pop" operation and executes the command
  • dispatcher "pushes" the response to the "handle" queue
• requestor "pops" the response and deletes the temporary "handle" queue

Note that if the request times out, a RuntimeError is triggered signaling whether the timeout was because the response didn't return OR the worker is not running.

Dispatcher/Backgrounder Workflow

This workflow is used by a dispatcher to execute a "topic" or "procedure" handler on a background thread. This is used by a "BackgroundHandler" to push a handler to Sidekiq and get the response from the background job.
This frees up the Event Machine to process other incoming requests. The flow is as follows

• dispatcher pushes the task to the background sidekiq worker providing the "handle" it will respond on
• backgrounder performs the operation
• backgrounder performs a "push" with response back to the dispatcher
• dispatcher performs a "pop" and sends the response (if it is a call) back to the caller

Requestor/Dispatcher Ticker Workflow

This workflow is used to sense when a worker is no longer running. The flow is as follows

• dispatcher periodically increments the ticker
• requestor does the following when performing a pop
  • stores the value of the ticker
  • blocks waiting for a "pop"
  • if the pop comes back "nil", it means we timed out
    • if the value of the ticker is that same as at the start, then the worker is not running
    • else the response was never returned