커스터마이징된 hbase thriftserver에 batch increment 요청을 보내면 하루 5-6회 정도 java.lang.ArrayIndexOutOfBoundsException이 발생한다. tcpdump로 보면 region server가 응답 헤더(key-length/value-length/rowkey-length)를 잘못된 값으로 돌려주고 있다.
region server가 응답 헤더를 잘못 구성하는 정확한 코드 경로는 원본에서 최종 확정되지 않았고, Cloudera는 '재시도하지 않는' 애플리케이션 패치를 임시 조치로 언급했다. 이는 근본 수정이 아니라 증상 회피이므로, 이후 버전에서 정식 수정이 반영됐는지는 별도 확인이 필요하다.
높은 동시 부하(다수 스레드에서 짧은 시간에 반복되는 batch increment)에서 region server 응답 헤더가 손상되는 결함이며, 최종 패치 전까지는 애플리케이션에서 이 예외가 나는 batch increment 요청을 자동 재시도하지 않도록 처리하는 것이 임시 대응이다.
확인 수준: 추가 조사 해법 · 해당 케이스 적용 결과 미확인
적용 조건: <...>와 예시 DB·테이블·경로·수치는 실제 확인값으로 바꾼다. 명령과 메뉴는 참고 문서를 바탕으로 보강한 예시이며 대상 시스템에서 실행하지 않았다. 버전·원인에 따른 분기와 남은 확인 사항은 아래에 명시한다.
정상 헤더 예: 0000005d000000080048 (4byte key length / 4byte value length / 2byte rowkey length)
오류 헤더 예: 73732e30313531406465 (필드 경계가 깨진 값)
재현 조건을 좁힌다. 알려진 재현 패턴은 다음과 같다: 동일 요청에서 서로 다른 region으로 가는 여러 row key를 한 batch에 담고, 짧은 시간에 다수 스레드(재현 사례는 약 200 thread)로 동시에 increment batch 요청을 반복한다.
thriftserver·region server 로그와 tcpdump를 함께 수집해 오류 발생 시점의 요청·응답을 대조한다.
tcpdump -i '<iface>' host '<regionserver-ip>' and port 9090 -w thrift_capture.pcap
애플리케이션 레벨에서 이 예외가 발생한 batch increment 요청을 자동으로 재시도하지 않도록 예외 처리를 추가한다. 손상된 응답을 그대로 재시도하면 중복 increment가 발생할 수 있으므로, 재시도 대신 실패를 알리고 별도로 검증 후 재처리하는 절차를 둔다.
HDP 3.1 기준 hotfix 버전(케이스에서는 3.1.0.6-1)을 사용 중이었는지 확인하고, 이후 버전에서 근본 수정이 반영됐는지 릴리스 노트로 재확인한다.
동일한 부하 패턴(다수 스레드·다중 region 대상 batch increment)을 반복 재현해 예외 발생 빈도가 줄었는지, 애플리케이션이 예외 발생 시 중복 재시도 없이 안전하게 처리하는지 확인한다.