Leaking PreparedStatement and ResultSet via CollectionLoadContext instances maintained in Map collectionLoadContexts in LoadContexts

Description

While diagnosing an apparent resource issue, while running our application for a couple of hours I noticed over time that the number of PreparedStatement and ResultSet instances continued to grow, eventually consuming a fair amount of memory. After digging around a bit, I saw that the entries LoadContext.java inserts into the map named collectionLoadContexts are not removed from the map [method cleanup(ResultSet resultSet) might have removed them, but I never witnessed its invocation, nor did I find any references to it).

I pasted below a stack trace that shows the insertion of elements into collectionLoadContexts:

Thread [http-9943-Processor2] (Suspended (breakpoint at line 53 in CollectionLoadContext))
CollectionLoadContext.<init>(LoadContexts, ResultSet) line: 53
LoadContexts.getCollectionLoadContext(ResultSet) line: 85
BasicCollectionLoader(Loader).handleEmptyCollections(Serializable[], Object, SessionImplementor) line: 1060
BasicCollectionLoader(Loader).doQuery(SessionImplementor, QueryParameters, boolean) line: 690
BasicCollectionLoader(Loader).doQueryAndInitializeNonLazyCollections(SessionImplementor, QueryParameters, boolean) line: 236
BasicCollectionLoader(Loader).loadCollection(SessionImplementor, Serializable, Type) line: 1994
BasicCollectionLoader(CollectionLoader).initialize(Serializable, SessionImplementor) line: 36
BasicCollectionPersister(AbstractCollectionPersister).initialize(Serializable, SessionImplementor) line: 565
DefaultInitializeCollectionEventListener.onInitializeCollection(InitializeCollectionEvent) line: 60
SessionImpl.initializeCollection(PersistentCollection, boolean) line: 1716
PersistentSet(AbstractPersistentCollection).forceInitialization() line: 454
StatefulPersistenceContext.initializeNonLazyCollections() line: 785
QueryLoader(Loader).doQueryAndInitializeNonLazyCollections(SessionImplementor, QueryParameters, boolean) line: 241
QueryLoader(Loader).doList(SessionImplementor, QueryParameters) line: 2220
QueryLoader(Loader).listIgnoreQueryCache(SessionImplementor, QueryParameters) line: 2104
QueryLoader(Loader).list(SessionImplementor, QueryParameters, Set, Type[]) line: 2099
QueryLoader.list(SessionImplementor, QueryParameters) line: 378
QueryTranslatorImpl.list(SessionImplementor, QueryParameters) line: 338
HQLQueryPlan.performList(QueryParameters, SessionImplementor) line: 172
SessionImpl.list(String, QueryParameters) line: 1121
QueryImpl.list() line: 79
HibQuery.list() line: 60
HibRepository(AbstractRepository).query(IQuery, Class) line: 300
...

While subsequent to this logic, hibernate does close the PreparedStatement and ResultSet instances, since it never removes them from collectionLoadContexts map, those instances are never GCed. After running our application for a couple of days the amount of storage attributed to this potential leak is significant.

Environment

hibernate 3.2.3 with patch from

Activity

Show:
Thomas J. Harris
August 10, 2007, 6:40 AM

I've upgraded to version 3.2.5 GA, and I've come to realize this patch has been included. My question is, why should the cleanup process perform logging at WARN level? Our logs need WARN, and these are filling up our logs. Any chance this could be changed to an INFO?

Emmanuel Bernard
August 10, 2007, 2:15 PM

Use categories to filter

Steve Ebersole
August 14, 2007, 9:29 PM

We are unable to reproduce the warn logging on cleanup. Create a Enhancement Request for lowering the log level with a test case reproducing this behavior...

Bradley Wagner
September 25, 2007, 4:14 PM

We're seeing the same excessive logging after upgrading to Hibernate 3.2.5. When you say you're unable to reproduce it does that mean that you never have any CollectionLoadContext objects to clear when cleaning up (line 108 of org.hibernate.engine.loading.LoadContexts) ?

Gail Badner
September 25, 2007, 8:25 PM

We were able to reproduce this issue. It was fixed in HHH-2795. Please see that ticket for more information.

Assignee

Steve Ebersole

Reporter

Douglas A. Herrick

Fix versions

Labels

None

backPortable

None

Suitable for new contributors

None

Requires Release Note

None

Pull Request

None

backportDecision

None

Components

Affects versions

Priority

Major
Configure