Code Concurrency and Two Easy Fixes

Facebook
Twitter
LinkedIn

Code concurrency is a default in any Rails code. A threaded web serverwill simultaneously serve many HTTP requests, and each will hold its controller instance. Threaded active job adapters and action cable channels also handle multiple requests simultaneously. Even when the global process space is shared, work for each instance is managed separately. For scenarios where the shared space is not altered, this process will run smoothly.

Let us see in detail how this is managed in our Rails applications.

  1. Executor: Executors separate the framework and application codes by wrapping the application code.

The wrapping of code was more complex before Rails 5.0. To protect a code, either separate Rack middleware classes were used or direct wrapping was used. With recent updates in Rails, the executor handles the wrapping in a single step that is easier to understand.

Call the executor to wrap the application code as you invoke it.

For example:

Code concurrency Executor example

One attractive feature of the executor is its reentrancy.

Two callbacks of the executor are ‘to run and ‘to complete.’ This enables wrapping code in parts when it is not possible to wrap the code as blocks.

code concurrency fix example

The current thread is moved to the ‘running’ mode, temporarily blocking the thread. So, the thread will not be accessible by any other request that tries to do so.

  1. Reloader: The Reloader functions similarly to the Executor. The code that is to be protected is wrapped before another request is hit. This is used in scenarios where application code is invoked multiple times by any long-running process. Most often, in Rails, the web requests and Active Jobs are by default wrapped. So the Reloader is rarely used.
You might also like:   Services, the Missing Element in Rails Applications: A Discussion with Riaz Virani

A Reloader is employed when there is a need to reload the application. When the requested condition asks for reloading, the Reloader delays the application reload until it is secure. And for scenarios where application reloads are mandated, the Reloader waits until the current block is executed and allows the reload. Thus, the code is protected from errors.

The ‘to_run‘ and ‘to_complete‘ callbacks are used by the Reloader also.

A class unload is involved in the Reloader process. Here, all of the auto-loaded classes are removed and set ready to be further loaded. The application reload is to happen only before or after the class unload, and so, the two additional callbacks of Reloader are ‘before_class_unload‘ and ‘after_class_unload.

Executor and Reloadersare used by the Rails framework components as well. ActionDispatch::Executor and ActionDispatch::Reloader are included in the default application stack. Whenever there is a code change, the Reloader serves a fresh copy of the application for an HTTP request. Active Job feature also utilizes Reloaders, whereas Action Cable uses Executor. Action Cable also uses the before_class_unload of Reloader to disconnect all the connections.

As discussed, code concurrency is handled by default with the threaded active jobs and action cables features of Rails codes. With recent Rails updates, Executors and Reloaders are also added to improve the code concurrency handling.

Want more posts like this?

What you should do now:

Facebook
Twitter
LinkedIn

Easy Application Deployment to AWS

Focus on development, not on managing infrastructure

Deploying, running and managing your Ruby on Rails app is taking away precious resources? Engine Yard takes the operational overhead out of the equation, so you can keep innovating.

  • Fully-managed Ruby DevOps
  • Easy to use, Git Push deployment
  • Auto scaling, boost performance
  • Private, fully-configured Kubernetes cluster
  • Linear pricing that scales, no surprises
  • Decades of Ruby and AWS experience

14 day trial. No credit card required.

Sign Up for Engine Yard

14 day trial. No credit card required.

Book a Demo