Shinyproxy: إيضاح عن نبضات القلب لحاويات الرصيف

+1

مرحبًا @ jat255

يعمل ShinyProxy حاليًا على النحو التالي:

• كل proxy.heartbeat-rate يرسل ShinyProxy نبضات إلى العميل. إذا أجاب العميل ، يتم تحديث الحالة الداخلية بالوقت الحالي. الافتراضي heartbeat-rate هو 10 ثوانٍ. يتم إرسال دقات القلب هذه عبر قناة websocket (إن وجدت).
• يقوم كل طلب HTTP لتطبيق ما أيضًا بتحديث الحالة الداخلية.
• إذا كانت النبضات الأخيرة للحاوية أطول من proxy.heartbeat-timeout قبل ذلك ، فإن ShinyProxy تقتل التطبيق. هذا افتراضيًا 60 ثانية.

طالما أن المستخدم يحتفظ بالمتصفح مفتوحًا ويكون اتصال websocket مفتوحًا أو يتم إرسال طلبات HTTP ، فإن ShinyProxy يفترض أن التطبيق قيد الاستخدام وبالتالي لن يوقفه.
لاحظ أن Spring سيبقي أيضًا جلسة المستخدم مفتوحة طالما أن التطبيق يرسل طلبات HTTP.

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

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

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