WebSphere 6.0.2 + Hibernate + Spring - Memory Leak
We are seeing some memory leak behavior with an app running on WebSphere.
Some heap/thread dump analysis seems to suggest that threads in the WebSphere threadpool are hanging on to some resources. The app slowly consumes resources (CPU/Memory) until OutOfMemoryExceptions begin to occur.
I've read some articles indicating that using ThreadLocal can be a little tricky, but responses by the Spring folks (as well as our analysis of the Spring code) suggests that proper cleanup is done in the OpenSessionInViewFilter. I've seen some posts suggesting that CGLIB may be the culprit, but no hard evidence.
I've scoured the forums and other resources and haven't really come up with anything solid. Any help or insight would be greatly appreciated.
Here's the relevant config info:
WebSphere 6.0.2 (Running on Windows)
Hibernate 3.2.4
Spring 2.0.5
cglib 2.1.3
acegi 1.0.3
commons-dbcp 1.2.2 (we get same behavior with C3PO)
log4j
DB2 Database
We are using a pretty standard configuration.
Web.xml:
Code:
<filter>
<description>
</description>
<display-name>
OpenSessionInView</display-name>
<filter-name>OpenSessionInView</filter-name>
<filter-class>org.springframework.orm.hibernate3.support.OpenSessionInViewFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>OpenSessionInView</filter-name>
<url-pattern>/app/*</url-pattern>
</filter-mapping>
Context config relevant sections:
Code:
<bean id="transactionManager" class="org.springframework.orm.hibernate3.HibernateTransactionManager">
<property name="sessionFactory" ref="sessionFactory"/>
</bean>
Code:
<bean id="txProxyTemplate" abstract="true"
class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean">
<property name="transactionManager" ref="transactionManager"/>
<property name="transactionAttributes">
<props>
<prop key="save*">PROPAGATION_REQUIRED</prop>
<prop key="delete*">PROPAGATION_REQUIRED</prop>
<prop key="update*">PROPAGATION_REQUIRED</prop>
<prop key="get*">PROPAGATION_REQUIRED</prop>
</props>
</property>
</bean>
Thanks,
-Troy
Issue resolved - WAS config issues
We didn't change any application code - there were some config tweaks with WAS that were required to get the application to scale without running out of memory. Adjustments to the session thread pool size and timeout apparently fixed the issue.