9

Rails 4 アプリケーションで使用するカスタム ラック ミドルウェアがあります。ミドルウェア自体は、クライアントが有効な情報を提供しなかった場合にデフォルトAcceptでContent-Typeヘッダーを作成するためにここにありますapplication/json(私は API に取り組んでいます)。したがって、各リクエストの前にこれらのヘッダーを変更し、各リクエストの後に、カスタム メディア タイプ情報を含むカスタム X-Something-Media-Type ヘッドを追加します。

Puma に切り替えたいので、そのようなミドルウェアのスレッドセーフが少し心配です。すべてのミドルウェアで遭遇する共通のものを除いて、私はインスタンス変数を@app.callいじりませんでしたが、ここでも RailsCasts のコメントで読んだものを再現しました:

def initialize(app)
 @app = app
end

def call(env)
 dup._call(env)
end

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

dup._callスレッドセーフの問題を処理するために本当に便利ですか?

そのインスタンス変数を除いて、@app私は現在の環境変数で構築された現在のリクエストでのみ再生します:

request      = Rack::Request.new(env)

env.updateそして、ヘッダーとフォーム情報を更新するために呼び出します。

Webrickからのような同時 Web サーバーに切り替えるときに、そのミドルウェアで何らかの問題が発生すると予想するのは危険Pumaですか?

はいの場合、スレッドセーフではないミドルウェアの部分を分離していくつかのテストを行ういくつかの方法を知っていますか?

ありがとう。

4

1 に答える 1

6

はい、dupミドルウェアがスレッドセーフである必要があります。そうすれば、設定元のインスタンス変数はすべて_call、元のインスタンスではなく、複製されたインスタンスに設定されます。Rack を中心に構築された Web フレームワークが次のように機能することに気付くでしょう。

これを単体テストする 1 つの方法_callは、元のインスタンスではなく複製されたインスタンスで呼び出されることをアサートすることです。

于 2014-10-30T20:01:43.683 に答える