Primeiro vamos entender as propriedades do mysql.

• interactive_timeout :tempo limite interativo para sessões de shell mysql em segundos como mysqldump ou ferramentas de linha de comando mysql. as conexões estão em estado de suspensão. Na maioria das vezes, isso é definido com um valor mais alto porque você não deseja que ele seja desconectado enquanto estiver fazendo algo no mysql cli.
• wait_timeout :a quantidade de segundos durante a inatividade que o MySQL irá esperar antes de fechar uma conexão em uma conexão não interativa em segundos. exemplo:conectado de java. as conexões estão em estado de suspensão.

Agora vamos entender as propriedades do c3po e sua relação com as props do banco de dados. (Vou copiar da sua pergunta)

Isso se refere a quanto tempo um objeto de conexão pode ser usado e estará disponível no pool. Quando o tempo limite terminar, o c3po irá destruí-lo ou reciclá-lo.

Agora o problema vem quando você tem maxIdleTime maior que o wait_timeout .digamos que o mxIdleTime : 50 segundos e wait_timeout : 40 s então há uma chance de você obter Connection time out exception: Broken Pipe se você tentar fazer qualquer operação nos últimos 10 segundos. Então maxIdelTime deve ser sempre menor que wait_timeout .

Em vez de maxIdleTime, você pode usar as seguintes propriedades.

• idleConnectionTestPeriod define um limite para quanto tempo uma conexão permanecerá inativa antes de testá-la. Sem preferredTestQuery , o padrão é DatabaseMetaData.getTables() - que é independente de banco de dados e, embora seja uma chamada relativamente cara, provavelmente é boa para um banco de dados relativamente pequeno. Se você é paranóico com o desempenho, use uma consulta específica para seu banco de dados (i.e. preferredTestQuery="SELECT 1")
• maxIdleTimeExcessConnections trará de volta o backdown connectionCount para minPoolSize após um pico de atividade.

Observe que qualquer propriedade do pool (por exemplo, maxIdleTime ) afeta apenas a conexão que está no pool ou seja, se o hibernate adquiriu uma conexão e a mantém ociosa por mais de maxIdleTime e depois tenta fazer qualquer operação, você obterá "Broken Pipe"

É bom ter wait_timeout menor no mysql, mas nem sempre está certo quando você tem um aplicativo já compilado. Você deve ter certeza antes de reduzi-lo que em seu aplicativo você não está mantendo a conexão aberta por mais de wait_time Fora.

Você também deve considerar que adquirir uma conexão é uma tarefa cara e, se o tempo de espera for muito baixo, supera todo o propósito de ter um pool de conexões, pois ele tentará frequentemente adquirir conexões.

Isso é especialmente importante quando você não está fazendo o gerenciamento de conexão manualmente, por exemplo, quando você usa a API transnacional do Spring. O Spring inicia a transação quando você insere um @Transaction método anotado para que ele adquira uma conexão do pool. Se você estiver fazendo qualquer chamada de serviço da web ou lendo algum arquivo que demore mais do que wait_time out, você receberá uma exceção.

Já enfrentei esse problema uma vez.

Em um dos meus projetos eu tinha um cron que faria o processamento de pedidos para os clientes. Para torná-lo mais rápido, usei o processamento em lote. Agora, uma vez que recupero um lote de clientes e faço algum processamento (sem chamadas de banco de dados). Quando tento salvar todos os pedidos, costumava obter uma exceção de tubo quebrado. O problema era que meu wait_timeout era de 1 minuto e o processamento do pedido estava demorando mais do que isso. Então tivemos que aumentar para 2 minutos. Eu poderia ter reduzido o tamanho do lote, mas isso estava tornando o processamento geral mais lento.