Solve the Problem of proxool connection Oracle memory overflow

Proxool is an excellent open source connection pool. I have compared the three connection pools DBCP, c3p0, and proxool to read and analyze their code. In contrast, proxool uses cglib, and its source code is quite concise and elegant.
But unfortunately, this time, the memory leakage account is counted on it. We use version 0.9.1 of proxool and the environment is Oracle jdbc5 + IBM jdk5.

0.9.1 is the latest version of proxool. One of our applications has been in the haze of memory overflow since it was said to have been running. Some BUSY systems that catch up with data may die several times or even dozens of times in a day. Some monitoring scripts have to be used for timed restart. This problem has also plagued me since I took over in last December. In the worst case, even a 50 + GB heap of well-deployed instances with some hardware facilities can be eaten in one day.

The cause of the error is very simple. proxool uses cglib, which uses wrappedconnection to proxy the actual conneciton. When running the wrappedconnection method, including its Finalize method, all call the conneciton. isclosed () method to determine whether certain operations are required. Unfortunately, Oracle
In JDBC, this method is synchronous, and the lock is the connection object itself. Therefore, when the finalizer thread recycles the wrappedconnection object that has just been executed, it will always compete with the working threads that are still using the connection.

Paste a simple graph and you will understand:

The solution is to make a small change in row 114th of wrappedconnection. java. Do not remove the isclosed () method when the Finalize method is called. In fact, the call to the wrappedconnection # finalize () method has nothing to do with the connection. Oracle JDBC itself does not implement the finalize () method. Instead, the cglib proxy object generates a finalize () method.
Row 114 before modification:

if (proxyConnection != null && proxyConnection.isReallyClosed()) {

Modified row 114:

if (proxyConnection != null && !concreteMethod.getName().equals(FINALIZE_METHOD) && proxyConnection.isReallyClosed()) {

Click here to view the complete wrappedconnection. Java on SourceForge.

The effect is obvious. On the one hand, memory consumption is significantly reduced. Previously, all the deployed instances were replaced in a different period of time, and some of the 52g stacks of the deployed instances would overflow! Now, the system is busy with its heap size, which is basically under the old XMS parameter. Second, the throughput has suddenly increased a lot, and there is no disturbing interference from the recycling thread (its priority is high). Of course it should be faster.

If you are interested, you can download the jar package (-target 1.5), (the source code is directly from the official website's proxool-0.9.1-source.zip ). This jar package also solves the problem that proxooldatasource cannot be injected with three attributes (maximumconnectionlifetime, housekeepingsleeptime, overloadwithoutrefusallifetime) when configured as bean in spring. For more information, see this blog post.

Download proxool-0.9.1

You can also compile a patch by yourself. Patch I uploaded it to the bug page. Please download it there.

From: http://blog.xiping.me/2011/04/proxool-memory-leak.html