Concurrent calls to server in Development yields "uninitialized constant" errors

dkobia commented 5 years ago

Checklist

[x] Upgrade Jets: Are you using the latest version of Jets? This allows Jets to fix issues fast. There's a jets upgrade command that makes this a simple task. There's also an Upgrading Guide: http://rubyonjets.com/docs/upgrading/
[x] Reproducibility: Are you reporting a bug others will be able to reproduce and not asking a question. If you're unsure or want to ask a question, do so on https://community.rubyonjets.com
[ ] Code sample: Have you put together a code sample to reproduce the issue and make it available? Code samples help speed up fixes dramatically. If it's an easily reproducible issue, then code samples are not needed. If you're unsure, please include a code sample.

My Environment

Software	Version
Operating System	10.14.4
Jets	1.9.10
Ruby	2.5.1p57

Expected Behaviour

Execute two concurrent GET request to Jets API in development for demo project should yield valid responses.

The reason this is a problem is because we're testing an app on local that makes concurrent requests (2) and one always comes back with an error.

Current Behavior

I'm not sure if this is by design or not but if I execute two or more concurrent requests to a Jets API I get uninitialized constant XXXX errors to random classes.

Step-by-step reproduction instructions

Set up and deploy the demo at: https://blog.boltops.com/2019/01/13/build-an-api-service-with-jets-ruby-serverless-framework
In separate window run curl http://localhost:8888/posts & curl http://localhost:8888/posts
One of the calls should give you a uninitialized constant PostsController::Post

Code Sample

Solution Suggestion

dkobia commented 5 years ago

To be fair a similar problem is mentioned at Rails: https://github.com/rails/rails/issues/32451

tongueroo commented 5 years ago

Thanks so much for the report! This is probably what is going on with #281 and #280 also.

dkobia commented 5 years ago

I'm currently able to get around this by commenting out Jets::Autoloaders.main.reload if Jets.env.development? in lib/jets/controller/base.rb. Just means development will be painful. Digging into it further I came across this ticket at Zeitwerk: https://github.com/fxn/zeitwerk/issues/52

tongueroo commented 5 years ago

@dkobia This is helpful!

Was able to reproduce the error with curl:

for i in {1..2} ; do echo $i ; curl localhost:8888/posts & done

I was actually looking at the same technique in the https://github.com/fxn/zeitwerk/issues/52 issue to fix the issue.

For some reason the @mutex.synchronize is not "locking" the request and processing in serial. Another request starts before the other request has finished:

jets reloader mutex

Maybe am not using the Mutex correctly 🤔

tongueroo commented 5 years ago

@dkobia Figured it out. Needed to use a global variable for the mutex otherwise the mutex was a brand new one every request. Released in v1.9.11

dkobia commented 5 years ago

@tongueroo ... very nicely done!

tongueroo commented 5 years ago

Thanks for the help. The report was key. Adjusted the reloader middleware in v1.9.12 slightly to use a class variable instead. Thanks again!

rubyonjets / jets