Plumber: مهلة مع طلب طويل

لسوء الحظ ، لست على دراية كافية بالجزء الداخلي من httpuv لأتمكن من التحدث بذكاء عن سبب حدوث ذلك.

للتراجع خطوة إلى الوراء ، على الرغم من ذلك ، فإن النمط المعتاد عند القيام بهذه الأنواع من المهام طويلة العمر في أنظمة أخرى هو الاستجابة فورًا للطلب الوارد ثم بدء العمل بشكل غير متزامن. يحصل العميل على بعض المعرفات استجابةً للطلب الأصلي ، ثم يمكنه الاقتراع لمعرفة وقت اكتماله.

لسوء الحظ ، R عبارة عن خيوط مفردة لذا فإن هذا أكثر تعقيدًا بعض الشيء. ولكن إذا كنت متحمسًا بشكل كافٍ ، يمكنك إلقاء نظرة على fork ing عملية R (انظر الحزم المتوازية أو متعددة النواة) ثم إنشاء التقرير في مفترق العملية ، وترك العملية الرئيسية متاحة للرد على طلبات واجهة برمجة التطبيقات (مثل العملاء الذين يقومون بالاقتراع لمعرفة ما إذا تم إنشاء تقريرهم).

أهلا،

هنا ، قمنا بتحسين كود 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)
}