11월 24일 SEOTcs 시스템이 SEO 채점 알고리즘을 업데이트한 이후로 Java 데이터 작업 실행 중에 다음과 같은 오류가 종종 보고됩니다.
"2011-12-03 18:00:32 DefaultHttpClient [INFO] 요청 처리 시 I/O 예외(java.net.SocketException)가 발생했습니다. 피어에 의한 연결 재설정: 소켓 쓰기 오류
2011-12-03 18:00:32 DefaultHttpClient [INFO] 요청 재시도 중”…
이를 위해 중국어와 영어로 된 몇몇 웹사이트를 검색해 보았는데, 이런 상황이 발생하는 이유를 알아냈습니다. 이 Java 예외는 클라이언트 측과 서버 측 모두에서 발생할 수 있습니다. 두 가지 이유:
1. 한쪽 끝의 소켓이 닫히면(또는 적극적으로 닫히거나 비정상적인 종료로 인해 닫히면) 다른 쪽 끝은 여전히 데이터를 보내고 전송된 첫 번째 데이터 패킷이 이 예외를 트리거합니다(피어에 의한 연결 재설정).
2. 한쪽 끝이 종료되지만 종료 시 연결이 닫히지 않습니다. 다른 쪽 끝이 연결에서 데이터를 읽는 경우 예외(연결 재설정)가 발생합니다. 간단히 말하면 연결이 끊어진 후 읽기 및 쓰기 작업으로 인해 발생합니다.
그래서 저는 소켓 시간 제한을 설정하면 문제가 해결될 수 있다고 생각했습니다.
그러나 설정 후에도 상황은 여전히 동일합니다.
이 문제로 며칠간 고민을 했고, 같은 키워드 수를 전제로 이 문제를 일으킨 코드를 찾기 위해 매일 고민하고 비교 테스트를 해왔습니다. 이전 일괄 쿼리 순위 데이터에는 오류가 없었는데, 최근에는 오류가 자주 보고되는 이유는 무엇인가요? 요청한 인터페이스 웹사이트가 우리 서버 IP를 차단하고 있나요? 이 이유만으로는 충분하지 않습니다. 프로그램 어딘가에서 연결을 제대로 해제하지 못했기 때문일 것입니다.
이 아이디어를 바탕으로 며칠간의 지속적인 노력과 연습 끝에 오늘 드디어 타이머 방식으로 인해 발생하는 문제의 본질을 발견했습니다! 상황은 이렇습니다. 지난 며칠 동안 일부 일괄 작업을 수동으로 실행했는데 필터 순위 값이 100일 때 java.net.SocketException: Connection Reset in java 오류가 계속 발생하고 화면이 나타나는 것을 발견했습니다. 새로고침은 이 타이머 코드를 주의 깊게 비교한 후에 특히 강력합니다.
마침내 나는 갑자기 깨달았습니다. 그렇습니다! 여기에 문제가 있습니다. 직접 분석하겠습니다.
함수값, 그것이 반환하는 값이 임계값인데, 제 타이머 방식에서는 반환된 값이 임계값이면 강제로 10초 이내에 해당 메서드를 계속 실행하도록 하는 것으로 판단하고, 이 메서드는 페이지에서 소스 코드의 특정 데이터를 얻으려면 이 메소드를 실행할 때마다 수십 밀리초가 소요됩니다. 이는 이 시간 내에 소켓 연결을 설정하는 것과 동일하지만 항상 임계값을 반환하므로 이 메소드는 지속적으로 이 메서드를 실행하는 데 매번 약 80ms가 걸린다면(테스트 후 각 메서드의 실행 시간은 약 80ms입니다) 이 시간 내에 10*1000/80 = 125 개의 소켓 연결이 설정됩니다. 즉, 초당 12.5 개의 소켓 연결이 설정됩니다. 또한 필터링 프로그램이므로 여러 임계 값이 연속적으로 함께 표시되므로 몇 초 안에 소켓 수가 늘어납니다. 동일한 웹 사이트 페이지에 대한 연결이 매우 높아져 수백 또는 수천에 도달하여 처리 대기 중인 요청 연결 수가 너무 많아집니다.
애초에 메소드를 여러 번 실행하기 위해 이 타이머 메소드를 사용한 이유는 안정적인 데이터 값을 얻기 위한 것이었습니다. 그러나 지금 생각해보면 부정적인 영향은 너무 크고 그 효과를 과소평가할 수 없습니다. , 그러나 며칠 간의 종합적인 분석과 테스트 끝에 마침내 범인이 밝혀졌습니다. 문제가 해결된 후에는 갑자기 마음이 편해지고 잠을 잘 수 있었습니다. . .