quartz 오류 보고:java.lang.classNotFoundException

최근에 스케줄링 플랫폼 개조 프로젝트를 하고 있는데 quartz는 테스트 환경에서 단기 환경을 달리고 생산에 있어서 두 대의 서버를 집단으로 만든다.
테스트 환경은 ok입니다. 생산이 시작된 후에 오류를 보고합니다.lang.classNotFoundException
처음: 실패
코드에서 낡은 job 클래스에 대한 인용을 배제했습니다. (프로필과 클래스는 모두 배제되었습니다.)
서버가 이 종류를 캐시한 것으로 추정된다.
시도:
캐시를 지우고 서버를 재부팅해도 상기 오류가 발생합니다.
두 번째: 실패
운영 구성을 테스트 환경으로 끌어다 놓고 테스트를 반복하면 서버를 재부팅할 때 캐시가 자동으로 지워집니다.
quartz로 추정되는 그 종류는 전역 변수로 생산적으로 동기화될 것이다.
시도:
테스트 환경에 다시 스케줄러 서버를 구축하여 생산에서 설정과 실행을 모두 테스트 환경으로 끌어올리고 ok를 실행합니다
디버깅을 반복했지만 동기화 흔적을 발견하지 못했다.
생산상의 이상이 재현되지 않아 감히 출시할 수 없다.
세 번째: 실패
그렇다면 이 낡은job류는 도대체 어디에서 호출된 것입니까?실마리를 찾지 못하다!데이터베이스에 저장되는 거 아니야?
당시에는 이 생각이 웃겼는데, 디자인의 측면에서 볼 때 quartz는 다른 종류를 자신의 체계에 도입하는 것을 허락하지 않을 것이다.
하지만 갈 길도 없으니 데이터베이스에 저장되어 있는지 확인해 보세요.너는 그것이 데이터베이스 테이블에 원래 있던 것에 대해 알아맞혔다.

CREATE TABLE QRTZ_JOB_DETAILS(
JOB_NAME VARCHAR(200) NOT NULL,
JOB_GROUP VARCHAR(200) NOT NULL,
DESCRIPTION VARCHAR(250) NULL,
JOB_CLASS_NAME VARCHAR(250) NOT NULL,
IS_DURABLE VARCHAR(1) NOT NULL,
IS_VOLATILE VARCHAR(1) NOT NULL,
IS_STATEFUL VARCHAR(1) NOT NULL,
REQUESTS_RECOVERY VARCHAR(1) NOT NULL,
JOB_DATA BLOB NULL,
PRIMARY KEY (JOB_NAME,JOB_GROUP))
TYPE=InnoDB;

그래!이 필드를 보니 오래된 클래스가 맞습니다. 새로운 클래스가 아닙니다.
그렇다면 왜 테스트 환경에서 발견했을까요?
테스트 라이브러리에 들어가도 낡은 종류를 발견하지 못했어요. 그래요.
네 번째: 성공
다시 생산에 배치할 것인가, 아니면 잘못을 보고할 것인가: 종류를 찾을 수 없다.
문제가 데이터베이스에 있는지 확인했습니다. 저는 Quartz의 시계를 한 장 한 장 찾았지만 이 기록을 찾지 못했습니다. 그러면 입고 작성부터 시작해서 Quartz의 코드를 찾아봤는데job_detail 테이블에 필드가 있습니다job_데이터, 그 유형은blob입니다. 여기에 존재하지 않을까요?
확실히, 이blob를 열어 볼 수 있습니다. 데이터는 여기에 있습니다.
이것 괜찮아요. 다른blob 필드에 오래된 job 클래스가 저장되어 있는지 다시 한 번 확인해 보니triggers표에도 필드job_데이터, 이로써 문제가 발견되었습니다.그런데 어떻게 해결할까요?blob 형식의 데이터는 업데이트를 통해 직접 실행할 수 없습니다. 인코딩 요소를 고려하여 밑천을 뽑아 클래스를 이전의 클래스로 재구성해야 합니다.
이번 경험을 보면 낡은 프로젝트가 과연 구렁텅이인지 나는 멍하니 빠져들었다.
결론:
컴퓨터는 이성적인 것이기 때문에 모든 것이 가능하다. 가장 불가능한 일이라도 일일이 확인해야 한다.문제를 찾을 때 모든 고장이 발생할 가능성을 가장 잘 알고 싶다. 그리고 최종적인 문제를 찾을 때까지 하나하나 배제한다.
웹 개발에 있어 이런 문제를 해결하는 일반적인 사고방식은 다음과 같다.
1. 전체적인 측면에서 볼 때 응용 프로그램, 캐시, 데이터베이스는 3대 독립 모듈로 이런 부분에서 이상이 발생할 수 있으므로 먼저 응용 프로그램 자체의 이상을 조사해야 한다(이 확률이 가장 크다).그 다음은 캐시(동기화) 모듈 배열이다.마지막으로 데이터베이스 모듈 배열입니다.
2. 전체 국면이 확정된 전제에서 상술한 모듈을 세분화하여 발생할 수 있는 문제를 일일이 열거한다.
3. 손을 대어 생각을 검증한다.좋은 개발자에게 손대는 것은 검증의 수단일 뿐이고 사고방식이야말로 가장 중요하다.