2012-02-21 31 views
5

Tôi đang sử dụng slf4j trên nhật ký. Đôi khi nhật ký không in theo thứ tự (dấu thời gian). Chúng tôi có thể buộc đăng nhập theo thứ tự như mã đang chạy không?buộc slf4j in các bản ghi theo thứ tự

Cập nhật 1: Điều này xảy ra khi chạy thử nghiệm đơn vị trên Jenkins thông qua maven. Nó đang xảy ra một cách nhất quán. Các câu lệnh log đầu tiên từ mã đang đến sau đó các câu lệnh log từ kiểm thử đơn vị đang đến.

Ngoài ra tất cả các tệp logback trông bình thường như bên dưới.

<appender name="STDOUT" 
      class="ch.qos.logback.core.ConsoleAppender"> 
    <layout class="ch.qos.logback.classic.PatternLayout"> 

Cập nhật 2: các đoạn ghi là như thế này (tôi đã chỉnh sửa tên file vv ..). Trong quá trình thực hiện test1, chúng tôi gọi mã để đảo ngược một giao dịch không thành công do một số lỗi. Nhưng điều lạ là ngoại lệ được in đầu tiên và sau đó các báo cáo nhật ký từ các phương pháp thử được in. Ngoài ra timestamps báo cáo log được như mong đợi nhưng thứ tự của chúng trong tập tin là khác nhau (14:33:34. đến trước 14:33:34.)

14:33:34.667 [869082[email protected]] [] WARN org.hibernate.ejb.Ejb3Configuration - hibernate.connection.autocommit = false break the EJB3 specification 
14:33:34.718 [[email protected]] [] WARN o.h.impl.SessionFactoryObjectFactory - InitialContext did not implement EventContext 
14:33:34.843 [[email protected]] [] DEBUG c.r.a.exception.ExceptionMapper - <3003> can't reverse transaction. [id=10000000100120014] 
. 
. 
. 
. 
. 
14:33:34.158 [main] [] DEBUG c.r.a.test - ========================= test0: finished. 
14:33:34.158 [main] [] DEBUG c.r.a.test - ========================= test1: started. 
. 
. 
. 
. 
14:33:34.449 [main] [] DEBUG c.r.a.test - reversing transaction, id=10000000100120014 
14:33:34.856 [main] [] DEBUG c.r.a.test - ========================= test2: started. 

Cập nhật 3: Dự án của chúng tôi sử dụng maven và có nhiều mô-đun. Chúng tôi có logback-test.xml trong thư mục src/test/resources.

Cấu trúc dự án là như thế này
codemodule/src/test/resources/logback-test.xml - mô-đun này sẽ được đóng gói trong tệp jar. Trường hợp kiểm tra gọi mã của mô-đun này.
parent/src/test/resources/logback-test.xml - đây là mô-đun chính bao gồm tất cả các tệp và gói jar khác của mô-đun khác vào cuộc chiến. Đây là nơi tôi có test case đang chạy và nó gọi trên code của module.

Tôi có báo cáo nhật ký trong cả mã trường hợp thử nghiệm và mã thực tế. Tôi đã kiểm tra rằng cả hai trường hợp thử nghiệm và mã đang sử dụng mẫu từ tệp logback của cha (mẫu trong mô hình mã hóa là khác nhau). Nó luôn in các bản ghi nhật ký của mã trước khi in nhật ký của các trường hợp thử nghiệm.

Ngoài ra, chúng tôi cũng không chạy thử nghiệm song song.
Concurrency config is parallel='none', perCoreThreadCount=true, threadCount=2, useUnlimitedThreads=false

Cập nhật 4: Tôi hiểu vấn đề. Chúng tôi đang thực hiện yêu cầu http không phải là cuộc gọi phương thức trực tiếp. Vì vậy, các trường hợp thử nghiệm đang chạy trong chuỗi main và mã thực tế đang chạy trong một chuỗi khác (Cảm ơn Sebbe).

Tôi hiểu việc buộc chuỗi đăng nhập có thể là hiệu suất truy cập nhưng đối với tính đầy đủ của câu hỏi, tôi sẽ hỏi thêm một câu hỏi.

Vì cả hai nhật ký sẽ chuyển sang ứng dụng đơn (STDOUT), tôi có thể buộc đăng nhập theo thứ tự dấu thời gian không?

+0

Bạn có nói rằng trong nhật ký của mình, bạn thấy thông báo dấu thời gian hỗn hợp (không phát triển?) Không bao giờ thấy hiện tượng như vậy. Bạn đang sử dụng ứng dụng nào? –

+0

@TomaszNurkiewicz Có, tôi đang sử dụng ch.qos.logback.core.ConsoleAppender – Reddy

+0

Bạn có sử dụng bất kỳ sự tương tranh nào không? Đó có thể là một nguyên nhân. Ngoài ra, bạn có thể cung cấp đoạn trích nhật ký – Fixpoint

Trả lời

2

Từ nhật ký của bạn, bạn có thể thấy bạn có ít nhất 2 chuỗi chạy: [email protected]main.

Bạn không thể kiểm soát thứ tự trong đó các chuỗi riêng biệt ghi sự kiện của họ vào cùng một đầu ra (có thể bạn có thể, nhưng đó sẽ là một ý tưởng tồi).

Từ chuỗi nhật ký của bạn [email protected] sẽ ghi quyền truy cập vào bảng điều khiển của bạn trước tiên. Trong khi viết thư cho nó, các sự kiện được ghi lại từ main. Sau khi phát hành [email protected] khóa, hãy main tải xuống và có thể xóa nhật ký của tệp đó thành tệp.

+0

Cảm ơn bạn Sebbe, đó có thể là vấn đề. Nhưng tôi vẫn cần phải kiểm tra lý do tại sao nó xảy ra một cách nhất quán và từ nơi mà '869082978 @ qtp-1587505558-0' đang đến. – Reddy

+0

Tôi gặp vấn đề tuy nhiên có một câu hỏi khác. Đã cập nhật (# 4) câu hỏi. – Reddy

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