2013-09-05 51 views
7

Chúng tôi đang xây dựng một dự án tích hợp bằng cách sử dụng Apache Camel (Camel 2.10.3, Java DSL based).Làm cách nào để phát hiện kết nối JMS bị hỏng/khôi phục trong Apache Camel?

Chúng tôi có tuyến đường trích xuất dữ liệu từ cơ sở dữ liệu (cho phép gọi IN_DB), thực hiện một số logic và chèn vào cơ sở dữ liệu khác (OUT_DB) một lần một ngày và một tuyến khác đăng ký chủ đề JMS cho dữ liệu XML một số logic và chèn nó vào cùng một cơ sở dữ liệu (OUT_DB) trong suốt cả ngày.

Yêu cầu là khi kết nối chủ đề JMS bị hỏng vì bất kỳ lý do nào, chúng tôi tiếp tục kết nối lại vô thời hạn và khi kết nối lại thành công, chúng tôi cần quay lại cơ sở dữ liệu (IN_DB) và thực hiện một tải khác để điền vào khoảng cách mà chủ đề đã giảm.

Câu hỏi của tôi là làm thế nào chúng ta có thể làm logic này ('Tôi đã được kết nối sau đó tôi đã bị ngắt kết nối và bây giờ tôi được kết nối lại') trong Camel? Điều gì sẽ xảy ra với tuyến đường bắt đầu với người tiêu dùng chủ đề khi chủ đề đi xuống, tuyến đường sẽ dừng lại? Hoặc nó sẽ phát hành một thông báo lỗi cho một số hàng đợi lỗi? Tôi có phải viết trình xử lý của riêng mình để theo dõi kết nối chủ đề hay Camel sẽ tự động kết nối lại khi chủ đề quay lại và đặt tiêu đề thư hoặc đặt một số biến ngữ cảnh để cho biết rằng 'Tôi đã kết nối rồi tôi bị ngắt kết nối và bây giờ Tôi được kết nối lần nữa 'kịch bản đã xảy ra? Tôi hạnh phúc xây dựng logic tuyến đường xung quanh việc gọi tải cơ sở dữ liệu Tôi chỉ không thể tìm ra cách tốt nhất để 'phát hiện' trong Camel rằng kịch bản này đã xảy ra.

Mọi đề xuất được đánh giá cao.

Trả lời

1

Về mặt kết nối lại với hàng đợi của bạn, nó phụ thuộc vào nhà môi giới JMS bạn đang sử dụng. Nếu bạn đang sử dụng ActiveMQ thì bạn có thể cấu hình cách nó kết nối lại thông qua URI để nó có thể thử và kết nối lại với một nhà môi giới khác, kết nối lại với cùng một nhà môi giới sau một khoảng thời gian chờ vv Các tài liệu cho nó là here.

Để phát hiện khi kết nối không thành công, cách dễ nhất từ ​​quan điểm của chương trình là chỉ sử dụng hàng đợi liên tục thay vì chủ đề. Tuy nhiên, giả sử rằng không khả thi thì tôi nghĩ bạn có hai lựa chọn.

  1. Xác định JMS exception listener. Điều này sẽ cho bạn biết khi kết nối cơ bản đã biến mất.

Để phát hiện khi sao lưu lại, tôi nghĩ bạn đang mắc kẹt khi đăng tin nhắn cho một chủ đề cụ thể và xem tin nhắn từ chủ đề này ở một tuyến đường khác. Khi bạn đọc một thông điệp về chủ đề này, bạn biết người môi giới đã quay lại để bạn có thể tải lại dữ liệu của mình từ DB.

hoặc 2. Bạn có thể đăng các tin nhắn thông thường vào chủ đề JMS của mình. Nếu bạn ngừng nhận chúng, bạn biết người môi giới đã đi xuống. Một khi bạn bắt đầu để có được chúng một lần nữa, bạn biết nó là sao lưu và bạn cần phải tải lại dữ liệu từ DB.

+0

Cảm ơn Matt, một số đề xuất tuyệt vời tại đây. Thật không may, chúng tôi không sở hữu các chủ đề mà chúng tôi đang đăng ký (nhà môi giới Tibco EMS) và đang kết nối với các tài khoản chỉ đọc giúp cho phương pháp tiếp cận nhịp tim trở nên khó khăn một chút. Trường hợp ngoại lệ JMS sẽ được ném từ đâu? JMSComponent chính nó, hoặc các tuyến đường tiêu thụ từ nó? – Matt

+0

Bạn dường như có một chút khó khăn cho các tùy chọn! Tôi đã không có một ví dụ để bàn tay nhưng người nghe ngoại lệ được đăng ký trên kết nối vì vậy ngoại lệ nên được ném bởi kết nối hơn là từ một nơi nào đó trong tuyến đường. Lựa chọn duy nhất khác của bạn là truy vấn IN_DB thường xuyên để xem nó có bất kỳ thư nào mà bạn không biết nhưng tôi nghi ngờ điều đó không thực tế. –

Các vấn đề liên quan