Hàng đợi JMS đầy đủ

Question

Ứng dụng Java EE của tôi gửi JMS đến hàng đợi liên tục, nhưng đôi khi ứng dụng người tiêu dùng JMS đã ngừng nhận JMS. Nó gây ra hàng đợi JMS rất lớn thậm chí đầy đủ, làm sụp đổ máy chủ. Máy chủ của tôi là JBoss hoặc Websphere. Các máy chủ ứng dụng có cung cấp chiến lược để xóa các tin nhắn JMS "hết giờ" không?

Chiến lược xử lý hàng đợi JMS lớn là gì? Cảm ơn!

Answer 1

Với bất kỳ tin nhắn không đồng bộ nào, bạn phải xử lý vấn đề "nhà sản xuất nhanh/người tiêu dùng chậm". Có một số cách để giải quyết vấn đề này.

1. Thêm người tiêu dùng. Với WebSphere MQ, bạn có thể kích hoạt một hàng đợi dựa trên độ sâu. Một số cửa hàng sử dụng điều này để thêm các trường hợp người tiêu dùng mới khi chiều sâu hàng đợi tăng lên. Sau đó, khi độ sâu hàng đợi bắt đầu giảm, người tiêu dùng thêm sẽ chết. Bằng cách này, người tiêu dùng có thể được thực hiện để tự động mở rộng quy mô để phù hợp với tải thay đổi. Các công ty môi giới khác thường có chức năng tương tự.
2. Tạo hàng đợi và hệ thống tệp cơ bản thực sự lớn. Phương pháp này cố gắng hấp thụ các đỉnh trong khối lượng công việc hoàn toàn trong hàng đợi. Đây là sau khi tất cả những gì xếp hàng được thiết kế để làm ở nơi đầu tiên. Vấn đề là, nó không quy mô tốt và bạn phải phân bổ đĩa mà 99% thời gian sẽ gần như trống rỗng.
3. Hết hạn các tin nhắn cũ. Nếu các tin nhắn có một tập hợp hết hạn thì bạn có thể làm cho chúng được dọn sạch. Một số nhà môi giới JMS sẽ tự động thực hiện việc này trong khi trên những người khác, bạn có thể cần phải duyệt hàng đợi để làm cho các thư đã hết hạn bị xóa. Vấn đề với điều này là không phải tất cả các tin nhắn đều mất giá trị kinh doanh của họ và đủ điều kiện hết hạn. Hầu hết các tin nhắn cháy và quên (nhật ký kiểm tra, v.v.) đều thuộc loại này.
4. Điều tiết lại nhà sản xuất. Khi hàng đợi được lấp đầy, không có gì có thể đặt tin nhắn mới vào nó. Trong WebSphere MQ, ứng dụng sản xuất sau đó nhận được một mã trả về cho biết hàng đợi đã đầy. Nếu ứng dụng phân biệt giữa các lỗi chết người và tạm thời, ứng dụng có thể dừng và thử lại.

Chìa khóa để triển khai thành công bất kỳ điều nào là hệ thống của bạn được phép cung cấp lỗi "mềm" mà ứng dụng sẽ phản hồi. Ví dụ: nhiều cửa hàng sẽ tăng tham số MAXDEPTH của hàng đợi trong lần đầu tiên họ nhận được điều kiện QFULL. Nếu độ sâu hàng đợi vượt quá kích thước của hệ thống tệp cơ bản thì kết quả là thay vì một lỗi "mềm" có tác động đến một hàng đợi mà hệ thống tệp lấp đầy và toàn bộ nút bị ảnh hưởng. Bạn đang MUCH tốt hơn điều chỉnh hệ thống để hàng đợi truy cập MAXDEPTH trước khi hệ thống tệp đầy nhưng sau đó cũng thiết bị ứng dụng hoặc các quy trình khác để phản ứng với hàng đợi đầy đủ theo một cách nào đó.

Nhưng dù bạn có làm gì khác, tùy chọn # 4 ở trên là bắt buộc. Không có vấn đề bao nhiêu đĩa bạn phân bổ hoặc bao nhiêu trường hợp người tiêu dùng bạn triển khai hoặc làm thế nào nhanh chóng bạn hết hạn tin nhắn luôn có khả năng là người tiêu dùng của bạn (s) sẽ không theo kịp với sản xuất tin nhắn. Khi điều này xảy ra, ứng dụng sản xuất của bạn sẽ tăng tốc trở lại hoặc tăng báo thức và dừng hoặc làm bất cứ điều gì khác ngoài việc treo hoặc chết. Nhắn tin không đồng bộ chỉ là không đồng bộ cho đến khi bạn hết dung lượng để xếp hàng các tin nhắn. Sau đó các ứng dụng của bạn được đồng bộ và phải xử lý một cách duyên dáng tình huống đó, ngay cả khi điều đó có nghĩa là (duyên dáng) tự đóng.

Answer 2

Chắc chắn!

http://download.oracle.com/docs/cd/E17802_01/products/products/jms/javadoc-102a/index.html Message#setJMSExpiration(long) thực hiện chính xác những gì bạn muốn.