Plumber: 長いリクエストでタイムアウト

作成日 2016年08月25日  ·  3コメント  ·  ソース: rstudio/plumber

やあ !

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は避けたい

よろしくお願いします、
エマニュエル

最も参考になるコメント

誰かがこの問題に関連していると思った場合に備えて: 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)
}

全てのコメント3件

残念ながら、私は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)
}
このページは役に立ちましたか?
0 / 5 - 0 評価

関連する問題

actuarialvoodoo picture actuarialvoodoo  ·  6コメント

alexzaytsev-newsroomly picture alexzaytsev-newsroomly  ·  6コメント

shangfr picture shangfr  ·  5コメント

jeffkeller87 picture jeffkeller87  ·  6コメント

trestletech picture trestletech  ·  5コメント