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. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/597809f2-6cc7-4834-ac37-0e3590f769ee%40googlegroups.com.
