มีบางอย่างที่ทำให้ NServiceBus สูญเสียข้อความ

ฉันมีการกำหนดค่า NServiceBus ที่ทำงานได้ดีบนเครื่องของนักพัฒนาและในสภาพแวดล้อมการพัฒนาของฉัน

อย่างไรก็ตาม เมื่อฉันย้ายมันไปที่สภาพแวดล้อมการทดสอบ ข้อความของฉันก็เริ่มถูกโยนทิ้ง

นี่คือระบบ:

  1. แอปได้รับข้อความ TCP จากระบบเมนเฟรมและส่งไปยัง MSMQ (เรียกว่า FromMainframe)
  2. แอปพลิเคชันที่โฮสต์ใน IIS มีวิธี "จัดการ" สำหรับ MSMQ นั้นและประมวลผลข้อความจากเมนเฟรม

ในสภาพแวดล้อมการทดสอบของฉัน ขั้นตอนที่สองเกิดขึ้นเพียงครึ่งทางเท่านั้น ข้อความถูกดึงออกมาจาก MSMQ แต่แอปพลิเคชันของฉันไม่ได้ประมวลผล

ข้อมูลของฉันสูญหายอย่างมีประสิทธิภาพ! NServiceBus ลบมันออกจากคิว แต่ฉันไม่เคยประมวลผลมันเลย พวกเขาไม่อยู่ในคิวข้อผิดพลาดด้วยซ้ำ!

นี่คือสิ่งที่ฉันได้ลองเพื่อพยายามค้นหาว่าเกิดอะไรขึ้น:

  1. ตรวจสอบไฟล์กำหนดค่า
  2. Attach a remote debugger to the process to see what the Handle method is doing
    • The Handle method is never called (but when I attach to the Development Environment my breakpoint in my Handle method is hit and it all works flawlessly).
  3. ปรับใช้เวอร์ชัน Dev ของฉันอีกครั้งกับ Test Envioronment แล้วลองขั้นตอนที่ 2 อีกครั้ง (ในกรณีที่เวอร์ชันไม่เหมือนกันทุกประการ)
  4. ตรวจสอบไฟล์กำหนดค่าอีกครั้ง
  5. Check that the Error queue is not filling up
    • The error queue stays empty (I wish it would fill up, then my data would not be LOST).
  6. Check for any other process that may be pulling stuff from my MSMQs
    • I Turned off my IIS website and the messages in the FromMainframe queue start to backup.
    • เมื่อฉันเปิดเครื่องอีกครั้ง ข้อความจะหายไปค่อนข้างเร็ว (แต่ยังไม่ทั้งหมดในคราวเดียว) ความเร็วที่หายไปนั้นเร็วเกินไปสำหรับการประมวลผลด้วยวิธี Handle ของฉัน
  7. ตรวจสอบไฟล์ Config อีกครั้ง
  8. Run the NServiceBusTools\MsmqUtils\Runner.exe \i
    • I ran it, rebooted, ran it again and again for good measure!
  9. ตรวจสอบการกำหนดค่าอีกครั้ง (ฉันคงพลาดอะไรบางอย่างใช่ไหม)
  10. Check the Development Environment Configs are not pointing to the Test Environment
    • I don't think it is possible to use another computer's MSMQ as your input queue, but it does not hurt to check.
  11. มองหาบล็อกที่ตรวจจับได้ที่อาจทำลายข้อความของฉันอย่างเงียบๆ
  12. การตรวจสอบไฟล์ Config ครั้งสุดท้าย
  13. สร้างสภาพแวดล้อมการทดสอบของฉันใหม่บนเครื่องอื่น (ทำงานได้อย่างไร้ที่ติ)
  14. Run my stuff outside of IIS.
    • When I host outside of IIS (using NServiceBus.Host.exe) it all works fine. So it has to be an IIS thing right?
  15. บ้าไปแล้ว และหวังว่า Stack Overflow จะสามารถให้ข้อมูลเชิงลึกทุกประเภทได้

