Possible memory leak with SLSB on WL5.1

[skaffman]

I've been using SimpleRemoteStatelessSessionProxyFactoryBean to access SLSBs on a Weblogic 5.1 (yes, very old) server, and it would appear to be causing a memory leak in the client VM.

My appcontext on the client is along the lines of:

<bean id="myProxyBean" class="org.springframework.ejb.access.SimpleRemoteStatelessSessionProxyFactoryBean">
   <property name="jndiName" value="mySLSBHomeInterfaceName" />
   <property name="businessInterface" value="myBusinessInterface" />
</bean>

This was used to replace code like this:

public static MyObject lookup(String objId) throws MyException {
		MyRemoteInterface remote = null;
		try {
			MySLSBHome home = (MySLSBHome) NamingUtil.lookup("mySLSBHomeInterfaceName");
			remote = home.create();
			return remote.lookup(objId);
		} catch (CreateException e) {
			throw new MyException (e);
		} catch (NamingException e) {
			throw new MyException (e);
		} catch (EJBException e) {
			throw new MyException (e);
		} catch (RemoteException e) {
			throw new MyException (e);
		} finally {
			ObjectUtil.removeEJB(tpl);
		}
	}

In other words, standard, old-fashioned boilerplate stuff.


Now, functionally, the Spring proxy approach works just fine, but after a certain amount of time, the VM is running out of memory. It happens every time when using the Spring proxy, but never when using the old-style manual code.

Looking through the sourcecode for SimpleRemoteStatelessSessionProxyFactoryBean, it appears to be doing more or less the same logic as the code shown above.

I've tried running the VM through a profiler, but the memory leak doesn't manifest itself when being profiled (typical).

Factors that may be of interest:

Client: Sun 1.3.1 VM
Server: Weblogic 5.1 running on Sun 1.3.1 VM

I can see that potentially there may be issues when running on old VMs and old appservers, but as I said, the actual handling of the SLSB invocations is pretty much the same between the Spring code and my own code.

The leak is proving to be quite a mystery. Any light anyone could shed on this would be greatly appreciated.

[Juergen Hoeller]

That's odd indeed.

Spring's remote EJB accessors "create" a new SLSB instance for each invocation and "remove" it afterwards - in a finally block, so even in case of exceptions. I can't see any potential leak there either...

Juergen

[skaffman]

My hunch is that it isn't anything to do with the EJB access code itself, but rather than AOP shenanigans. This is an awfully old VM we're talking about (the original 1.3.1, not even 1.3.1_01 or the like), so I wouldn't be too surprised if Spring's fancy footwork is causing it to leak classes or classloaders or something along those lines.

[Juergen Hoeller]

I guess you are a candidate for the oldest VM I've encountered this year ;-) Wait, actually I had a guy running on Sun JDK 1.3.0 (!), who had an odd issue back in the Spring 1.2 RC2 days, which we fixed just to stay compatible with the Sun 1.3 classic VM...

WebLogic 5.1 is definitely a candidate for the oldest WebLogic version I've encountered this year, though. I thought WebLogic 6.1 was the oldest I would get ;-)

I assume you're not running CGLIB but plain old JDK dynamic proxies... It could easily be that the original Sun 1.3.1 VM had an issue with dynamic proxies, causing potential memory leaks. Is there any chance you could upgrade to 1.3.1_15, at least for testing purposes?

Juergen

[skaffman]

I assume you're not running CGLIB but plain old JDK dynamic proxies... It could easily be that the original Sun 1.3.1 VM had an issue with dynamic proxies, causing potential memory leaks.

Actually, CGLIB is in there, for use by other stuff, and Spring is picking it up and using it.

Is there any chance you could upgrade to 1.3.1_15, at least for testing purposes?

That's not a bad idea. Unfortunately, WL5.1 (or the patch version that we use, anyway), is not supported on anything other than vanilla 1.3.1. However, our unittest VM runs on its own, and could be made to run on a later VM, maybe even 1.4 (*faints*), just to see if the leak repeats itself.

cheers

[Juergen Hoeller]

Actually, CGLIB is in there, for use by other stuff, and Spring is picking it up and using it.

Note that, while Spring will detect CGLIB when available, it's only gonna use CGLIB when actually needed: that is, for proxying full target classes. CGLIB is by default not gonna be used for proxying interfaces: Spring will always use JDK dynamic proxies for this, unless you explicitly request "proxyTargetClass=true" through the proxy definition.

Juergen