Java로 작성된 TCP 서버에서 임의의 클라이언트가 5 ~ 60 초 지연되는 경우가 있습니다. 이 때 서버에 여유 공간이 충분하고 CPU가 남아 있습니다. 이 때 소켓이 이미 열려 있습니다.Java 소켓에서 30 초 지연됩니까?
이것은 특정 클라이언트에게 임의로 발생합니다. java 프로세스는 데이터가 전송 된 것처럼 계속되지만 서버는 실제로 데이터를 송수신하지 않습니다.
Nagle을 비활성화했지만 Nagle이 그러한 대기 시간을 초래하는 것을 볼 수 없습니다.
나는 이것에 대해 혼란 스럽기 때문에 나는별로 구체적이지 않다. 이론적으로 이것은 무엇을 일으킬 수 있습니까?
또 다른 한가지 : 클라이언트 중 한 명이 그런 지연을 가지고 있으면 다른 클라이언트가 정상적으로 실행 중입니다. 그리고 그들은 모두 서버의 동일한 이더넷 인터페이스에 있습니다. 나는 그런 것을 설명 할 수 없다.
이론적으로 이것이 발생할 수있는 것은 무엇입니까?
이론적 인 원인은 다음과 같습니다
클라이언트 코드의 버그. 코드를 보지 않고 무엇이 될지 말하기는 어렵지만 스레딩, 알림 또는 동기화 문제는 의심 스럽습니다.
서버 코드에 버그가 있습니다. 위와 같이 무엇이 될지 말하기는 어렵습니다.
JVM 버그. 있을 것 같지 않게.
운영 체제 버그. 있을 것 같지 않게.
네트워킹 문제. 어쩌면 클라이언트와 서버 사이에 flakey 또는 잘못 구성된 스위치/게이트웨이/방화벽이있을 수 있습니다. 네트워킹 및 가상화에 문제가있을 수 있습니다.
나는 당신이 패킷이 와이어 등을 통과 할 때를 볼 수 있는지 Wireshark와 같은 것을 사용해야한다고 생각합니다. 그것은 그것을 조금 좁히는 데 도움이 될 것입니다.
이 특정 고객에게 무작위로 발생합니다. java 프로세스는 데이터가 전송 된 것처럼 계속되지만 서버는 실제로 데이터를 송수신하지 않습니다.
는 스스로에게 물어 몇 가지 추가 질문이 있습니다
그것은 단지 "특정"고객에 발생합니다. 그래서 그들에 대해 다른 점은 무엇입니까?
Java 프로세스는 데이터가 전송 된 것처럼 계속 진행됩니다. 그렇다면 왜 데이터가 전송되었다고 생각합니까?
서버는 "물리적으로"데이터를 송수신하지 않습니다. "육체적으로"는 무엇을 의미합니까? 왜 이것이 사실인지 아는가/믿는가? 서버 스레드가 읽기에서 차단 되었습니까? 아니면 듣기에 막혔습니까? 데이터가 서버 시스템에 실제로 도착 했습니까?
내 주요 문제는 문제를 재현 할 방법이 없다는 것입니다. 이 대답을위한 thx. 내 제안에 따라 내 서버에 추적을 더 추가하겠습니다. 나는 여전히 pb를 얻지 못하면 결과에 따라 다른 질문을 더 정확하게 게시 할 것입니다. – Joel
@Joel - 재현하기 어려운 문제는 종종 스레딩/동기화 버그로 드러납니다. 불행히도 이러한 버그를 찾는 가장 좋은 방법은 스레딩을 실제로 이해하는 사람과 자바 메모리 모델을주의 깊게 분석하는 것입니다. –
그것은 분명히 동기화와 관련이 없습니다. 이것은 outputstream.write() 및 inputstream.read() 지침에서 발생합니다. 인터넷 라우팅이 이미 열려있는 소켓을 사용하여 몇 초가 걸릴 수도 있습니다. 아니면 불가능한가요? – Joel
동시성 아키텍처에서 교착 상태를 확인했는지, 시간 초과 잠금을 사용하는 경우 잠금 시간이 초과 되었습니까? – gd1
예. 있습니다. 교착 상태가 없습니다 – Joel