Spring Batch - Không phải tất cả hồ sơ đang được xử lý từ việc truy xuất MQ

Question

Tôi khá mới mẻ đối với Spring and Spring Batch, vì vậy hãy hỏi bất kỳ câu hỏi nào rõ ràng nếu bạn có bất kỳ câu hỏi nào.

Tôi đang gặp sự cố với Spring Batch mà tôi không thể tạo lại trong môi trường thử nghiệm hoặc môi trường địa phương của chúng tôi. Chúng tôi có một công việc hàng ngày kết nối với Websphere MQ thông qua JMS và truy xuất một tập hợp các bản ghi. Công việc này sử dụng JMS ItemReader ngoài hộp. Chúng tôi thực hiện ItemProcessor của riêng mình, nhưng nó không làm bất cứ điều gì đặc biệt khác ngoài việc đăng nhập. Không có bộ lọc hoặc quá trình xử lý nào ảnh hưởng đến bản ghi đến.

Vấn đề là trong số hơn 10.000 bản ghi hàng ngày trên MQ, chỉ khoảng 700 hoặc hơn (số chính xác là khác nhau mỗi lần) thường được đăng nhập vào ItemProcessor. Tất cả các bản ghi được kéo thành công khỏi hàng đợi. Số lượng bản ghi được ghi lại khác nhau mỗi lần và dường như không có mẫu. Bằng cách so sánh các tệp nhật ký với danh sách các bản ghi trong MQ, chúng ta có thể thấy rằng một tập hợp con dường như ngẫu nhiên các bản ghi đang được "xử lý" bởi công việc của chúng tôi. Bản ghi đầu tiên có thể được chọn, sau đó 50 được bỏ qua, sau đó 5 liên tiếp, v.v. Và mô hình khác nhau mỗi khi công việc chạy. Không có ngoại lệ nào được ghi lại.

Khi chạy cùng một ứng dụng trong máy chủ cục bộ và thử nghiệm bằng cùng một tập dữ liệu, tất cả 10.000 bản ghi được truy xuất thành công và được ghi bởi ItemProcessor. Công việc chạy từ 20 đến 40 giây trong Sản xuất (cũng không phải không đổi), nhưng trong thử nghiệm và địa phương phải mất vài phút để hoàn thành (điều này rõ ràng là có ý nghĩa vì nó đang xử lý nhiều bản ghi hơn).

Vì vậy, đây là một trong những vấn đề khó khắc phục sự cố vì chúng tôi không thể tạo lại. Một ý tưởng là triển khai ItemReader của riêng chúng ta và thêm ghi nhật ký để chúng ta có thể xem các bản ghi bị mất trước trình đọc hay sau trình đọc - tất cả những gì chúng ta biết bây giờ là chỉ một tập con của các bản ghi đang được xử lý bởi ItemProcessor. Nhưng ngay cả điều đó sẽ không giải quyết được vấn đề của chúng ta, và nó sẽ có phần kịp thời để thực hiện xem xét nó thậm chí không phải là một giải pháp.

Có ai khác đã gặp sự cố như thế này không? Bất kỳ ý tưởng hoặc đề xuất khắc phục sự cố nào có thể sẽ được đánh giá cao. Dưới đây là một số số phiên bản jar mà chúng tôi đang sử dụng để tham khảo.

• mùa xuân - 3.0.5.RELEASE
• Xuân Integration - 2.0.3.RELEASE
• mùa xuân hàng loạt - 2.1.7.RELEASE
• tích cực MQ - 5.4.2
• Websphere MQ - 7.0.1

Cảm ơn bạn đã nhập trước.

EDIT: Theo yêu cầu, mã cho bộ vi xử lý:

public SMSReminderRow process(Message message) throws Exception { 

    SMSReminderRow retVal = new SMSReminderRow(); 
    LOGGER.debug("Converting JMS Message to ClaimNotification"); 
    ClaimNotification notification = createClaimNotificationFromMessage(message); 

    retVal.setShortCode(BatchCommonUtils 
      .parseShortCodeFromCorpEntCode(notification.getCorpEntCode())); 
    retVal.setUuid(UUID.randomUUID().toString()); 
    retVal.setPhoneNumber(notification.getPhoneNumber()); 
    retVal.setMessageType(EventCode.SMS_CLAIMS_NOTIFY.toString()); 

    DCRContent content = tsContentHelper.getTSContent(Calendar 
      .getInstance().getTime(), 
      BatchCommonConstants.TS_TAG_CLAIMS_NOTIFY, 
      BatchCommonConstants.TS_TAG_SMSTEXT_TYP); 

    String claimsNotificationMessage = formatMessageToSend(content.getContent(), 
      notification.getCorpEntCode()); 

    retVal.setMessageToSend(claimsNotificationMessage); 
    retVal.setDateTimeToSend(TimeUtils 
      .getGMTDateTimeStringForDate(new Date())); 

    LOGGER.debug(
      "Finished processing claim notification for {}. Writing row to file.", 
      notification.getPhoneNumber()); 
    return retVal; 
} 

