Một người tiêu dùng ActiveMQ chậm khiến người tiêu dùng chậm chậm

Question

Tôi đang tìm kiếm trợ giúp về vấn đề lạ khi người tiêu dùng chậm trên hàng đợi khiến tất cả những người tiêu dùng khác trên cùng một hàng đợi bắt đầu sử dụng tin nhắn ở khoảng thời gian 30 giây. Đó là tất cả người tiêu dùng nhưng người chậm không tin nhắn của người tiêu dùng nhanh như họ có thể, thay vào đó họ chờ đợi một số rào cản kỳ diệu 30s trước khi tiêu thụ.

Dòng chảy cơ bản của ứng dụng của tôi đi như thế này:

1. một số thông báo các nhà sản xuất diễn ra vào một hàng đợi duy nhất. Tin nhắn có thể có JMSXGroupIDs khác nhau
2. một số người tiêu dùng nghe tin nhắn trong đó hàng đợi đơn
3. như thực hành tiêu chuẩn JMSXGroupIDs được phân phối trên người tiêu dùng
4. tại một số điểm một trong những người tiêu dùng trở nên chậm chạp và không thể xử lý thông điệp rất nhanh chóng
5. người tiêu dùng chậm sẽ điền bộ đệm tìm nạp trước vào nhà môi giới và AMQ nhận ra rằng nó chậm (hành vi mặc định)
6. tại thời điểm đó - hoặc một số 'ngẫu nhiên' nhưng thời gian sau đó - tất cả người tiêu dùng ngoại trừ chậm một người bắt đầu chỉ tiêu thụ tin nhắn trong cùng khoảng thời gian 30 giây
7. nếu người tiêu dùng chậm trở nên nhanh chóng trở lại sau đó mọi thứ rất nhanh chóng trở lại hoạt động bình thường và các rào cản độ tuổi 30 sẽ biến mất

Tôi đang ở một mất mát cho những gì có thể gây ra vấn đề này, hoặc làm thế nào để sửa chữa nó, xin vui lòng Cứu giúp.

More nền và phát hiện

• tôi đã quản lý để chắc chắn tạo lại vấn đề này trên AMQ 5.8.0, 5.9.0 (nơi vấn đề này ban đầu được chú ý) và 5.9.1, vào cài đặt tươi và các cài đặt hiện có được quản lý bởi ops và trên các máy khác nhau một số vm và một số thì không. Tất cả các cài đặt Linux, các hệ điều hành và phiên bản java khác nhau.
• Nó dường như không bị ảnh hưởng bởi bất kỳ tìm nạp trước nào có liên quan, đó là: thay đổi giá trị tìm nạp trước từ 1 đến 10 đến 1000 đã không dừng sự cố xảy ra
• [red herring?] Bật nhật ký gỡ lỗi trên ví dụ amq hiển thị nhật ký liên quan đến việc kiểm tra định kỳ các thư có thể hết hạn. Hàng đợi không có một chính sách hết hạn vì vậy tôi chỉ có thể nghĩ rằng thời gian theo lịch trình expireMessagesPeriod chỉ là đánh thức amq lên theo cách mà sau đó nó sẽ gửi tin nhắn đến người tiêu dùng không chậm.
• Nếu chế độ 30 giây được nhập rồi sang trái rồi nhập lại, thời gian giây phút qua luôn giống nhau, ví dụ: 14 và 44 đã qua phút. Điều này là đúng trên tất cả người tiêu dùng và tất cả các máy lưu trữ những người tiêu dùng. Những rào cản này thay đổi sau khi khởi động lại amq.

Answer 1

Mặc dù không hoàn toàn là giải pháp cho vấn đề, việc điều tra thêm đã phát hiện ra nguyên nhân gốc rễ của vấn đề này.

TL; DR - Nó được biết đến hành vi và sẽ không được cố định trước khi Apollo

Xem chi tiết

