西 坪

Update: Be cautions if you don’t apply the patch to work with Oracle JDBC. The finalize() method in the WrappedConnection instances is always invoked when they are being finalized; then the finalize() in the physical connection class would be invoked. If the JDBC driver places some code there, it could destroy the pooled connections. (Apr 10th, 2011)
============================

Someone has reported a possible memory leak related with Proxool connection pool. And we addressed the bug recently in our applications, which are Java backend applications that work with Oracle 11g through Oracle JDBC5 on IBM JDK 5 platform.

The finalize() method of the proxied OracleConnection instances are the root cause. OracleConnection classes have no explict finalize() method, but each proxied object has one generated by cglib. When such a proxied connection instance is being finalized, the stack should be as the figure shows. You can see Connection#isClosed() method is invoked, which is SYNCHRONIZED (the monitor is the connection object itself). Then the finalizer thread and the worker thread using the physical connection could block each other. Finally, the proxied connection objects in finalizing queue and all referenced objects couldn’t be garbage-collected. Sometimes Connections aren’t so busy – you are lucky – the heap could suspend or even decrease; but OOM is waiting for you at the end usually.

I gave a fix that avoid invoking Connection#isClosed() while finalizing. Actually, I changed the line 114 of WrappedConnection from

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

to

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

The fix is proved to be effective in our serveral systems in production .

You can download the patch in the bug page in proxool bugtrack site.

Or you can download a compiled version of proxool-0.9.1.jar(WITHOUT WARRANT). (It’s comipled from proxool-0.9.1-source.zip)

Any questions please let me know by giving a comment.

最近很多工作在Linux下做，但是因为整个公司的环境是Windows，很多事情也经常要在Windows下处理。于是在Windows XP上用VMware搭建了OpenSUSE，同时使用这两种系统。经过这段时间的使用，觉得OpenSUSE的桌面支持确实是做得不错的，似乎比Ubuntu更加方便简单。但是Ubuntu更流行，很多简单的设置问题，网络上随处可见Ubuntu的解决方案，而SUSE的方案却难觅踪影。

例如，我经常使用VMWare的共享文件夹特性来在Host与Guest之间交换数据，共享文件。 但是在OpenSUSE下，却没有找到合适的方法。最终，不得不求助于Samba。 Samba在OpenSUSE上的安装是很方便的，基本上遵照 How To Samba With openSuse 10.3 And Windows XP 的指导，三两步就完成了。 完毕以后，在Windows XP 下映射一个盘符到 \\GUEST_HOSTNAME\users 就完成了。我完全关闭了Guest上的防火墙，有防火墙反而可能招致麻烦。

而在OpenSUSE上访问Windows XP也很简单，基本上遵照 SDB:Access to Windows Shares 的 Manual Procedure 部分，将Windows XP共享目录加入到 /etc/fstab 中：

  1 /dev/sda1            swap                 swap       defaults              0 0
  2 /dev/sda2            /                    ext4       acl,user_xattr        1 1
  3 /dev/sda3            /home                ext4       acl,user_xattr        1 2
  4 proc                 /proc                proc       defaults              0 0
  5 sysfs                /sys                 sysfs      noauto                0 0
  6 debugfs              /sys/kernel/debug    debugfs    noauto                0 0
  7 usbfs                /proc/bus/usb        usbfs      noauto                0 0
  8 devpts               /dev/pts             devpts     mode=0620,gid=5       0 0
  9 //x.x.x.x/work   /mnt/windows    cifs  auto,uid=liuz,gid=users,umask=0002,iocharset=utf8,credentials=/etc/winpasswd 0 0

别忘了保护你的密码文件：

chmod 600 /etc/winpassword

特殊之处，是指定了一个 uid=liuz， 将文件的所有者指定为liuz这个用户，方便增删改等操作。有关 uid,gid,umask等的解释如下： (来源)

uid与gid
uid即user identifer，gid即group identifer。设置所有文件的所有者和群组。gid=64，即权限为所有者可读、写，不能执行，群组用户可读、不能写、执行。
umask
umask即user mask，即用户屏蔽。umask=007，即所有文件的权限中，屏蔽其它使用者的读、写、执行权限。

总结

总结一下我使用的这三种方法：

• 1) 使用VMware提供的共享文件夹功能。
• 2) 使用Samba为Windows Host OS 共享Linux Guest OS文件系统。
• 3) 在Linux Guest OS中mount Host OS （Windows系统）的共享文件夹。