Ruby on Rails

I think you have the situation where a user U sends a request to Rails app A which in turn calls a service B. Then, service B makes a request back to Rails app A, presumably for some additional information from the DB. You want to make sure the second request from B to A does not block.

If the above understanding is correct, then using Puma in multithreading mode will work as long as you have enough workers. (We use this approach in production for a similar architecture). The GIL is not an issue, I think it is thread (worker) specific.

Alternatively, if you want to use Puma in single threaded mode, you can run a second copy of the Rails app (say A2) either listening on a different port (eg 8001) or on a separate, dedicated URL (eg B-server.example.com) and then send the requests from B to A2 at the second port or hte second hostname. We started with this approach using a second port before adopting Puma.

Hope this helps.

Phil

On Friday, August 9, 2019 at 11:07:32 AM UTC-5, San Ji wrote:

Hi Hassan

I don't because that would not solve my problem.
He was describing a kind of more usual deadlock caused by the global interpreter lock.
Where Puma send the cyclic request to the same multithreaded worker, but the worker was unable to process the latter request because of the GIL. (I guess)

While in a single-threaded config Puma would not send cyclic requests to the originating worker in the first place.

In contrast, I was describing the deadlock caused by the cyclic request itself. While less usual, this is still possible.

All workers can be occupied without a single one of them handling the cyclic requests causing the indefinite wait. (Until one of them timeout)

I want to solve this systematically, not statistically. (I must admit that the latter would be a practical option too.)

Plus I am seeking less hassle, not more. JRuby/Rubinius are relatively worst options (in my situation) compared to just spinning up multiple Puma and have that dedicated pool of workers handling the cyclic requests.