Lỗi Java7 "Solr/Lucene" nghiêm trọng như thế nào?

Question

Rõ ràng Java7 có một số lỗi khó chịu về tối ưu hóa vòng lặp: Google search.

Từ các báo cáo và mô tả lỗi, tôi thấy khó để đánh giá mức độ nghiêm trọng của lỗi này (trừ khi bạn sử dụng Solr hoặc Lucene).

Những gì tôi muốn biết:

• Làm thế nào có khả năng là nó mà tôi (bất kỳ) chương trình bị ảnh hưởng?
• Lỗi có đủ xác định để kiểm tra bình thường không?

Lưu ý: Tôi không thể khiến người dùng chương trình của mình sử dụng -XX:-UseLoopPredicate để tránh sự cố.

Answer 1

Vấn đề với bất kỳ lỗi điểm phát sóng nào là bạn cần đạt đến ngưỡng biên dịch (ví dụ: 10000) trước khi nó có thể giúp bạn: vì vậy nếu kiểm tra đơn vị của bạn là "tầm thường", có thể bạn sẽ không bắt được nó.

Ví dụ: chúng tôi gặp phải vấn đề về kết quả không chính xác một cách sáng suốt, vì thử nghiệm cụ thể này tạo 20.000 chỉ mục tài liệu. Trong các thử nghiệm của chúng tôi, chúng tôi ngẫu nhiên hóa các giao diện khác nhau (ví dụ: các triển khai thư mục khác nhau) và các tham số chỉ mục, và thử nghiệm chỉ thất bại 1% thời gian, sau đó có thể tái tạo với cùng một hạt giống ngẫu nhiên. Chúng tôi cũng chạy checkindex trên mọi chỉ mục để kiểm tra việc tạo, thực hiện một số kiểm tra sanity để đảm bảo chỉ mục không bị hỏng.

Đối với thử nghiệm chúng tôi đã tìm thấy, nếu bạn có cấu hình cụ thể: ví dụ: RAMDirectory + PulsingCodec + tải trọng được lưu trữ cho trường, sau khi nó đạt đến ngưỡng biên dịch, vòng lặp liệt kê trên các bài đăng trả về các phép tính không chính xác, trong trường hợp này là số lượng tài liệu trả về cho một thuật ngữ! = DocFreq được lưu trữ cho thuật ngữ.

Chúng tôi có một số lượng tốt các bài kiểm tra căng thẳng và điều quan trọng cần lưu ý là các xác nhận thông thường trong bài kiểm tra này thực sự trôi qua, phần kiểm tra ở phần cuối không thành công.

Vấn đề lớn với việc lập chỉ mục tăng dần của Lucene về cơ bản hoạt động bằng cách hợp nhất nhiều phân đoạn thành một: vì điều này, nếu những dữ liệu không hợp lệ này được tính được lưu trữ vào chỉ mục mới được hợp nhất: tham nhũng.