person Vaccano    schedule 19.03.2012    source แหล่งที่มา
comment
NSB กำลังโฮสต์อยู่ใน IIS หรือไม่ มีการกำหนดค่าโปรโตคอลอะไรบ้าง? คิวของคุณเป็นธุรกรรมหรือไม่? MSDTC เปิดใช้งานแล้วหรือยัง? App Pool Identity มีสิทธิ์ที่ถูกต้องในคิวหรือไม่ ข้อความไปอยู่ในคิวจดหมายที่ไม่ทำงานของระบบหรือไม่?   -  person Adam Fyles    schedule 20.03.2012
comment
คุณได้กำหนดค่า log4net เพื่อบันทึกเอาต์พุต nservicebus ทั้งหมดหรือไม่ คำตอบของคุณอาจอยู่ในนั้น .. nservicebus เวอร์ชันใดด้วย   -  person Sarmaad    schedule 20.03.2012
comment
@AdamFyles - NSB กำลังโฮสต์ใน IIS ฉันจะต้องตรวจสอบโปรโตคอล (ฉันไม่คิดว่าจะส่งผลกระทบต่อ NSB) MSMQ ของฉันถูกตั้งค่าโดย NSB ดังนั้นฉันคิดว่ามันเป็นธุรกรรม กลุ่มแอพมีสิทธิ์ที่ถูกต้อง ข้อความไม่สิ้นสุดในคิวจดหมายที่ไม่ทำงาน (พวกเขาเพิ่งไปแล้ว)   -  person Vaccano    schedule 20.03.2012
comment
@Sarmaad - ฉันยังไม่ได้ทำอย่างนั้น ฉันก็ไม่รู้เหมือนกัน ถ้ารู้วิธีกรุณาโพสต์ไว้ครับ (ถ้าไม่ฉันจะขุดมันขึ้นมา) ฉันใช้ NSB 2.6.0.1506   -  person Vaccano    schedule 20.03.2012
comment
คุณสามารถอ่านคิวจากโค้ดนอก IIS ได้หรือไม่ คุณยังสามารถลองเปิดการบันทึกแหล่งที่มาเชิงลบใน MSMQ ได้ ซึ่งจะช่วยให้คุณระบุสิ่งที่เกิดขึ้นกับข้อความได้   -  person Adam Fyles    schedule 20.03.2012
comment
@AdamFyles - ฉันไม่คิดว่า Negative Source Journaling จะช่วยได้ เห็นคิวเต็มแล้ว.. ข้อความก็เข้าได้ดี เมื่อแอปพลิเคชันดำเนินการกับปัญหาที่เกิดขึ้น แฮนเดิลไม่เคยถูกเรียก เหมือนกับว่า NServiceBus มีบางอย่างบอกให้พิจารณาข้อความที่ประมวลผลก่อนที่จะเรียก Handle (บางทีฉันอาจไม่เข้าใจ Negative Source Journaling แต่ฉันคิดว่าเป็นเพราะปัญหาที่ข้อความไม่เคยมาถึง)   -  person Vaccano    schedule 20.03.2012
comment
ฉันสงสัยว่านั่นอาจจับได้ว่าทำไมพวกเขาถึงไม่อยู่ในคิวข้อผิดพลาด ฉันนิ่งงันว่าทำไม NSB ไม่แสดงข้อผิดพลาดใดๆ ให้คุณเห็น ซึ่งเป็นเหตุผลว่าทำไมฉันถึงเอนเอียงไปทางสิ่งผิดปกติในโครงสร้างพื้นฐาน คุณช่วยโพสต์วิธีกำหนดค่าอุปกรณ์ปลายทางของคุณได้ไหม   -  person Adam Fyles    schedule 21.03.2012
comment
@AdamFyles - ฉันไม่รู้วิธีเปิดการบันทึกแหล่งที่มาเชิงลบในคิว ฉันเห็นเฉพาะตัวเลือกสำหรับการบันทึกแบบปกติเท่านั้น คุณรู้วิธีเปิดใช้งานหรือไม่?   -  person Vaccano    schedule 21.03.2012
comment
@AdamFyles - ฉันพยายามตั้งค่า MSMQ ให้ทำงานนอก IIS (โดยใช้ NServiceBus.Host.exe) มันใช้งานได้ดี! ฉันคิดว่านี่หมายความว่าจะต้องเป็นสิ่งที่ IIS ดังนั้นฉันจึงได้เพิ่ม IIS ให้กับแท็ก   -  person Vaccano    schedule 21.03.2012
comment
@AdamFyles - ฉันตรวจสอบโปรโตคอลแล้ว ได้แก่: http, net.tcp, net.pipe, net.msmq, msmq.formatname   -  person Vaccano    schedule 21.03.2012
comment
ฉันจะลองเปลี่ยนโปรโตคอลที่ใช้ msmq หรือปิดบริการฟังที่เกี่ยวข้องในกรณีที่ WAS ขโมยข้อความของคุณ นี่คือลิงค์ที่ดีเกี่ยวกับข้อความที่หายไป: blogs.msdn.com/b/johnbreakwell/archive/2010/01/22/   -  person Adam Fyles    schedule 21.03.2012
comment
@AdamFyles - ขอบคุณสำหรับความช่วยเหลือในเรื่องนี้ ฉันคิดว่าฉันได้รับคำตอบเกี่ยวกับสิ่งที่เกิดขึ้น (ดูด้านล่าง)   -  person Vaccano    schedule 21.03.2012


