3

私はZappaアプリに取り組んでおり、現在、サーバーを停止しrequire.cache、ファイルが変更されたときにサーバーをクリアして再要求し、再起動する小さな監視スクリプトを作成しようとしています。

# watch all dependent files
for file of require.cache
  fs.watch file, ->
    # attach a handler to 'close'
    # -- here's the issue: this takes far too long to trigger
    server.on 'close', ->
      server = require './server'
      server.start()

      # log the new server's id
      console.log server.id

    # stop the current server instance
    server.stop()

    # clear require's cache
    delete require.cache[f] for f of require.cache

console.log server.idIDが一致するかどうかを確認できるように、リクエストハンドラにも行があります。

つまり、依存関係を変更すると、サーバーが停止し、新しいIDが起動し、新しいIDがログに記録されます。これはすべて重大です。ただし、その後のランダムな時間の間、サーバーへの要求は引き続き古いIDをログに記録し、古いリスナーがまだ何らかの形で接続されていることを示します。最終的に、リスナーは「切り替え」たように見え、新しいIDがログに記録されます。

更新：これはcloseイベントに関連しているようです（当然のことながら）-イベントに単純なconsole.log 'close'コールバックをアタッチすると、表示close後にIDが変更され始め'close'ます。ただし、イベントが発生するまでに長い時間（10秒以上）かかるclose場合があります。なぜこれほど時間がかかるのでしょうか。

4

2 に答える 2

3

node.jsのドキュメントによると：

server.close（）

サーバーが新しい接続を受け入れるのを停止します。net.Server.close（）を参照してください。

したがって、サーバーは新しい接続の受け入れを停止しますが、現在の接続が閉じられるまで実際には閉じません（そしてcloseイベントを発行しません）。私の推測では、おそらくkeep-aliveリクエストを使用して、クライアントが接続していると思います。

于 2012-02-17T13:01:35.853 に答える
0

私は同じ問題を探していました。これを探しているあなたや他の人に解決策を与えるには：

プロジェクトで問題がなければ、すべての接続をすぐに閉じることができます。これは私にとってのクロージングの問題を完全に解決します。

app.use((req, res, next) => {
    res.setHeader('Connection', 'close');
    next();
});
于 2017-03-16T10:05:54.077 に答える