Mudanças entre as edições de "O Erro Broken Pipe ou Communications link failure"

Edição atual tal como às 18h33min de 2 de maio de 2023

Este erro, comum em banco de dados MySQL, ocorre por conta de um timeout padrão, no MySQL – e na Integrator, de 8 horas de conexão inativa. O problema é comum quando o desenvolvedor não resolve em seu Pool de Conexões essa característica, seja por desconhecimento ou por esquecimento.

Como Resolver?

Para resolver, existem formas diferentes para cada framework que opera, logo, o que transmitimos neste WIKI não se trata de uma regra da Integrator, mas um auxílio técnico que poderá lhe ajudar a resolver o seu problema. Esteja ciente que não há compromisso do suporte em ajudar a modificar seu código, nem mesmo de resolver a questão.

No Hibernate

Por exemplo, com o Hibernate, em um hibernate.cfg.xml, com o C3p0, temos o hibernate.c3p0.idle_test_period que resolve o broken pipe. No exemplo, ele checa a cada 100 segundos se a conexão está inválida:

<property name="hibernate.connection.provider_class">
  org.hibernate.connection.C3P0ConnectionProvider
</property>
<property name="hibernate.c3p0.min_size">1</property>
<property name="hibernate.c3p0.max_size">20</property>
<property name="hibernate.c3p0.timeout">30</property>
<property name="hibernate.c3p0.idle_test_period">100</property>

Um exemplo com o Pool de Conexões do Tomcat

No Pool do Tomcat, é comum vermos o erro Communications link failure. Neste caso, por exemplo, temos o atributo validationQuery, além de outros testes que permitem a validação da conexão a cada X tempo, permitindo assim que o aplicativo possa analisar se a conexão está ainda ativa ou se o MySQL realizou o famoso timeout.

<Resource auth="Container" 
   name="jdbc/POOL" 
    driverClassName="com.mysql.jdbc.Driver" 
    maxActive="20"    
    maxIdle="10" 
    maxWait="-1" 
    type="javax.sql.DataSource" 
    url="jdbc:mysql://localhost/banco?autoReconnect=true" 
    password="senha"    
    username="usuario"  
    removeAbandoned = true
    validationInterval = 34000
    validationQuery="SELECT 1"
    testOnBorrow="true"   testWhileIdle="true"
   timeBetweenEvictionRunsMillis="10000"
    minEvictableIdleTimeMillis="60000" />
</Context>

Abaixo uma rápida explicação técnica:

Validação da Conexão

• testOnBorrow = true - valida antes de ser usado no pool. Se não validar, ele será retirado do pool, sendo pego outro.

• validationInterval = 34000 - usado para evitar o excesso de validação , apenas executar a validação no máximo nesta frequência - tempo em milissegundos . Se uma conexão está prevista para a validação , mas já foi validado anteriormente neste intervalo, não será validado novamente . Quanto maior o valor, melhor o desempenho, mas você aumenta a chance de uma conexão antiga estar sendo requisitada.

• validationQuery = SELECT 1 - consulta o MySQL usando esta simples query para validar conexões do pool antes de apresenta-las ao aplicativo.

Vazamentos de Conexão

Existem várias definições de configuração para ajudar a detectar vazamentos de conexões, ajudando a resolver possíveis leaks:

• removeAbandoned = true – remove conexões abandonadas se excederem o removeAbandonedTimeout . A conexão é considerada abandonada e elegíveis para retirada do pool. Conexões em banco de dados, desta forma, podem ser recuperadas a partir de aplicações que não conseguem fechar uma conexão.

• removeAbandonedTimeout = 54 - tempo limite em segundos antes que uma conexão seja considerada abandonada e elegível para ser removida.

• validationQuery - Vide explicação anterior.

Nota: As questões informadas neste tópico são de cunho técnico programático, fugindo ao trabalho da hospedagem. Caso não seja o desenvolvedor, informe o problema a ele.

Veja também

• Erro no envio de e-mail por aplicativos Java
• Erro 503 do Apache
• Erro PermGen
• Erro na Exclusão de Banco de Dados PostgreSQL
• Servidor Java não inicia ou instala
• Servidor Caindo Erro 503 PermGen
• Erros 404 e 500 após o deploy
• Erro 500
• Erro 550 Message headers fail syntax check