ruby on rails - Rack middleware and thread-safety -


i have custom rack middleware used rails 4 application. middleware here default accept , content-type headers application/json if client did not provide valid information (i'm working on api). before each request changes headers , after each request adds custom x-something-media-type head custom media type information.

i switch puma, therefore i'm bit worried thread-safety of such middleware. did not play instances variables, except once common @app.call encounter in every middleware, here reproduced i've read in railscasts' comments :

def initialize(app)  @app = app end  def call(env)  dup._call(env) end  def _call(env)  ...  status, headers, response = @app.call(env)  ... 

is dup._call useful in order handle thread-safety problems ?

except @app instance variable play current request built current env variable :

request      = rack::request.new(env) 

and call env.update update headers , forms informations.

is dangerous enough expect issues middleware when i'll switch webrick concurrent web server such puma ?

if yes, know handful way make tests en isolate portions of middleware non-thread-safe ?

thanks.

yes, it's necessary dup middleware thread-safe. way, instance variables set _call set on duped instance, not original. you'll notice web frameworks built around rack work way:

one way unit test assert _call called on duped instance rather original.


Comments

Popular posts from this blog

apache - Remove .php and add trailing slash in url using htaccess not loading css -

javascript - jQuery show full size image on click -