bus dịch vụ xanh không nhận được tất cả tin nhắn (chỉ ~ 65%)

Question

Đây là câu hỏi gần nhất trước đây tôi có thể tìm thấy: Azure Service Bus Subscription OnMessage not receiving messages.

Điều tương tự cũng xảy ra với tôi. Khi tôi thay đổi tên của chủ đề nó hoạt động trong một thời gian nữa. Sau đó, chủ đề xe buýt dịch vụ đó lại bị hỏng. Chỉ có 65-71% tin nhắn đến. Không giúp xóa các phụ đề, cũng không phải chủ đề. Tên chủ đề dường như bị ô nhiễm bằng cách nào đó sau một thời gian. Nó thực sự thực sự tồi tệ, bởi vì tôi không có cách nào để nói khi chủ đề bị hỏng, ngoại trừ việc hệ thống không hoạt động giống như khi tin nhắn không đến. Tạo một chủ đề mới với tên mới ngẫu nhiên ngay bây giờ và sau đó có vẻ như một giải pháp hoàn toàn tồi tệ.

Tôi đang thử nghiệm thông qua một vòng lặp trong một quy trình, gửi thư, sau đó lặp lại trong một quy trình khác, đang nhận và đếm. Với một tên chủ đề mới, nó hoạt động hoàn hảo. Và tôi biết tôi chỉ có một người nghe đến thuê bao, và đó là một khóa nhìn trộm, yêu cầu thông điệp được hoàn thành.

Bất kỳ ai? Làm sao tôi có thể giải quyết việc này?

CẬP NHẬT: Có một hình ảnh xác thực được tìm thấy ở đây. Tôi đã có 1 đăng ký được tạo và duy trì kết nối với nó; 1 chủ đề được tạo và xe buýt được tạo lại 10 lần, gửi 100 tin nhắn mỗi lần. Không có tin nhắn nào bị mất. Tôi đã tạo 1 đăng ký và một đăng ký mới được tạo cho mỗi lần xe buýt được tạo lại và 100 tin nhắn được gửi. Mất 50% tin nhắn. Có vẻ như chủ đề đã biết về gói thuê bao trước đó và các thông báo sẽ được xử lý cho cả hai?

CÂU HỎI MỚI: Tôi đang cố gắng bọc đầu xung quanh cách xử lý việc này. Bất cứ ai có thể xác nhận rằng việc khởi động lại quy trình, dẫn đến việc tạo ứng dụng đăng ký mới có cùng tên đăng ký, sẽ làm cho chủ đề xử lý thông điệp giữa khách hàng đăng ký đầu tiên và khách hàng thứ hai, mặc dù người đầu tiên không còn ở đó nữa? Vì tôi đang cố gắng xử lý lỗi bằng cách khởi động lại mô-đun đăng ký, tức là thực hiện các bước kiểm tra xem chủ đề có tồn tại không, nếu đăng ký tồn tại và sau đó tạo ứng dụng đăng ký, tôi đang cố gắng hiểu cách tôi có thể tránh được mô tả ở trên, và tránh các thông điệp được xử lý ra các thuê bao không existant cũng ..

Đề xuất cho giải pháp, atm: Theo dõi các thuê bao cũ, và nếu tôi phải khởi động lại quá trình, tạo một thuê bao mới? Để lại một cửa sổ giữa quá trình đi xuống và đăng ký mới được tạo, nơi thư sẽ được bơm ra chỉ cho đăng ký "đã chết". Những tin nhắn này sẽ bị mất. Nhưng ít nhất bất kỳ tin nhắn nào sau đó sẽ được đăng ký mới. Man .. vấn đề này phải được xử lý trước đây. Tôi không làm đúng. Sẽ đánh giá cao một số hướng dẫn tại đây.

GIẢI PHÁP: Đó là tất cả về công cụ phù hợp cho công việc. Tình huống này gọi cho một Hàng đợi, không phải là một Pub/Sub. Mọi thứ được giải quyết. Tôi đang làm các thử nghiệm tương tự như trên, nhưng với hàng đợi thay vào đó, và tất nhiên, vì nó quyết định khách hàng nhận được một tin nhắn, không có vấn đề với trước đó (đã chết) thuê bao nhận tin nhắn từ những cái mới. Chỉ có một ứng dụng khách hàng đợi sẽ vẫn hoạt động tại một thời điểm, do đó, chỉ có một người có thể lấy thông điệp ra khỏi hàng đợi.

Answer 1

GIẢI PHÁP: Đó là tất cả về công cụ phù hợp cho công việc. Tình huống này gọi cho một Hàng đợi, không phải là một Pub/Sub. Mọi thứ đã được giải quyết.Tôi đang làm các thử nghiệm tương tự như trên, nhưng với hàng đợi thay vào đó, và tất nhiên, vì nó quyết định khách hàng nhận được một tin nhắn, không có vấn đề với trước đó (đã chết) thuê bao nhận tin nhắn từ những cái mới. Chỉ có một ứng dụng khách hàng đợi sẽ vẫn hoạt động tại một thời điểm, do đó, chỉ có một người có thể lấy các thông điệp ra khỏi hàng đợi.