[Hibernate-JIRA] Created: (HHH-2631) Leaking PreparedStatement and ResultSet via CollectionLoadContext instances maintained in Map collectionLoadContexts in LoadContexts
4:20 a.m.
Leaking PreparedStatement and ResultSet via CollectionLoadContext instances maintained in
Map collectionLoadContexts in LoadContexts
------------------------------------------------------------------------------------------------------------------------------------
Key: HHH-2631
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2631
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.3
Environment: hibernate 3.2.3 with patch from HHH-2553
Reporter: Douglas A. Herrick
Priority: Critical
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:29 p.m.
New subject: [Hibernate-JIRA] Updated: (HHH-2631) Leaking PreparedStatement and ResultSet via CollectionLoadContext instances maintained in Map collectionLoadContexts in LoadContexts
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2631?page=c...
]
Steve Ebersole updated HHH-2631:
--------------------------------
Priority: Major (was: Critical)
Assignee: Steve Ebersole
Affects Version/s: (was: 3.2.3)
3.2.4
Fix Version/s: 3.3
3.2.5
Leaking PreparedStatement and ResultSet via CollectionLoadContext
instances maintained in Map collectionLoadContexts in LoadContexts
------------------------------------------------------------------------------------------------------------------------------------
Key: HHH-2631
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2631
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.4
Environment: hibernate 3.2.3 with patch from HHH-2553
Reporter: Douglas A. Herrick
Assignee: Steve Ebersole
Fix For: 3.2.5, 3.3
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:50 p.m.
New subject: [Hibernate-JIRA] Updated: (HHH-2631) Leaking PreparedStatement and ResultSet via CollectionLoadContext instances maintained in Map collectionLoadContexts in LoadContexts
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2631?page=c...
]
Gail Badner updated HHH-2631:
-----------------------------
Attachment: HHH-2631.patch
I am attaching a patch that removes references to ResultSet objects from
CollectionLoadContext and LoadContexts when they are no longer needed, and removes
CollectionKey objects from CollectionLoadContext.localLoadingCollectionKeys as they are
processed by CollectionLoadContext.endLoadingCollections(CollectionPersister persister).
In CollectionLoadContext.endLoadingCollections(CollectionPersister persister), I noticed
that it would be more efficient to iterate over localLoadingCollectionKeys rather than
loadContexts.getLoadingCollectionEntryMap().entrySet(), since it can be a much smaller set
and each element will refer to a collection being loaded from the relevant ResultSet. This
patch makes this change in iterator.
I used loadContexts.locateLoadingCollectionEntry( collectionKey ) to get the
LoadingCollectionEntry. When a match in Persister and ResultSet is found, iter.remove()
removes the CollectionKey from localLoadingCollectionKeys and a new method,
loadContexts.unregisterLoadingCollectionEntry( collectionKey ), is called to remove the
entry from the cross-reference map in loadContexts.
When all elements of localLoadingCollectionKeys have been removed, then all collections
that are loaded from the ResultSet have been processed and the CollectionLoadContext
object (and its ResultSet reference) is no longer needed. A new method,
loadContexts.removeCollectionLoadContext(this), is called to remove the two references to
the ResultSet object in loadContexts.collectionLoadContexts (the key and in the
CollectionLoadContext value).
I'm not completely sure that it is appropriate to remove the CollectionLoadContext
from loadContexs.collectionLoadContexts after the last CollectionKey in
localLoadingCollectionKeys is processed. Would it be better to call LoadContexts.cleanup()
when the session is being closed?
I've verified that no unit tests are broken by this patch.
Leaking PreparedStatement and ResultSet via CollectionLoadContext
instances maintained in Map collectionLoadContexts in LoadContexts
------------------------------------------------------------------------------------------------------------------------------------
Key: HHH-2631
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2631
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.4
Environment: hibernate 3.2.3 with patch from HHH-2553
Reporter: Douglas A. Herrick
Assignee: Steve Ebersole
Fix For: 3.2.5, 3.3
Attachments: HHH-2631.patch
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:54 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-2631) Leaking PreparedStatement and ResultSet via CollectionLoadContext instances maintained in Map collectionLoadContexts in LoadContexts
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2631?page=c...
]
Douglas A. Herrick commented on HHH-2631:
-----------------------------------------
"Would it be better to call LoadContexts.cleanup() when the session is being
closed?"
That would seem to be a solution that would cover all bases, including possible exceptions
that might have prevented invocation of the logic you added to remove individual elements
from collectionLoadContexts.
Leaking PreparedStatement and ResultSet via CollectionLoadContext
instances maintained in Map collectionLoadContexts in LoadContexts
------------------------------------------------------------------------------------------------------------------------------------
Key: HHH-2631
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2631
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.4
Environment: hibernate 3.2.3 with patch from HHH-2553
Reporter: Douglas A. Herrick
Assignee: Steve Ebersole
Fix For: 3.2.5, 3.3
Attachments: HHH-2631.patch
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:30 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-2631) Leaking PreparedStatement and ResultSet via CollectionLoadContext instances maintained in Map collectionLoadContexts in LoadContexts
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2631?page=c...
]
Douglas A. Herrick commented on HHH-2631:
-----------------------------------------
...actually, since the ResultSet and PreparedStatement would be moribund after commit, I
believe that would be an appropriate time to invoke cleanup().
Leaking PreparedStatement and ResultSet via CollectionLoadContext
instances maintained in Map collectionLoadContexts in LoadContexts
------------------------------------------------------------------------------------------------------------------------------------
Key: HHH-2631
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2631
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.4
Environment: hibernate 3.2.3 with patch from HHH-2553
Reporter: Douglas A. Herrick
Assignee: Steve Ebersole
Fix For: 3.2.5, 3.3
Attachments: HHH-2631.patch
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:37 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-2631) Leaking PreparedStatement and ResultSet via CollectionLoadContext instances maintained in Map collectionLoadContexts in LoadContexts
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2631?page=c...
]
Steve Ebersole commented on HHH-2631:
-------------------------------------
The basic (simplified) idea of a "load context" is contextual scoping of
information relating to the processing of a result set. In an ideal scenario, I'd
actually have each entry in the two main maps available *as part of the result-set*; then
when a result-set closes, it can make sure these entries get cleaned up. Long term that
may actually be an option; nested loader stacks make it "interesting"...
But for now, given the current codebase, the desire would be to release these resources as
the result sets are being closed as a way to approximate the above discussion. There are
two main candidates:
1) as part of the specific Loader methods controlling the result sets (doQuery,
sequentialLoad, etc)
2) as part of the Batcher code.
I'm not a big fan of #2 (I'm not really a big fan of the current batchers at all),
but mention it because it would give that "central point" to do this processing
provider all the pertinent loader calls are using the Batcher correctly. My plan, then,
is to investigate #1...
And Gail, to answer your specific question, I think calling cleanup on session closing is
a great fail-safe.
Leaking PreparedStatement and ResultSet via CollectionLoadContext
instances maintained in Map collectionLoadContexts in LoadContexts
------------------------------------------------------------------------------------------------------------------------------------
Key: HHH-2631
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2631
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.4
Environment: hibernate 3.2.3 with patch from HHH-2553
Reporter: Douglas A. Herrick
Assignee: Steve Ebersole
Fix For: 3.2.5, 3.3
Attachments: HHH-2631.patch
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:18 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-2631) Leaking PreparedStatement and ResultSet via CollectionLoadContext instances maintained in Map collectionLoadContexts in LoadContexts
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2631?page=c...
]
Steve Ebersole commented on HHH-2631:
-------------------------------------
Ok, so here is what I am thinking in terms of implementing:
1) LoadContext already has a cleanup(ResultSet) method; unfortunately it is not used.
Clearly this is something I planned to do, but did not do :( Anyway, this just needs to
get called when we are done processing the given result sets. The trigger for that should
all come from a (a) few finite methods on Loader and (b) the cleanup code in
ScrollableResults and IteratorImpl (see discussion #1 below)
2) Add a LoadContext.cleanup() method to be used as the fail-safe. This new method will
be called from SessionImpl on cleaning up the Session. I do not think we can do this in
the transaction completion code because it is possible (depending on the db ) to have
result sets span a transaction; the condition I am worried about is iterate() and scroll()
queries, which keep the result sets open until explicitly done with. Anyway, coupled with
#1, this really truly should be a fail-safe. I'll also do some warn logging during
that process if there are still associated result-sets
Leaking PreparedStatement and ResultSet via CollectionLoadContext
instances maintained in Map collectionLoadContexts in LoadContexts
------------------------------------------------------------------------------------------------------------------------------------
Key: HHH-2631
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2631
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.4
Environment: hibernate 3.2.3 with patch from HHH-2553
Reporter: Douglas A. Herrick
Assignee: Steve Ebersole
Fix For: 3.2.5, 3.3
Attachments: HHH-2631.patch
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:26 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-2631) Leaking PreparedStatement and ResultSet via CollectionLoadContext instances maintained in Map collectionLoadContexts in LoadContexts
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2631?page=c...
]
Steve Ebersole commented on HHH-2631:
-------------------------------------
Actually on second thought, I decided to go ahead with Gail's approach for this
currently. Since I plan on this part of the code changing drastically in the near future,
I'm not gonna expand a lot of effort tracking down all the contexts from which
CollectionLoadContexts actually get created (I know the places from which they *should*
get created...).
Anyway, I have attached my patch against the current 3.2 branch. It is also checked in to
both the 3.2 branch and trunk.
Leaking PreparedStatement and ResultSet via CollectionLoadContext
instances maintained in Map collectionLoadContexts in LoadContexts
------------------------------------------------------------------------------------------------------------------------------------
Key: HHH-2631
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2631
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.4
Environment: hibernate 3.2.3 with patch from HHH-2553
Reporter: Douglas A. Herrick
Assignee: Steve Ebersole
Fix For: 3.2.5, 3.3
Attachments: HHH-2631.patch
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:32 a.m.
New subject: [Hibernate-JIRA] Updated: (HHH-2631) Leaking PreparedStatement and ResultSet via CollectionLoadContext instances maintained in Map collectionLoadContexts in LoadContexts
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2631?page=c...
]
Steve Ebersole updated HHH-2631:
--------------------------------
Attachment: hhh-2631.patch
Leaking PreparedStatement and ResultSet via CollectionLoadContext
instances maintained in Map collectionLoadContexts in LoadContexts
------------------------------------------------------------------------------------------------------------------------------------
Key: HHH-2631
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2631
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.4
Environment: hibernate 3.2.3 with patch from HHH-2553
Reporter: Douglas A. Herrick
Assignee: Steve Ebersole
Fix For: 3.2.5, 3.3
Attachments: hhh-2631.patch, HHH-2631.patch
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:48 a.m.
New subject: [Hibernate-JIRA] Updated: (HHH-2631) Leaking PreparedStatement and ResultSet via CollectionLoadContext instances maintained in Map collectionLoadContexts in LoadContexts
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2631?page=c...
]
Steve Ebersole updated HHH-2631:
--------------------------------
Attachment: (was: hhh-2631.patch)
Leaking PreparedStatement and ResultSet via CollectionLoadContext
instances maintained in Map collectionLoadContexts in LoadContexts
------------------------------------------------------------------------------------------------------------------------------------
Key: HHH-2631
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2631
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.4
Environment: hibernate 3.2.3 with patch from HHH-2553
Reporter: Douglas A. Herrick
Assignee: Steve Ebersole
Fix For: 3.2.5, 3.3
Attachments: HHH-2631.patch
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
3 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-2631) Leaking PreparedStatement and ResultSet via CollectionLoadContext instances maintained in Map collectionLoadContexts in LoadContexts
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2631?page=c...
]
Douglas A. Herrick commented on HHH-2631:
-----------------------------------------
Steve,
So, in summary, Gail's original patch stands as is for 3.2.4. Is this correct?
Thanks,
Doug
Leaking PreparedStatement and ResultSet via CollectionLoadContext
instances maintained in Map collectionLoadContexts in LoadContexts
------------------------------------------------------------------------------------------------------------------------------------
Key: HHH-2631
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2631
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.4
Environment: hibernate 3.2.3 with patch from HHH-2553
Reporter: Douglas A. Herrick
Assignee: Steve Ebersole
Fix For: 3.2.5, 3.3
Attachments: HHH-2631.patch
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:18 a.m.
New subject: [Hibernate-JIRA] Updated: (HHH-2631) Leaking PreparedStatement and ResultSet via CollectionLoadContext instances maintained in Map collectionLoadContexts in LoadContexts
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2631?page=c...
]
Steve Ebersole updated HHH-2631:
--------------------------------
Attachment: hhh-2631.patch
Leaking PreparedStatement and ResultSet via CollectionLoadContext
instances maintained in Map collectionLoadContexts in LoadContexts
------------------------------------------------------------------------------------------------------------------------------------
Key: HHH-2631
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2631
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.4
Environment: hibernate 3.2.3 with patch from HHH-2553
Reporter: Douglas A. Herrick
Assignee: Steve Ebersole
Fix For: 3.2.5, 3.3
Attachments: hhh-2631.patch, HHH-2631.patch
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:22 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-2631) Leaking PreparedStatement and ResultSet via CollectionLoadContext instances maintained in Map collectionLoadContexts in LoadContexts
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2631?page=c...
]
Steve Ebersole commented on HHH-2631:
-------------------------------------
Sorry, I got side-tracked.
No; well sorta. I just attached a patch which represents what I am committing to svn. It
is basically Gail's patch ++ (like the failsafe cleanup and explicit cleanup from
scrollableresults and iteratorimpl), along with the fact that I javadoc'ed some of the
stuff better and re-orged the code a bit. At the least it is Gail's patch plus the
"fail-safe" cleanup (from StatefulPersistenceContext).
Leaking PreparedStatement and ResultSet via CollectionLoadContext
instances maintained in Map collectionLoadContexts in LoadContexts
------------------------------------------------------------------------------------------------------------------------------------
Key: HHH-2631
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2631
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.4
Environment: hibernate 3.2.3 with patch from HHH-2553
Reporter: Douglas A. Herrick
Assignee: Steve Ebersole
Fix For: 3.2.5, 3.3
Attachments: hhh-2631.patch, HHH-2631.patch
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-2631) Leaking PreparedStatement and ResultSet via CollectionLoadContext instances maintained in Map collectionLoadContexts in LoadContexts
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2631?page=c...
]
Shawn Clowater commented on HHH-2631:
-------------------------------------
Ok, it looks like someone else found this before I did today, couldn't figure out why
my memory was creeping and creeping during a long batch process even though I was clearing
the session.
Sanity check, I'm running on 3.2.4 right now and all I did to get around this today
was call clear on the hashmaps in LoadContexts when the PersistentContext is cleared.
Should this ghetto rigging cause me any undue grief? We're about to ship a release
out the door and I'd rather not swap the guts out of our hib layer if I don't have
to.
Checking the patch code it looks like you're cleaning up each Entity and Collection
LoadContext one by one and clearing some internal refs in it which should get me to the
same point I think.
Leaking PreparedStatement and ResultSet via CollectionLoadContext
instances maintained in Map collectionLoadContexts in LoadContexts
------------------------------------------------------------------------------------------------------------------------------------
Key: HHH-2631
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2631
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.4
Environment: hibernate 3.2.3 with patch from HHH-2553
Reporter: Douglas A. Herrick
Assignee: Steve Ebersole
Fix For: 3.2.5, 3.3
Attachments: hhh-2631.patch, HHH-2631.patch
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:45 p.m.
New subject: [Hibernate-JIRA] Closed: (HHH-2631) Leaking PreparedStatement and ResultSet via CollectionLoadContext instances maintained in Map collectionLoadContexts in LoadContexts
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2631?page=c...
]
Steve Ebersole closed HHH-2631.
-------------------------------
Resolution: Fixed
Leaking PreparedStatement and ResultSet via CollectionLoadContext
instances maintained in Map collectionLoadContexts in LoadContexts
------------------------------------------------------------------------------------------------------------------------------------
Key: HHH-2631
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2631
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.4
Environment: hibernate 3.2.3 with patch from HHH-2553
Reporter: Douglas A. Herrick
Assignee: Steve Ebersole
Fix For: 3.2.5, 3.3
Attachments: hhh-2631.patch, HHH-2631.patch
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:41 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-2631) Leaking PreparedStatement and ResultSet via CollectionLoadContext instances maintained in Map collectionLoadContexts in LoadContexts
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2631?page=c...
]
Thomas J. Harris commented on HHH-2631:
---------------------------------------
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?
Leaking PreparedStatement and ResultSet via CollectionLoadContext
instances maintained in Map collectionLoadContexts in LoadContexts
------------------------------------------------------------------------------------------------------------------------------------
Key: HHH-2631
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2631
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.4
Environment: hibernate 3.2.3 with patch from HHH-2553
Reporter: Douglas A. Herrick
Assignee: Steve Ebersole
Fix For: 3.2.5, 3.3
Attachments: hhh-2631.patch, HHH-2631.patch
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:16 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-2631) Leaking PreparedStatement and ResultSet via CollectionLoadContext instances maintained in Map collectionLoadContexts in LoadContexts
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2631?page=c...
]
Emmanuel Bernard commented on HHH-2631:
---------------------------------------
Use categories to filter
Leaking PreparedStatement and ResultSet via CollectionLoadContext
instances maintained in Map collectionLoadContexts in LoadContexts
------------------------------------------------------------------------------------------------------------------------------------
Key: HHH-2631
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2631
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.4
Environment: hibernate 3.2.3 with patch from HHH-2553
Reporter: Douglas A. Herrick
Assignee: Steve Ebersole
Fix For: 3.2.5, 3.3
Attachments: hhh-2631.patch, HHH-2631.patch
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:31 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-2631) Leaking PreparedStatement and ResultSet via CollectionLoadContext instances maintained in Map collectionLoadContexts in LoadContexts
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2631?page=c...
]
Steve Ebersole commented on HHH-2631:
-------------------------------------
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...
Leaking PreparedStatement and ResultSet via CollectionLoadContext
instances maintained in Map collectionLoadContexts in LoadContexts
------------------------------------------------------------------------------------------------------------------------------------
Key: HHH-2631
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2631
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.4
Environment: hibernate 3.2.3 with patch from HHH-2553
Reporter: Douglas A. Herrick
Assignee: Steve Ebersole
Fix For: 3.2.5, 3.3
Attachments: hhh-2631.patch, HHH-2631.patch
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:15 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-2631) Leaking PreparedStatement and ResultSet via CollectionLoadContext instances maintained in Map collectionLoadContexts in LoadContexts
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2631?page=c...
]
Bradley Wagner commented on HHH-2631:
-------------------------------------
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) ?
Leaking PreparedStatement and ResultSet via CollectionLoadContext
instances maintained in Map collectionLoadContexts in LoadContexts
------------------------------------------------------------------------------------------------------------------------------------
Key: HHH-2631
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2631
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.4
Environment: hibernate 3.2.3 with patch from HHH-2553
Reporter: Douglas A. Herrick
Assignee: Steve Ebersole
Fix For: 3.2.5, 3.3
Attachments: hhh-2631.patch, HHH-2631.patch
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:26 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-2631) Leaking PreparedStatement and ResultSet via CollectionLoadContext instances maintained in Map collectionLoadContexts in LoadContexts
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2631?page=c...
]
Gail Badner commented on HHH-2631:
----------------------------------
We were able to reproduce this issue. It was fixed in HHH-2795. Please see that ticket for
more information.
Leaking PreparedStatement and ResultSet via CollectionLoadContext
instances maintained in Map collectionLoadContexts in LoadContexts
------------------------------------------------------------------------------------------------------------------------------------
Key: HHH-2631
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2631
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.4
Environment: hibernate 3.2.3 with patch from HHH-2553
Reporter: Douglas A. Herrick
Assignee: Steve Ebersole
Fix For: 3.2.5, 3.3
Attachments: hhh-2631.patch, HHH-2631.patch
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6070
days inactive
6195
days old
hibernate-issues@lists.jboss.org
19 comments
7 participants
participants (7)
-
Bradley Wagner (JIRA) -
Douglas A. Herrick (JIRA)
-
Emmanuel Bernard (JIRA)
-
Gail Badner (JIRA)
-
Shawn Clowater (JIRA)
-
Steve Ebersole (JIRA)
-
Thomas J. Harris (JIRA)