やあ !
PDFで約3分かかる長いレポートを生成しており、Plumberを介して公開しています。
HTTP接続は約1分40秒(100秒)で閉じます。
したがって、配管工は閉じた接続にデータを送信しようとするため、論理エラーメッセージが表示されます。
ERROR: [on_request_read] connection reset by peer
#12に関連していると思います。ちなみにhttps://github.com/rstudio/httpuv/issues/49
配管工でそれを修正する方法はありますか? Plumberで次のようなものを手動で送信することによる可能性があります。
Keep-Alive: timeout=300
Connection: Keep-Alive
しかし、いずれにせよ、#12は避けたい
よろしくお願いします、
エマニュエル
残念ながら、私はhttpuvの内部に精通していないため、これが発生する理由についてインテリジェントに話すことができません。
ただし、一歩後退するために、他のシステムでこの種の長期的なタスクを実行する場合の通常のパターンは、着信要求にすぐに応答してから、非同期で作業を開始することです。 クライアントは、元の要求に応答してIDを取得し、それをポーリングして、いつ完了したかを確認できます。
残念ながら、Rはシングルスレッドであるため、これはもう少し複雑です。 ただし、十分な意欲があれば、Rプロセスのfork
を確認して(パラレルパッケージまたはマルチコアパッケージを参照)、プロセスのフォークでレポートを生成し、親プロセスをAPIリクエストに応答できるようにしておくことができます。 (レポートが生成されるかどうかを確認するためにポーリングしているクライアントのように)。
やあ、
ここでは、Rコードを最適化したので、実際には問題ありません。 ただし、他の場合には問題が再発する可能性があります。 解決策を見つけたら、戻ってきてここに公開します。
誰かがこの問題に関連していると思った場合に備えて: fork
ingは非常にうまく機能し、 parallel
パッケージで簡単に実行できます。
parallel <- function() {
# Long running calculation here
print("Sleeping...")
Sys.sleep(10)
print("Finished.")
return(Sys.time())
}
#* <strong i="8">@get</strong> /parallel
parallelTest <- function() {
parallel::mcparallel(parallel())
return(TRUE)
}
最も参考になるコメント
誰かがこの問題に関連していると思った場合に備えて:
fork
ingは非常にうまく機能し、parallel
パッケージで簡単に実行できます。