Skip to content
This repository has been archived by the owner on Jun 25, 2020. It is now read-only.

Serialized handling of requests #126

Open
liaden opened this issue May 26, 2015 · 4 comments
Open

Serialized handling of requests #126

liaden opened this issue May 26, 2015 · 4 comments

Comments

@liaden
Copy link

liaden commented May 26, 2015

Currently running into a deadlock problem where micro service A is hitting micro service B which is hitting micro service A again. The deadlock causes a timeout.

With a controller like

class StatusController < ApplicationController
  def index
    sleep 25
  end
end

and the following:

time curl machine.dev &
time curl machine.dev &

we end up seeing request 1 takes 25.x seconds and request 2 takes 52 seconds to complete.

We have tried the following .praxconfig:

export PRAX_APP_THREADS=16
export PRAX_THREADS=32
source /usr/local/share/chruby/chruby.sh
source /usr/local/share/chruby/auto.sh
@ysbaddaden
Copy link
Owner

Prax isn't battle tested for this use case: many services calling each others. You'll eventually run out of workers, and deadlock.

Yet, is your sleep example called many times through the services, or just twice by curl?

@liaden
Copy link
Author

liaden commented Jun 1, 2015

In my example, sleep is called just twice by curl.

It also seems like there is a difference in the behavior of how prax runs my different rails apps if I have the application launched with rubinius instead of MRI. I am not entirely sure that changing PRAX_APP_THREADS or PRAX_THREADS is changing anything in how the system behave.

@ysbaddaden
Copy link
Owner

I never checked against Rails apps, but the same test with a raw Rack application didn't wait (as far as I remember).

I recall Rails before 4.0 (?) added a mutex around requests, to force requests to not run in parallel.

@liaden
Copy link
Author

liaden commented Jun 1, 2015

I am unsure of what Rails and Rack is doing, but when running on Macs with powify, the problem is not seen.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants