دورة حياة حالات الحافلات وأفضل الممارسات [مغلق]

Question

مغلق.هذا السؤال هو على أساس الرأي.لا يقبل حاليا الإجابات.

---

تريد تحسين هذا السؤال? تحديث السؤال بحيث يمكن الإجابة مع الحقائق والاستشهادات من قبل تحرير هذا المنشور.

مغلق منذ 5 سنوات.

في حين تهرب آليات الطابور بشكل عام و ريبوس على وجه الخصوص ، خطرت لي الأسئلة التالية حول دورة حياة حالات الحافلة:

1. عندما تحتاج إلى الوصول إلى مثيل الحافلة (وضع العميل في اتجاه واحد) من عدة خدمات وف استضافتها على خدمة ويندوز, الخيار الوحيد ل إنستانسينغ على وضع سينغلتون?

2. هناك طريقة لإيقاف الحافلة مؤقتا (توقف عن إرسال الرسالة إلى معالجات الرسائل?) ثم ابدأ تشغيله مرة أخرى.أو الخيار الوحيد هو التخلص منه وإنشاء واحدة جديدة.

   • حالة الاستخدام لهذا هي عند الاتصال بالأنظمة التي لها قيود الإنتاجية ، أو المعاملات في حدود الساعة.

3. يمكن الملاحم يكون العمال متعددة, إذا كان الأمر كذلك ، وعلى افتراض أن الأحداث تم إرسالها على الترتيب الصحيح (البادئ أولا), هناك طريقة لضمان أن البادئ سوف يتم التعامل معها أولا, هناك لخلق الملحمة, قبل أن يتم التعامل مع الأحداث التالية مع العمال متعددة?

4. إذا تم استخدام العديد من مثيلات الحافلات في نفس المضيف ، وداخل معالج الرسائل نسميه إرسال على مثيل ناقل آخر بناء على نفس التكوين.لن يتم نقل معرف الارتباط, وأشياء مثل الرد لن تعمل بشكل صحيح, حق?

أنا أفضل إجابات ملموسة على كيفية ريبوس يمكن أن تدعم أو لا هذا ، مع المراجع رمز/أمثلة.

Answer 1

1:انها حقا بسيطة:مثيل الحافلة (أي.تنفيذ IBus أن يحصل على وضع في الحاوية ويتم تسليم لك عند القيام Configure.With(...) نوبات التكوين) من المفترض أن يكون مثيل المفرد الذي تبقي حولها لمدة كاملة من عمر التطبيق الخاص بك.

يمكنك بسهولة إنشاء مثيلات متعددة ، ولكن هذا سيكون مفيدا فقط لاستضافة نقاط نهاية متعددة في نفس العملية.

إو الحافلة هو إعادة الدخول بالكامل ويمكن بأمان أن تكون مشتركة بين المواضيع في تطبيق الويب الخاص بك.

2:ليس بسهولة ، لا-على الأقل ليس بطريقة تدعمها واجهة برمجة التطبيقات العامة.أنت يمكن هل هذا على الرغم من: ((RebusBus)bus).SetNumberOfWorkers(0) (أي.يلقي IBus مثيل ل RebusBus وتغيير عدد مؤشرات ترابط العمال) ، والتي سيتم حظرها حتى يتم تعديل عدد العمال إلى الرقم المطلوب.

بهذه الطريقة ، يمكنك فعلا تحقيق ما كنت بعد.انها ليست مجرد سمة رسمية من اللغز (حتى الآن) ، ولكن قد يكون في المستقبل.يمكنني أن أضمن ، مع ذلك ، أن القدرة على ضبط عدد العمال في وقت التشغيل لن تختفي.

3:نعم، تخضع الملاحم لحراسة مخطط التزامن المتفائل بغض النظر عن طبقة الثبات التي تختارها.إذا لم تكن متأكدا من نوع الرسالة التي ستصل أولا إلى الملحمة الخاصة بك ، فيجب أن تجعل الملحمة الخاصة بك متسامحة مع هذا - أي.مجرد تنفيذ IAmInitiatedBy<> لكل نوع رسالة يحتمل أن يبدأ وجعل الملحمة تتعامل بشكل صحيح.

كونك (إلى حد ما) متسامحا مع الرسائل خارج الترتيب هو مبدأ متانة عام جيد سيخدمك جيدا أيضا عند إعادة تسليم الرسائل بعد البقاء لفترة في قائمة انتظار الخطأ.

4:سوف اللغز التقاط سياق الرسالة الحالية على الرغم من أنك تستخدم مثيلات حافلة متعددة لأنه يستخدم "السياق المحيط" (أي.a MessageContext على مؤشر ترابط العامل) لالتقاط حقيقة أنك ترسل رسالة من داخل معالج ، مما يؤدي بدوره إلى نسخ معرف الارتباط للرسالة التي تم التعامل معها إلى أي رسائل صادرة.

وهكذا bus.Reply سوف تعمل أيضا.

ولكن كما ذكرت في (1) مثيل الحافلة هو إعادة الدخول بالكامل وليس هناك حاجة إلى وجود مثيلات متعددة حولها ، إلا إذا كانت في الواقع نقاط نهاية الفرق منطقيا.

آمل أن يكون هذا يجيب على أسئلتك :)