คำตอบ (1)


ฉันจึงรู้ดีเพียงพอเกี่ยวกับสิ่งที่เกิดขึ้นและโยน "คำตอบ" ออกไป

เมื่อฉันตั้งค่า NServiceBus โฮสติ้งด้วยตนเอง ฉันได้รับสายที่โหลดตัวจัดการข้อความ

NServiceBus.Configure.With().LoadMessageHandlers()

(มีการกำหนดค่ามากกว่านี้ แต่ฉันข้ามไปเพื่อความกระชับ)

เมื่อคุณเรียกสิ่งนี้ NServiceBus จะสแกน assmeblies เพื่อหาคลาสที่ใช้ IHandleMessages<T>

ดังนั้นใน Test Environment Machine ของฉัน การสแกน ServiceBus ของไดเร็กทอรีสำหรับคลาสที่เรียก IHandleMessages ล้มเหลวในการค้นหาคลาสของฉัน (แม้ว่าแอสเซมบลีจะอยู่ที่นั่นอย่างแน่นอน)

ปรากฎว่าถ้า NServiceBus ไม่พบสิ่งที่จัดการข้อความ มันจะ โยนทิ้งไป!!!

นี่เป็นข้อบกพร่องด้านการออกแบบโดยรวมในความคิดของฉัน แนวคิดทั้งหมดของ NServiceBus คือการไม่สูญเสียข้อมูลของคุณ แต่ในกรณีนี้มันก็เป็นเช่นนั้น!

เมื่อคุณรู้เกี่ยวกับหลุมพรางนี้แล้ว ก็มีหลายวิธีที่จะแก้ไขได้

  1. ระบุอย่างชัดเจนว่าผู้ดูแลของคุณควรเป็นอย่างไร:

    NServiceBus.Configure.With().LoadMessageHandlers<First<MyMessageType>>()

  2. การป้องกันเพิ่มเติมคือการเพิ่มตัวจัดการอื่นที่จะจัดการ "อย่างอื่น" IMessage เป็นฐานสำหรับเพย์โหลดข้อความทั้งหมด ดังนั้นหากคุณใส่ตัวจัดการไว้ ตัวจัดการจะรับทุกอย่าง
    หากคุณตั้งค่า IMessage เป็น จัดการหลังจากข้อความของคุณได้รับการจัดการ จากนั้นมันจะจัดการทุกสิ่งที่ NServiceBus ไม่สามารถหาตัวจัดการได้ หากคุณโยนและยกเว้นในเมธอด Handle ซึ่งจะทำให้ NServiceBus ย้ายข้อความไปที่คิว error (สิ่งที่ฉันคิดว่าควรเป็นพฤติกรรมค่าเริ่มต้น)

person Vaccano    schedule 21.03.2012
comment
คุณทำงานเพื่อระบุตัวจัดการข้อความทั้งหมดของคุณที่นั่นหรือเพียงตัวเดียวในชุดการจัดการข้อความ? - person Galen; 10.08.2012
comment
@Galen - ฉันมีตัวจัดการข้อความเพียงตัวเดียว และฉันระบุอย่างชัดเจนว่ามันคืออะไรในการกำหนดค่าของฉันตอนนี้ - person Vaccano; 10.08.2012