O que pode causar intermitentes ORA-12519 (TNS: nenhum manipulador apropriado encontrado) erros

Question

Estamos executando nossa suíte de teste JUnit 4 contra Weblogic 9 na frente de um banco de dados Oracle 10 (usando Hudson como um servidor de integração contínua) e, ocasionalmente, vamos obter um ORA-12519 acidente durante desmontagem script. No entanto, o erro é muito intermitente:

• Isso geralmente acontece para a mesma classe de teste
• Não acontece sempre para os mesmos casos de teste (às vezes eles passam)
• Não acontece para o mesmo número de casos de teste (em qualquer lugar 3-9)
• Às vezes isso não acontece em tudo, tudo passa

Enquanto eu não posso garantir que isso não aconteça localmente (quando executado contra o mesmo banco de dados, é claro), eu tenho que correr o mesmo conjunto de classe várias vezes sem problemas.

Todas as idéias?

Answer 1

Não sei se esta será a resposta de todos, mas depois de algumas escavações, aqui está o que nós viemos acima com.

O erro é, obviamente, causado pelo fato de que o ouvinte não estava aceitando conexões, mas por que temos esse erro quando outros testes poderiam conectar fino (que também pode se conectar sem problema através de sqlplus)? A chave para a questão não era que não pôde se conectar, mas que era intermitente

Depois de algumas investigações, descobrimos que havia alguns dados estáticos criados durante a configuração de classe que iria manter conexões abertas para a vida da classe de teste, criar novos como foi. Agora, mesmo que todos os recursos foram devidamente liberado quando esta classe saiu de escopo (através de um bloco finally {}, é claro), houve alguns casos durante a corrida quando esta classe poderá engolir todas as conexões disponíveis (ok, mau alerta prática -. isso foi código de teste de unidade que conectado diretamente ao invés de usar uma piscina, de modo que o mesmo problema não poderia acontecer em produção)

A correção foi para não fazer essa classe estática e correr na configuração de classe, mas sim usá-lo no per método de configuração e métodos tearDown.

Portanto, se você receber esse erro em seus próprios aplicativos, tapa um profiler em que bad boy e veja se você pode ter um vazamento de conexão. Espero que ajude.

Answer 2

Outra solução que eu encontrei para um erro semelhante, mas a mesma mensagem de erro é aumentar o número de prestadores de serviços encontrados. (My instância desse erro foi causado por muitas conexões nos pools de conexão Weblogic Portal.)

• Executar SQL*Plus e login como SYSTEM. Você deve saber que a senha que você usou durante a instalação do banco de dados Oracle XE.
• Execute o alter system set processes=150 scope=spfile; comando no SQL * Plus
• MUITO IMPORTANTE:. Reinicie o banco de dados

A partir daqui:

http: // www.atpeaz.com/index.php/2010/fixing-the-ora-12519-tnsno-appropriate-service-handler-found-error/

Answer 3

Eu também tive o mesmo problema, eu procurava as respostas muitos lugares. Eu tenho muitas respostas semelhantes para alterar o número de manipuladores de processo / serviço. Mas eu pensei, se eu esqueci de redefini-la de volta?

Então eu tentei usar método Thread.sleep() após cada da minha connection.close();.

Eu não sei como, mas ele está trabalhando, pelo menos para mim.

Se alguém quer experimentá-lo e descobrir como ele está funcionando, por favor, vá em frente. Eu também gostaria de conhecê-lo como eu sou um novato no mundo de programação.

Answer 4

Eu tive o problema semelhante. Aconteceu cada vez que quando eu executar um pacote de banco de dados (Primavera JDBC) testes com SpringJUnit4ClassRunner, então eu resolveu o problema colocando anotação @DirtiesContext para cada teste, a fim de limpar o contexto de aplicação e liberar todos os recursos, assim, cada teste pode ser executado com uma nova initalization do contexto da aplicação.

Answer 5

Eu tive esse problema em um teste de unidade que abriu um monte de conexões com o DB através de um pool de conexão e, em seguida, "parou" o pool de conexão (ManagedDataSource na verdade) para liberar as conexões no final de cada teste. Eu sempre corri para fora de conexões em algum momento no conjunto de testes.

Adicionado um Thread.sleep (500) no teardown () dos meus testes e isso resolveu o problema. Eu acho que o que estava acontecendo era que a paragem de pool de conexão () libera as conexões ativas em outro segmento para que se o thread principal mantém a execução de testes do segmento de limpeza (s) Obteve tão atrás que o servidor Oracle ficou sem conexões. Adicionando o sono permite que as threads em segundo plano para liberar as conexões do pool.

Isto é muito menos de um problema no mundo real porque os servidores de banco de dados são muito maiores e há uma mistura saudável de operações (não apenas infinita DB conexão / desconexão de operações).