/ / Razões oficiais para “O software causou uma interrupção de conexão: erro de gravação de soquete” - java, exceção, soquetes, tomcat, rastreamento de pilha

Razões oficiais para “Software causou a anulação da conexão: erro de gravação do soquete” - java, exceção, sockets, tomcat, stack-trace

Dado esse snippet de rastreamento de pilha

Causado por: java.net.SocketException: Interrupção de conexão causada por software: erro de gravação do soquete
às java.net.SocketOutputStream.socketWrite0 (nativo Método)

Tentei responder às seguintes perguntas:

  1. Qual código está lançando essa exceção? (JVM? / Tomcat? / Meu código?)
  2. O que faz com que essa exceção seja lançada?

Em relação ao item 1:

A fonte JVM da Sun não contém essa mensagem exata, mas acho que o texto O software causou a interrupção da conexão: erro de gravação do soquete é da implementação nativa de SocketOutputStream:

private native void socketWrite0(FileDescriptor fd, byte[] b, int off,
int len) throws IOException;

Em relação a # 2

Meu palpite é que isso é causado quando o cliente temencerrou a conexão antes de obter a resposta completa (por exemplo, enviou uma solicitação, mas antes de obter a resposta completa, ela foi fechada / encerrada / offline)

Questões:

  1. As premissas acima estão corretas (nº 1 e nº 2)?
  2. Isso pode ser diferenciado da situação: "não foi possível gravar no cliente, devido a um erro de rede no servidor side "? ou isso renderizaria a mesma mensagem de erro?
  3. E o mais importante: Existe um documento oficial (por exemplo, da Sun) afirmando o acima?

Preciso ter uma prova de que esse rastreamento de pilha éa falha do cliente de soquete e não há nada que o servidor possa ter feito para evitá-la. (exceto capturando a exceção ou usando uma Sun JVM SocketOutputStream que não seja da Sun, embora ambos não evitem o fato de que o cliente foi encerrado )

Respostas:

47 para resposta № 1

"Este erro pode ocorrer quando a rede localsistema interrompe uma conexão, como quando o WinSock fecha uma conexão estabelecida após a retransmissão de dados falhar (o receptor nunca reconhece os dados enviados em um soquete do fluxo de dados). ". este artigo do MSDN. Veja também Algumas informações sobre "O software causou a interrupção da conexão".


9 para resposta № 2

Eu já vi isso com mais frequência quando um firewall corporativo em uma estação de trabalho / laptop atrapalha, mata a conexão.

por exemplo. Eu tenho um processo de servidor e um processo de cliente na mesma máquina. O servidor está escutando em todas as interfaces (0.0.0.0) e o cliente tenta uma conexão com a interface pública / doméstica (observe a interface de loopback 127.0.0.1).

Se a máquina estiver com a rede desconectada (por exemplo, wifi desligado), a conexão será formada. Se a máquina estiver conectada à rede corporativa (diretamente ou VPN), a conexão será formada.

No entanto, se a máquina estiver conectada a uma rede públicawifi (ou rede doméstica), o firewall entra em ação e mata a conexão. Nessa situação, conectar o cliente à interface de loopback funciona bem, mas não à interface doméstica / pública.

Espero que isto ajude.


4 para resposta № 3

Para provar qual componente falha, eu monitorava a comunicação TCP / IP usando wireshark e veja quem está fechando completamente a porta, também os intervalos podem ser relevantes.


3 para resposta № 4

o java.net.SocketException é lançado quando há um erro ao criar ou acessar uma tomada (tal como TCP) Isso geralmente pode ser causado quando o servidor encerra a conexão (sem fechá-la adequadamente), portanto, antes de obter a resposta completa. Na maioria dos casos, isso pode ser causado pelo problema de tempo limite (por exemplo, a resposta leva muito tempo ou o servidor está sobrecarregado com as solicitações) ou o cliente enviou o SYN, mas ele não recebeu ACK (reconhecimento da terminação da conexão) Para problemas de tempo limite, considere aumentar o valor do tempo limite.

A exceção de soquete geralmente vem com a mensagem de detalhes especificada sobre o problema.

