问题描述

我们在 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:

• 它通常发生在同一个测试类
• 对于相同的测试用例(有时它们通过)并不总是发生这种情况
• 对于相同数量的测试用例(从 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).

解决方法是不将该类设为静态并在类设置中运行，而是在每个方法的 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:找不到合适的处理程序)错误的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持跟版网！