JMS config:

<?xml version="1.0" encoding="UTF-8"?> 
<beans xmlns="http://www.springframework.org/schema/beans" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xmlns:context="http://www.springframework.org/schema/context" 
xmlns:tx="http://www.springframework.org/schema/tx" 
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd 
    http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd 
    http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx.xsd"> 
<bean id="claimsQueueConnectionFactory" class="org.springframework.jndi.JndiObjectFactoryBean"> 
    <property name="jndiName" value="jms/SMSClaimNotificationCF" /> 
    <property name="lookupOnStartup" value="true" /> 
    <property name="cache" value="true" /> 
    <property name="proxyInterface" value="javax.jms.ConnectionFactory" /> 
</bean> 

<bean id="jmsDestinationResolver" 
    class="org.springframework.jms.support.destination.DynamicDestinationResolver"> 
</bean> 

<bean id="jmsJndiDestResolver" 
    class=" org.springframework.jms.support.destination.JndiDestinationResolver"/> 

<bean id="claimsJmsTemplate" class="org.springframework.jms.core.JmsTemplate"> 
    <property name="connectionFactory" ref="claimsQueueConnectionFactory" /> 
    <property name="defaultDestinationName" value="jms/SMSClaimNotificationQueue" /> 
    <property name="destinationResolver" ref="jmsJndiDestResolver" /> 
    <property name="pubSubDomain"> 
     <value>false</value> 
    </property> 
    <property name="receiveTimeout"> 
     <value>20000</value> 
    </property> 
</bean> 

Answer 1

Xem http://activemq.apache.org/jmstemplate-gotchas.html.

Có vấn đề khi sử dụng JMSTemplate. Tôi chỉ gặp phải những vấn đề này khi tôi nâng cấp phần cứng của mình và đột nhiên tiếp xúc với tình trạng cuộc đua đã tồn tại từ trước.

Biểu mẫu ngắn gọn là do thiết kế và ý định mẫu JMS mở và đóng kết nối trên mọi invocaton. Nó sẽ không thấy thông báo cũ hơn quá trình tạo. Trong các kịch bản có khối lượng lớn và/hoặc thông lượng cao, nó sẽ không đọc được một số tin nhắn.

Answer 2

Như một quy luật, MQ sẽ KHÔNG bị mất thông điệp khi cấu hình đúng. Câu hỏi sau đó là "cấu hình đúng" trông như thế nào?

Thông thường, thư bị mất là do GET không tồn tại hoặc không giao dịch.

Nếu các thư không liên tục đang truyền qua các kênh QMgr-tới-QMgr và NPMSPEED(FAST) được đặt thì MQ sẽ không ghi lại các lỗi nếu chúng bị mất. Đó là những gì các tùy chọn được dự định sẽ được sử dụng vì vậy không có lỗi dự kiến.

Khắc phục: Đặt NPMSPEED(NORMAL) trên kênh QMgr-to-QMgr hoặc làm cho các thư liên tục.

Nếu khách hàng đang nhận tin nhắn bên ngoài điểm đồng bộ hóa, tin nhắn có thể bị mất. Điều này là không có gì để làm với MQ cụ thể, nó chỉ là cách nhắn tin nói chung hoạt động. Nếu bạn yêu cầu MQ nhận một thông báo hủy bỏ khỏi hàng đợi và nó không thể truyền thông điệp đó đến ứng dụng từ xa thì cách duy nhất để MQ cuộn nó trở lại là nếu thông điệp được truy xuất dưới điểm đồng bộ.

Khắc phục: Sử dụng phiên được giao dịch.

Có một số ghi chú bổ sung, được sinh ra từ kinh nghiệm.

• Mọi người thề rằng sự kiên trì tin nhắn được đặt theo ý của họ. Nhưng khi tôi dừng ứng dụng và kiểm tra thư theo cách thủ công, rất thường là không những gì được mong đợi. Thật dễ dàng để xác minh vì vậy đừng giả sử.
• Nếu một thư được cuộn lại trên hàng đợi, nó sẽ không xảy ra cho đến khi MQ hoặc TCP lần ra khỏi kênh mồ côi Điều này có thể lên đến 2 giờ để điều chỉnh parms kênh và TCP Keepalive để giảm điều đó.
• Kiểm tra nhật ký lỗi của MQ (các bản ghi tại QMgr không phải là ứng dụng khách) để tìm kiếm thông báo về các giao dịch quay lại.
• Nếu bạn vẫn không thể xác định vị trí của thư, hãy thử truy tìm bằng SupportPac MA0W. Theo dõi này chạy dưới dạng lối ra và nó là cực kỳ có thể định cấu hình. Bạn có thể theo dõi tất cả các hoạt động GET trên một hàng đợi duy nhất và chỉ có hàng đợi đó. Đầu ra ở dạng người có thể đọc được.