Cuối cùng này là do maxPageSize tài sản và thực tế là AMQ sẽ chỉ áp dụng lựa chọn tiêu chí cho thư trong bộ nhớ. Nói chung đây là những bộ chọn tin nhắn (property = value), nhưng trong trường hợp của tôi, chúng là JMSXGroupID=>Consumer bài tập.

Khi thư được nhận bởi hàng đợi, chúng sẽ được phân trang vào bộ nhớ và được đặt vào bộ sưu tập (có tên là pagedInPendingDispatch trong nguồn). Để gửi tin nhắn AMQ sẽ quét qua danh sách tin nhắn này và cố gắng tìm một người tiêu dùng sẽ chấp nhận nó. Điều đó bao gồm kiểm tra id nhóm, bộ chọn tin nhắn và không gian bộ đệm prefetch. Đối với trường hợp sử dụng của chúng tôi, chúng tôi không sử dụng bộ chọn tin nhắn nhưng chúng tôi đang sử dụng các nhóm. Nếu không có người tiêu dùng nào có thể nhận được tin nhắn thì nó còn lại trong bộ sưu tập và sẽ được kiểm tra lại ở lần đánh dấu tiếp theo.

Để dừng bộ sưu tập pagedInPendingDispatch do ăn hết tất cả các tài nguyên có sẵn, có giới hạn được đề xuất cho kích thước của hàng đợi này được định cấu hình qua thuộc tính maxPageSize. Tài sản này không thực sự là tối đa, nó là một gợi ý về việc liệu, trong điều kiện bình thường, thư mới đến nên được phân trang trong bộ nhớ hoặc phân trang vào đĩa.

Với hai thông tin này và người tiêu dùng chậm, cuối cùng tất cả các tin nhắn trong bộ sưu tập pagedInPendingDispatch chỉ được tiêu thụ bởi người tiêu dùng chậm và do đó bộ sưu tập bị chặn hiệu quả và không có tin nhắn nào khác được gửi đi. Điều này giải thích lý do tại sao người tiêu dùng chậm không bị ảnh hưởng bởi khoảng thời gian 30 giây, nó đã có maxPageSize tin nhắn đang chờ giao hàng.

Điều này không giải thích lý do tại sao tôi thấy người tiêu dùng không chậm nhận được tin nhắn cứ sau 30 giây. Khi nó quay ra, nhắn tin nhắn tin vào bộ nhớ có hai chế độ, bình thường và buộc phải. Bình thường sau quá trình được nêu ở trên, nơi kích thước của bộ sưu tập được so sánh với thuộc tính maxPageSize, khi bị buộc, tuy nhiên, thư luôn được phân trang vào bộ nhớ. Chế độ này tồn tại để cho phép bạn duyệt qua các thư không có trong bộ nhớ. Khi nó xảy ra chế độ cưỡng bức này cũng được sử dụng bởi cơ chế hết hạn để cho phép AMQ hết hạn các thư không có trong bộ nhớ. Vì vậy, những gì chúng tôi có bây giờ là một bộ sưu tập các tin nhắn trong bộ nhớ được tất cả các mục tiêu để gửi đến cùng một người tiêu dùng, một người tiêu dùng sẽ không chấp nhận chúng bởi vì nó là chậm hoặc bị chặn. Chúng tôi cũng có một thông báo tồn đọng đang chờ giao hàng cho tất cả người tiêu dùng. Mỗi expireMessagesPeriod mili giây một nhiệm vụ chạy các trang lực lượng thông báo vào bộ nhớ để kiểm tra xem họ có nên hết hạn hay không. Thao tác này sẽ thêm các thông báo đó vào các trang trong bộ sưu tập hiện có chứa thông báo maxPageSize cho người tiêu dùng chậm và N nhiều thông điệp hơn dành cho bất kỳ người tiêu dùng nào. Những tin nhắn đó được gửi đi.

QED.

Tài liệu tham khảo

• Ticket referring to this issue but for message selectors instead
• Docs relating to the configuration properties
• Somebody else with this issue but for selectors