什么会导致间歇性的ORA-12519(TNS:找不到合适的处理程序)错误 [英] What can cause intermittent ORA-12519 (TNS: no appropriate handler found) errors

问题描述

我们在Oracle 10数据库(使用Hudson作为连续集成服务器)之前针对Weblogic 9运行我们的Junit 4测试套件，有时在脚本拆除过程中会发生ORA-12519崩溃.但是，错误是非常间歇性的:

We are running our Junit 4 test suite against Weblogic 9 in front of an Oracle 10 database (using Hudson as a continuous integration server) and occasionally we will get an ORA-12519 crash during script teardown. However, the error is very intermittent:

• 通常在相同的Test类中发生
• 并非总是在相同的测试用例中发生(有时它们通过了)
• 对于相同数量的测试用例(从3到9)，不会发生
• 有时候根本不会发生，一切都会过去

虽然我不能保证这不会在本地发生(当然，当针对同一个数据库运行时)，但我多次运行相同的类套件却没有问题.

While I can't guarantee this doesn't happen locally (when running against the same database, of course), I have run the same suite of class multiple times with no issues.

有什么想法吗?

推荐答案

不知道这是否将是每个人的答案，但是经过一番挖掘，这就是我们的想法.

Don't know if this will be everybody's answer, but after some digging, here's what we came up with.

错误显然是由于侦听器不接受连接这一事实引起的，但是当其他测试可以正常连接时(为什么我们也可以通过sqlplus连接也没有问题)，为什么我们会收到该错误?问题的关键不是我们无法连接，而是间歇

The error is obviously caused by the fact that the listener was not accepting connections, but why would we get that error when other tests could connect fine (we could also connect no problem through sqlplus)? The key to the issue wasn't that we couldn't connect, but that it was intermittent

经过一番调查，我们发现在类设置过程中创建了一些静态数据，这些数据将在测试类的整个生命周期中保持开放的连接，并随着时间的流逝创建新的连接.现在，即使在此类超出范围时(当然，通过finally {}块)适当地释放了所有资源，在运行过程中还是有某些情况下此类会吞没所有可用的连接(好的，不好的)练习警报-这是直接连接而不是使用池的单元测试代码，因此在生产中不会发生相同的问题.

After some investigation, we found that there was some static data created during the class setup that would keep open connections for the life of the test class, creating new ones as it went. Now, even though all of the resources were properly released when this class went out of scope (via a finally{} block, of course), there were some cases during the run when this class would swallow up all available connections (okay, bad practice alert - this was unit test code that connected directly rather than using a pool, so the same problem could not happen in production).

解决方法是不要使该类静态化并在类设置中运行，而应在per方法setUp和tearDown方法中使用它.

The fix was to not make that class static and run in the class setup, but instead use it in the per method setUp and tearDown methods.

因此，如果您在自己的应用程序中遇到此错误，请在该坏男孩身上打探探查器，看看是否可能存在连接泄漏.希望有帮助.

So if you get this error in your own apps, slap a profiler on that bad boy and see if you might have a connection leak. Hope that helps.

这篇关于什么会导致间歇性的ORA-12519(TNS:找不到合适的处理程序)错误的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！