Tôi muốn nói lỗi này là lén lút hơn các lỗi điểm phát sóng tối ưu hóa vòng lặp trước mà chúng tôi đã nhấn (ví dụ: công cụ đăng nhập lật, https://issues.apache.org/jira/browse/LUCENE-2975). Trong trường hợp đó, chúng tôi đã có được các tài liệu tiêu cực bất thường, điều này giúp bạn dễ dàng nắm bắt. Chúng tôi cũng chỉ phải tự mở một phương thức duy nhất để né tránh nó. Mặt khác, "thử nghiệm" duy nhất mà chúng tôi ban đầu cho rằng đó là một chỉ số 10GB khổng lồ của http://www.pangaea.de/, do đó, thật khó để thu hẹp nó xuống lỗi này. Trong trường hợp này, tôi đã dành một số lượng thời gian (ví dụ như mỗi đêm tuần trước) cố gắng tự unroll/inline những thứ khác nhau, cố gắng để tạo một số workaround vì vậy chúng tôi có thể né tránh các lỗi và không có khả năng chỉ số tham nhũng đang được tạo. Tôi có thể né tránh một số trường hợp, nhưng có nhiều trường hợp tôi không thể ... và tôi chắc chắn rằng nếu chúng ta có thể kích hoạt công cụ này trong các thử nghiệm của chúng tôi có nhiều trường hợp hơn ...

Answer 2

Cách đơn giản để tái tạo con bọ. Mở nhật thực (Indigo trong trường hợp của tôi), và Đi tới Trợ giúp/Tìm kiếm. Nhập một chuỗi tìm kiếm, bạn sẽ thấy rằng nhật thực bị treo. Hãy xem nhật ký.

# Problematic frame: 
# J org.apache.lucene.analysis.PorterStemmer.stem([CII)Z 
# 
# Failed to write core dump. Minidumps are not enabled by default on client versions of Windows 
# 
# If you would like to submit a bug report, please visit: 
# http://bugreport.sun.com/bugreport/crash.jsp 
# 

--------------- T H R E A D --------------- 

Current thread (0x0000000007b79000): JavaThread "Worker-46" [_thread_in_Java, id=264, stack(0x000000000f380000,0x000000000f480000)] 

siginfo: ExceptionCode=0xc0000005, reading address 0x00000002f62bd80e 

Registers: 

Answer 3

Như tôi đã hiểu, lỗi này chỉ được tìm thấy trong máy chủ jvm. Nếu bạn chạy chương trình của bạn trên máy khách jvm, bạn đang ở trong tình trạng rõ ràng. Nếu bạn chạy chương trình của bạn trên máy chủ jvm nó phụ thuộc vào chương trình làm thế nào nghiêm trọng vấn đề có thể được.

Answer 4

Vấn đề, vẫn còn tồn tại như của 02 tháng mười hai năm 2012 trong cả Oracle JDK java -version phiên bản java "1.7.0_09" Java (TM) SE Runtime Environment (xây dựng 1.7.0_09-b05) Java HotSpot (TM) Máy chủ 64-Bit Server (xây dựng 23.5-b02, chế độ hỗn hợp) và openjdk phiên bản java "1.7.0_09-icedtea" Môi trường chạy OpenJDK (fedora-2.3.3.fc17.1-x86_64) OpenJDK Máy chủ 64-bit (xây dựng 23.2-b09, chế độ hỗn hợp)

Lạ là riêng lẻ bất kỳ -XX: -UseLoopPredicate hoặc -XX: LoopU nrollLimit = 1 tùy chọn ngăn chặn lỗi xảy ra, nhưng khi được sử dụng cùng nhau - JDK không thành công xem ví dụ https://bugzilla.redhat.com/show_bug.cgi?id=849279

Answer 5

Vâng hai năm sau đó và tôi tin rằng lỗi này (hoặc biến thể của nó) vẫn tồn tại trong 1,7.0_25-b15 trên OSX.

Thông qua thử nghiệm và lỗi rất đau đớn, tôi đã xác định rằng việc sử dụng Java 1.7 với Solr 3.6.2 và tự động <maxTime>30000</maxTime> dường như gây ra tham nhũng chỉ mục. Nó chỉ dường như xảy ra w/1.7 và maxTime ở 30000- nếu tôi chuyển sang Java 1.6, tôi không có vấn đề gì. Nếu tôi thấp hơn maxTime đến 3000, tôi không có vấn đề gì.

JVM không bị lỗi, nhưng nó khiến RSolr chết với dấu vết ngăn xếp sau trong Ruby: https://gist.github.com/armhold/6354416. Nó thực hiện điều này một cách đáng tin cậy sau khi lưu một vài trăm bản ghi.

Với nhiều lớp liên quan ở đây (Ruby, Sunspot, Rsolr, v.v.) Tôi không chắc chắn tôi có thể đun sôi điều này thành một cái gì đó chứng minh dứt khoát lỗi JVM, nhưng nó chắc chắn cảm thấy như đó là những gì đang xảy ra ở đây. FWIW Tôi cũng đã thử JDK 1.7.0_04, và nó cũng thể hiện vấn đề.