분명히 Java7에는 루프 최적화에 관한 몇 가지 불쾌한 버그가 있습니다 : Google search.Java7 "Solr/Lucene"버그는 얼마나 심각한가요?
보고서 및 버그 설명에서 나는 Solr 또는 Lucene을 사용하지 않는 한이 버그의 중요성을 판단하기가 어렵습니다.
내가 알고 싶습니다 무엇 : 내 (모든) 프로그램이 영향을받는 것을 어떻게 가능성이
참고 : 내 프로그램의 사용자는 -XX:-UseLoopPredicate을 사용하여 문제를 피할 수 없습니다.
핫스팟 버그의 문제점은 컴파일 임계 값 (예 : 10000)에 도달해야 얻을 수 있다는 것입니다. 따라서 단위 테스트가 "사소한"것이라면 아마 잡히지 않을 것입니다.
예를 들어,이 특정 테스트는 20,000 개의 문서 색인을 생성하기 때문에 lucene에서 잘못된 결과 문제를 발견했습니다.
우리의 테스트에서 서로 다른 인터페이스 (예 : 다른 디렉토리 구현) 및 색인화 매개 변수 등을 무작위로 추출 했으므로 테스트는 1 %의 시간 만 실패합니다. 물론 동일한 임의의 시드로 재현 할 수 있습니다. 테스트가 생성하는 모든 인덱스에 대해 checkindex를 실행합니다. 인덱스는 인덱스가 손상되지 않았는지 확인하기 위해 몇 가지 테스트를 수행합니다.
특정 구성이있는 경우 Google에서 테스트했습니다. RAMDirectory + PulsingCodec + 페이로드가 필드에 저장된 경우 컴파일 임계 값에 도달 한 후 게시물에 대한 열거 루프가 잘못된 계산을 반환합니다.이 경우에는 용어에 대해 반환되는 문서 수! = 해당 용어에 대해 저장된 docFreq입니다.
우리는 많은 수의 스트레스 테스트를 수행하며,이 테스트에서 정상적인 어설 션을 기록하는 것이 중요합니다. 즉, 실패한 끝에있는 checkindex 부분입니다.
이 가진 큰 문제, 즉 루씬의 증분 색인은 근본적으로 하나에 여러 개의 세그먼트를 병합하여 작동합니다 열거의 잘못된 데이터를 계산하는 경우,이 유효하지 않은 데이터는 다음 인이의 때문에 새로 합병 색인에 저장 : 일명 부패.
나는이 버그가 이전 루프 최적화 프로그램의 핫스팟 버그 (예 : sign-flip stuff, https://issues.apache.org/jira/browse/LUCENE-2975)보다 훨씬 더 위선적이라고 말하고 싶습니다. 이 경우 우리는 쉽게 잡을 수있는 엉뚱한 부정적인 문서 델타를 얻었습니다. 우리는 또한 그것을 피하기 위해 수동으로 하나의 방법을 언 롤해야했습니다. 반면에 처음에 우리가 가진 유일한 "테스트"는 http://www.pangaea.de/이라는 거대한 10GB 인덱스 였으므로이 버그를 좁히는 것은 힘들었습니다.
이 경우에는 여러 가지를 수동으로 언롤/인라인하는 등 많은 시간을 (예 : 매일 밤) 보냈습니다. 버그를 피할 수 있고 손상된 색인의 가능성이 없도록 몇 가지 해결 방법을 만들려고했습니다. 창조되고있다. 몇 가지 사례를 피할 수는 있지만 더 많은 경우가있었습니다 ... 테스트에서이 문제를 일으킬 수 있다면 더 많은 사례가있을 수 있습니다.
재현하는 간단한 방법 벌레. 오픈 일식 (필자의 경우 인디고) 및 도움말/검색으로 이동하십시오. 검색 문자열을 입력하면 일식이 충돌한다는 것을 알 수 있습니다. 로그를보십시오.
# 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:
Robert가 설명한 것과 동일합니까? – OscarRyz
아니요, Narayan은 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7070134에 대해 설명합니다. 그 중 하나는 lucene에 영향을 미치는 java7의 버그 (포터 줄기를 사용하면 JRE가 충돌하기 때문입니다.)하지만 충돌이 발생하기 때문에 색인 크래시가 발생하지 않으므로 가장 심각하지는 않습니다. –
이 버그는 서버 jvm에서만 발견됩니다. 클라이언트 jvm에서 프로그램을 실행하면 명확합니다. 서버 jvm에서 프로그램을 실행하면 프로그램에 따라 문제가 얼마나 심각한 지에 따라 다릅니다.
이것은 오해의 소지가 있습니다. 내 컴퓨터에서 - 클라이언트는 Java 7과 아무런 관계가 없으며 모든 버그가 여전히 발생합니다. –
문제는 여전히 년 12 월 2 일 모두 오라클 JDK 자바 -version 자바 버전 "1.7.0_09" 자바 (TM) SE 런타임 환경 (빌드 1.7.0_09-B05) 자바에서 2012 의로 존재 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 : LoopU nrollLimit = 1 옵션을 사용하면 버그가 발생하지 않습니다. 하지만 함께 사용하면 JDK가 실패합니다. 예 : https://bugzilla.redhat.com/show_bug.cgi?id=849279
글쎄 2 년 후이 버그 (또는 그 변형)가 여전히 OSX의 1.7.0_25-b15에 있다고 생각합니다.
매우 고통스러운 시행 착오를 통해 Solr 3.6.2 및 자동 커밋 <maxTime>30000</maxTime>에서 Java 1.7을 사용하면 인덱스 손상이 발생하는 것으로 나타났습니다. w/1.7 및 maxTime이 30000에서 발생하는 것으로 보입니다. Java 1.6으로 전환하면 문제가 없습니다. maxTime을 3000으로 낮추면 문제가 없습니다.
JVM이 충돌하지 않지만 Ruby에서 RSolr이 다음 스택 추적으로 인해 종료됩니다 : https://gist.github.com/armhold/6354416. 이것은 수백 개의 레코드를 저장 한 후이를 안정적으로 수행합니다.
많은 계층 (Ruby, Sunspot, Rsolr 등)이 있기 때문에 JVM 버그를 확실하게 증명할 수있는 것으로 확신 할 수는 없지만 실제로 여기에있는 것처럼 느껴집니다. FWIW JDK 1.7.0_04도 시험해 보았습니다. 또한 문제가 있습니다.
직선 소스에서. +1 – aroth
감사합니다. 그런데 여러 가지 의견을 보았습니다. '잘못된 결과'를 발견 한 테스트 설정은 6 월 30 일에 커밋되었습니다 (https://issues.apache.org/jira/browse/LUCENE- 3264), Java 7 릴리스의 타임 스탬프는 실제로 6 월 27 일입니다 (http://blog.thetaphi.de/2011/07/real-story-behind-java-7ga-bugs.html). 어쨌든 5 월 13 일부터 버그가 oracle에 공개되었습니다 (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7044738). –
상세한 직접적인 답변을 해주신 Robert 께 감사드립니다. 이것은 재앙입니다 : 현재 프로젝트는 많은 암호화와 암호화 해시를 사용합니다. 배열에 대한 수백만 개의 반복 내가 처리 할 수있는 충돌,하지만 잘못 암호화 된 파일이나 해시가 끔찍한 결과와 함께 트랙 아래로 분명 년 될 수 있습니다. – Carsten