Java7“Solr / Lucene”버그는 얼마나 심각한가요?

Java7“Solr / Lucene”버그는 얼마나 심각한가요?

---

분명히 Java7에는 루프 최적화와 관련된 몇 가지 불쾌한 버그가 있습니다. Google 검색 .

보고서와 버그 설명에서이 버그가 얼마나 중요한지 판단하기 어렵다는 것을 알았습니다 (Solr 또는 Lucene을 사용하지 않는 한).

내가 알고 싶은 것 :

• 내 (모든) 프로그램이 영향을받을 가능성은 얼마나됩니까?
• 버그가 일반 테스트에서 잡을만큼 결정적입니까?

참고 : 내 프로그램의 사용자가 -XX:-UseLoopPredicate문제를 피하기 위해 사용 하도록 할 수는 없습니다 .

---

핫스팟 버그의 문제점은 컴파일 임계 값 (예 : 10000)에 도달해야 얻을 수 있다는 것입니다. 따라서 단위 테스트가 "사소한"경우 잡을 수 없을 것입니다.

예를 들어,이 특정 테스트는 20,000 개의 문서 색인을 생성하기 때문에 lucene에서 잘못된 결과 문제를 발견했습니다.

우리의 테스트에서 우리는 다른 인터페이스 (예 : 다른 디렉토리 구현)와 인덱싱 매개 변수 등을 무작위 화하고 테스트는 1 %의 시간 동안 만 실패합니다. 물론 동일한 무작위 시드로 재현 할 수 있습니다. 또한 테스트가 생성하는 모든 인덱스에 대해 checkindex를 실행하여 인덱스가 손상되지 않았는지 확인하기 위해 일부 온 전성 테스트를 수행합니다.

발견 한 테스트의 경우 특정 구성이있는 경우 : 예 : RAMDirectory + PulsingCodec + 필드에 저장된 페이로드가 컴파일 임계 값에 도달 한 후 게시에 대한 열거 루프가 잘못된 계산을 반환합니다.이 경우에는 반환 된 문서 수 용어에 대해! = 용어에 대해 저장된 docFreq.

우리는 많은 스트레스 테스트를 가지고 있으며,이 테스트의 정상적인 어설 션이 실제로 통과한다는 점을 주목하는 것이 중요합니다. 실패한 끝에 체크 인덱스 부분이 있습니다.

이것의 가장 큰 문제는 lucene의 증분 인덱싱이 기본적으로 여러 세그먼트를 하나로 병합하여 작동한다는 것입니다.이 때문에 이러한 열거 형이 유효하지 않은 데이터를 계산하면이 유효하지 않은 데이터가 새로 병합 된 인덱스, 즉 손상에 저장 됩니다.

나는이 버그가 이전의 루프 옵티 마이저 핫스팟 버그 (예 : sign-flip stuff, https://issues.apache.org/jira/browse/LUCENE-2975 ) 보다 훨씬 더 은밀하다고 말하고 싶습니다 . 이 경우 우리는 쉽게 잡을 수있는 이상한 음의 문서 델타를 얻었습니다. 우리는 또한 그것을 피하기 위해 하나의 방법을 수동으로 펼쳤습니다. 반면에 우리가 처음에 수행 한 유일한 "테스트"는 http://www.pangaea.de/ 의 거대한 10GB 인덱스 였기 때문에이 버그로 범위를 좁히는 것이 고통 스러웠습니다.

이 경우, 버그를 피하고 손상된 인덱스가 생성 될 가능성이 없도록 여러 가지를 수동으로 언 롤링 / 인라인하는 데 상당한 시간 (예 : 지난주 매일 밤)을 보냈습니다. 일부 케이스를 피할 수는 있었지만 할 수없는 케이스가 더 많았습니다. 테스트에서이 항목을 트리거 할 수 있다면 더 많은 케이스가있을 것입니다 ...

---

버그를 재현하는 간단한 방법. Eclipse (내 경우에는 Indigo)를 열고 도움말 / 검색으로 이동합니다. 검색 문자열을 입력하면 Eclipse가 충돌하는 것을 알 수 있습니다. 로그를보십시오.

# 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:

---

문제는 2012 년 12 월 2 일부터 Oracle JDK java -version java 버전 "1.7.0_09"Java (TM) SE 런타임 환경 (빌드 1.7.0_09-b05) Java HotSpot (TM) 64 비트 서버 VM 모두에 여전히 존재합니다. (빌드 23.5-b02, 혼합 모드) 및 openjdk Java 버전 "1.7.0_09-icedtea"OpenJDK 런타임 환경 (fedora-2.3.3.fc17.1-x86_64) OpenJDK 64 비트 서버 VM (빌드 23.2-b09, 혼합 모드) )

-XX : -UseLoopPredicate 또는 -XX : LoopUnrollLimit = 1 옵션 중 하나가 개별적으로 버그 발생을 방지하지만 함께 사용하면 JDK가 실패합니다 (예 : https://bugzilla.redhat.com/show_bug.cgi?id=849279 참조).

---

2 년이 지난 지금도이 버그 (또는 그 변형)가 OSX의 1.7.0_25-b15에 여전히 존재한다고 생각합니다.

매우 고통스러운 시행 착오를 통해 Solr 3.6.2 및 자동 커밋과 함께 Java 1.7을 사용 <maxTime>30000</maxTime>하면 인덱스 손상이 발생하는 것으로 확인되었습니다. 1.7과 maxTime30000 에서만 발생하는 것 같습니다. Java 1.6으로 전환해도 문제가 없습니다. maxTime3000으로 낮추면 문제가 없습니다.

JVM은 충돌하지 않지만 Ruby에서 https://gist.github.com/armhold/6354416 스택 추적과 함께 RSolr가 종료됩니다 . 수백 개의 레코드를 저장 한 후 안정적으로 수행합니다.

여기에 관련된 많은 레이어 (Ruby, Sunspot, Rsolr 등)를 감안할 때 이것을 JVM 버그를 확실하게 증명하는 것으로 요약 할 수 있을지 모르겠지만 여기에서 일어나고있는 것처럼 느껴집니다. FWIW 또한 JDK 1.7.0_04를 시도했지만 문제가 있습니다.

---

As I understand it, this bug is only found in the server jvm. If you run your program on the client jvm, you are in the clear. If you run your program on the server jvm it depends on the program how serious the problem can be.

참고URL : https://stackoverflow.com/questions/6894104/how-serious-is-the-java7-solr-lucene-bug