Exemplo de mensagens detalhadas:

  • O software causou a interrupção da conexão: falha na recuperação.

    O erro indica uma tentativa de enviar a mensagem e a conexão foi interrompida pelo seu servidor. Se isso aconteceu durante a conexão com o banco de dados, isso pode estar relacionado ao uso driver Connector / J JDBC não compatível.

    Solução possível: verifique se você possui bibliotecas / drivers adequados no seu CLASSPATH.

  • Interrupção de conexão causada por software: conectar.

    Isso pode acontecer quando houver um problema para conectar-se ao controle remoto. Por exemplo devido ao verificador de vírus rejeitar as solicitações de correio remoto.

    Solução possível: verifique se o serviço de verificação de vírus está bloqueando a porta para as solicitações de saída de conexões.

  • O software causou a interrupção da conexão: erro de gravação do soquete.

    Solução possível: verifique se você está escrevendo o comprimento correto de bytes no fluxo. Verifique novamente o que está enviando. Veja isso fio.

  • Redefinição de conexão por ponto: erro de gravação de soquete / Conexão interrompida por ponto: erro de gravação de soquete

    O aplicativo não verificou se a conexão keep-alive havia atingido o tempo limite no servidor.

    Solução possível: verifique se o HttpClient não é nulo antes de ler a partir da conexão.E13222_01

  • Redefinição de conexão por pares.

    A conexão foi encerrada pelo par (servidor).

  • Reinicialização da conexão.

    A conexão foi encerrada pelo cliente ou fechada pelo final do servidor devido a solicitação com a solicitação.

    Vejo: O que está causando meu java.net.SocketException: Conexão redefinida?


2 para resposta № 5

Você verificou o código fonte do Tomcat e a fonte da JVM? Isso pode lhe dar mais ajuda.

Eu acho que o seu pensamento geral é bom. Eu esperaria um ConnectException no cenário que você não pôde conectar. O exemplo acima parece muito com o cliente.


2 para resposta № 6

Para quem usa programas simples do Client Server e obtém esse erro, é um problema de fluxos de entrada ou saída não fechados (ou fechados para o início).


1 para resposta № 7

Eu estava enfrentando o mesmo problema.
Comumente Esse tipo de erro ocorre porque o cliente fechou sua conexão e o servidor ainda está tentando gravar nesse cliente.
Portanto, verifique se o seu cliente tem sua conexão aberta até o servidor concluir o fluxo de saída.
E mais uma coisa, não se esqueça de fechar fluxo de entrada e saída.

Espero que isto ajude.
E se ainda estiver enfrentando um problema, informe-o aqui em detalhes.


0 para a resposta № 8

Esse erro aconteceu comigo ao testar meu serviço de sabão com o cliente SoapUI, basicamente eu estava tentando receber uma mensagem muito grande (> 500kb) e o SoapUI fechou a conexão por tempo limite.

No SoapUI, acesse:

Arquivo -> Preferências - Tempo limite do soquete (ms)

... e colocar um valor grande, como 180000 (3 minutos), isso não será a solução perfeita para o seu problema, pois o arquivo é realmente grande demais, mas pelo menos você terá uma resposta.


0 para a resposta № 9

No meu caso, o erro foi:

java.net.SocketException: Software caused connection abort: recv failed

Foi recebido no eclipse durante a depuração de um javaaplicativo acessando um banco de dados H2. A origem do erro foi que eu havia aberto o banco de dados com o SQuirreL para verificar manualmente a integridade. Usei o sinalizador para ativar várias conexões com o mesmo banco de dados (ou seja, AUTO_SERVER=TRUE), portanto não houve problemas ao conectar-se ao banco de dados a partir do java.

O erro apareceu quando, depois de um tempo - é umlong java process-- Decidi fechar o SQuirreL para liberar recursos. Parece que SQuirreL foi o "proprietário" da instância do servidor DB e que foi encerrada com a conexão SQuirreL.

Reiniciar o aplicativo Java não produziu o erro novamente.

config

  • Windows 7
  • Eclipse Kepler
  • SQuirreL 3.6
  • org.h2.Driver versão 1.4.192

-1 para resposta № 10

Meu servidor estava lançando essa exceção nos últimos dois dias e resolvi-a movendo a função desconectar com:

outputStream.close();
inputStream.close();
Client.close();

Até o final do segmento da lista. se isso ajudou alguém.


-1 para resposta № 11

Na situação explicada abaixo, o lado do cliente lançará uma exceção:

O servidor é solicitado a autenticar o clientecertificado, mas o cliente fornece um certificado que o Uso Estendido de Chave não oferece suporte à autenticação do cliente; portanto, o servidor não aceita o certificado do cliente e fecha a conexão.


-3 para a resposta № 12

Eu estava enfrentando o mesmo problema com o wireMock enquanto zombava das demais chamadas da API. Anteriormente, eu estava definindo o servidor assim:

WireMockServer wireMockServer = null;

Mas deve ser definido como mostrado abaixo:

@Rule
public WireMockRule wireMockRule = new WireMockRule(8089);