A java.net.SocketException Broken Pipe - Blog da Caelum: desenvolvimento, web, mobile, UX e Scrum
Quando começamos a programar com banco de dados, rapidamente aprendemos que devemos sempre usar um pool de conexões para acessa-lo, caso contrário podemos facilmente atrapalhar o bom funcionamento do mesmo, devido o excesso de conexões.
Passamos então a usar um pool de conexões, e ao colocar o sistema em produção, nos deparamos com outro problema: o broken pipe:
at com.mysql.jdbc.MysqlIO.send(MysqlIO.java:2690)
No GUJ, são mais de 100 mensagens a respeito de broken pipes! Recentemente Tomaz Lavieri abriu um detalhado tópico sobre esse mesmo assunto, que me incentivou a escrever esse post, dada sua relevância.
Por que essa exception acontece? São dois motivos principais:
O primeiro é que muitos bancos de dados possuem um timeout para conexões inativas (o padrão do MySQL é de 8 horas, mas em alguns hosts isso pode estar configurado em segundos!). Depois de determinado tempo, o banco de dados mata essa conexão ociosa numa tentativa de economizar recursos, pois conclui que alguém simplesmente a esqueceu aberta. Quando, no lado do cliente, seu pool decide usá-la, a socket rapidamente percebe que a conexão foi fechada do outro lado, foi quebrada (daí o nome broken pipe). Muito comum ao começar a usar um pool!
O segundo motivo é que você pode estar tratando suas transações sem o devido cuidado: esquecendo de fazer o commit ou o rollback em alguns casos. O banco de dados então pode matar essa conexão depois de algum timeout de transação, porém o seu pool não sabe disso, e quando for utilizar essa conexão, ela está quebrada!
Solução rápida? Configurar o seu pool para testar se as conexões continuam válidas. No C3P0, pool de conexões que recomendamos fortemente, quando usado com o Hibernate, basta fazer no seu hibernate.cfg.xml:
É a configuração hibernate.c3p0.idle_test_period que resolve o broken pipe. Nesse caso o C3P0 fara essa verificação de maneira assíncrona: ele cria threads (3 por padrão) que checam de tanto em tanto tempo (100 segundos nesse caso) se alguma das conexões do pool está inválida (broken pipe é um dos casos). Na existência de uma conexão assim, essa será eliminada do seu pool! Você ainda pode ter um azar muito grande, pois uma conexão pode ter algum problema logo depois que a thread a verificou! Se você quer ter uma confiabilidade de 100% em relação a suas conexões, você pode configurar a variável testConnectionOnCheckout no arquivo c3p0.properties que deve ser colocado no seu classpath. Isso não é muito recomendado, pois toda vez que uma conexão é pega do pool, alguma forma de ping será feito no banco de dados para saber se ela é válida, perdendo um pouco de performance.
Vale lembrar de que isso não é motivo para você se descuidar no tratamento de transações, centralizando isso dentro de um interceptador/filtro que faça o uso correto do try, catch e finally, precavendo-se de qualquer vazamento. Transações, assim como qualquer outro recurso caro (arquivos, conexões, sockets, threads, etc…), deve ter seu ciclo de vida tratado com atenção, de preferência de maneira isolada.
Caso você não use Hibernate, Jerônimo Mozer mostra como usar o C3P0 programaticamente.
Mais detalhes podem ser vistos nas configurações de teste de conexões do C3P0, detalhes do seu funcionamento com o Hibernate e a página do próprio Hibernate sobre esse pool, mas que se encontra um pouco defasada. Também vemos muitos detalhes como esses no nosso curso FJ-25.
Tags: broken pipe, c3p0, connection, connection pool, escalabilidade, hibernate, Java, mysql
Paulo Silveira 19/10/2009 at 16:55 #
Outra dica é que o pool de prepared statements pode deixar vazar memoria, basta configurar hibernate.c3p0.max_statements para 0.
Edvaldo Melo 19/10/2009 at 17:31 #
Tomaz Lavieri 19/10/2009 at 18:19 #
Opa Paulo!, excelente esse topico.
broken pipe é um problema muito recorrente, e vejo muita gente enfrentando o problema, graças aos nossos debates consegui chegar a uma solução onde o teste só é feito a cada 100 segundos, anteriormente eu estava usando um teste a cada retirada de conexão do pool.
Agora ajudando com mais um dica
"pois toda vez que uma conexão é pega do pool, alguma forma de ping será feito no banco de dados para saber se ela é válida, perdendo um pouco de performance".
O padrão do c3p0 para checar a conexão é usar um getTables() que é compativel com todos os bancos de dados, para quem tem muitas tabelas, e esta muito preucupado com a performance, pode reduzir esse teste de três maneiras:
– configurar o "automaticTestTable", pode ser configurado para o c3p0 criar uma tabela e realizar testes nela.
– configurar o "preferredTestQuery" para realizar uma query simples personalizada.
– criar uma classe que realiza o teste "connectionTesterClassName"
mais informações aqui => http://bit.ly/VuRFU
Tomaz Lavieri 19/10/2009 at 18:32 #
Outra dica para quem usa MySQL:
algumas configurações do banco afetam diretamente neste controle do pool, a maior parte dos meus problemas na configuração do c3p0 foi algumas propriedade do meu servidor MySQL.
segue as antigas configuraçẽos do my.cnf do servidor que fui obrigado a mudar:
"interactive_timeout" e "wait_timeout" são muito parecidas, e as duas matarão conexões inativas por X segundos, onde X é o tempo nelas definidas.
"connect_timeout" é o tempo maximo que alguem pode ficar conectado ao seu banco de dados, esta configuração definitivamente não estava boa.
modifiquei o wait e o interactive para 500, e retirei o connect_timeout (o padrão do mysql são 12 horas)
com essas mudanças meu banco passou a permitir conexões ativar por no maximo de 12 horas, desde que elas sejam renovadas a cada 500 segundos (8,3 minutos).
como o "idle_test_period" testa a conexão a cada 100 segundos, a conexão do pool é sempre renovada, garantido que não haverá broken, após 12 horas a conexão é perdida devida ao tempo maximo de conexão com o banco, mas como o c3p0 faz um teste a cada 100 segundos, o teste coincide com o momento da queda, reativando instantaneamente.
Rodrigo Facholi 21/10/2009 at 10:11 #
Como sempre, uma ótima explicação Paulo.
Roberto 22/10/2009 at 15:35 #
eu tenho visto por aí o pessoal colocar o idle_test_period igual o timeout, pelo que entendi, com o timeout menor ainda existe um tempo até rolar o teste em que o pool pode acabar pegando uma conexão inválida.
entendo que nesse caso o timeout é tão pequeno que essa abordagem poderia gerar o mesmo tipo de efeito colateral que o testConnectionOnCheckout.
será que um timeout maior, por exemplo 100 segundos, traria algum problema? pois neste caso tenho a impressão que já se tornaria viável colocar o mesmo valor para o idle_test_period.
Paulo Silveira 22/10/2009 at 15:45 #
Perfeito comentário. Na própria documentação o pessoal do C3P0 recomenda um valor alto para testes, como de 1000 segundos ou mais, para ter uma senhora escalabilidade. Claro que ai voce deve pensar melhor se seu host for compartilhado e conexoes viverem pouco!
Washington Botelho 29/01/2010 at 09:42 #
Muito bom o artigo Paulo.
Hoje comecei o dia com um Broke Pipe e o Jeveaux já me indicou seu artigo.
Paulo Silveira 28/02/2010 at 18:36 #
Aqui tem mais informações desse problema: http://www.databasesandlife.com/automatic-reconnect-from-hibernate-to-mysql/
Edson Marques Barbosa 08/06/2010 at 19:02 #
Srs, trabalho como administrador Weblogic(8, 9 e 10 ) numa estrutura com muitos domínios e muitas aplicações distintas usando pools com bancos Oracle. Gostaria de saber de vocês como deveria proceder para saber o porquê de tantas ocorrências de Broken pipe nos logs das JVM's. Quero fazer uma pesquisa para ter evidências técnicas para reportar de maneira precisa o problema. Alguém sabe por onde começar ?? Desde já muito obrigado.
Paulo Silveira 08/06/2010 at 20:54 #
O problema é que alguma das duas partes fechou o seu lado da conexão. provavelmente a não java, e aí quando o Java tenta conversar, o cano estava quebrado. A idéia é usar um bom pool, seja através de datasource ou não, que saiba verificar se a conexao esta boa… o C3P0 faz isso bem.
Deivid Martins 17/10/2010 at 12:53 #
Resolveu meu problema de broken pipe!
Daniel 03/12/2010 at 09:08 #
funcionava ate o Tomcat 6.0.20. Estou tendo problema com o listener que verifica memory leak (introduzido na versao 6.0.25)
amazu 02/03/2011 at 17:40 #
Use DBCP e acabou de vez o seu proplema de pipe
Paulo Silveira 02/03/2011 at 19:54 #
Minhas experiências com o DBCP nunca foram as melhores. o C3P0 sempre se apresentou de melhor forma. Mas como meu último projeto que coloquei DBCP em produção foi em 2005, muita coisa pode ter mudado.
Pimenta 21/05/2013 at 16:32 #
E quando o Hudson te apresenta a exceção?
Daniel Interliche 09/07/2014 at 18:54 #
Eu verifiquei as variáveis de ambiente do mysql e esta configurado o valor default de 28800 segundos. Quem abre e fecha minhas transações é o interceptor do plugin do vraptor (versao 1.0.1). Ainda assim tenho tomado com frequência exceptions relacionadas ao erro broken pipe line.
Daniel Interliche 09/07/2014 at 18:55 #
Só uma observação referente ao meu comentário anterior. O plugin do Vraptor no qual eu me refiro é o vraptor-jpa versão 1.0.1
Yehia Azanki 03/01/2015 at 01:05 #
E no caso da JPA q eu não utilizo hibernate.cfg.xml??? eh a mesma coisa???
Victor Hugo 28/07/2015 at 11:46 #
Olá Yehia Azanki, meu persistence.xml ficou assim:
Jerônimo Mozer 17/11/2015 at 16:34 #
Opa, fui citado na matéria, que honra, só vi agora depois de 6 anos, se soubesse antes teria colocado no meu currículo rsrsrsrsrsrsrs