You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Christian Schröder <ne...@l7010.de> on 2009/04/07 10:29:28 UTC
ConnectionRecoveryManager collecting all PreparedStatements
Hello,
i'am wondering if it is intended that ConnectionRecoveryManager collects
all PreparedStatements ever done and never removes them at all.
I suspect this could lead to memory leak problems in the long run.
It seams the preparedStatements Map inside
org.apache.jackrabbit.core.persistence.bundle.util.ConnectionRecoveryManager
is used as a cache. If so it really should have an eviction strategy and
a maximum size. Otherwise it should leak sometime in my understanding.
Just stumbled over it because of
https://sourceforge.net/tracker/?func=detail&aid=2728324&group_id=111957&atid=660861
where this behaviour means serious trouble together with the filed bug
in ha-jdbc :)
Maybe i have overlooked something, thats why i didn't file a bug report.
regards
Christian
Re: ConnectionRecoveryManager collecting all PreparedStatements
Posted by Thomas Müller <th...@day.com>.
Hi,
As far as I know, the number of distinct prepared statements is fixed
and quite small. So I believe it should not be a problem (as far as
Jackrabbit is concerned).
Regards,
Thomas
On Tue, Apr 7, 2009 at 10:29 AM, Christian Schröder <ne...@l7010.de> wrote:
> Hello,
> i'am wondering if it is intended that ConnectionRecoveryManager collects
> all PreparedStatements ever done and never removes them at all.
>
> I suspect this could lead to memory leak problems in the long run.
>
> It seams the preparedStatements Map inside
> org.apache.jackrabbit.core.persistence.bundle.util.ConnectionRecoveryManager
> is used as a cache. If so it really should have an eviction strategy and
> a maximum size. Otherwise it should leak sometime in my understanding.
>
> Just stumbled over it because of
> https://sourceforge.net/tracker/?func=detail&aid=2728324&group_id=111957&atid=660861
> where this behaviour means serious trouble together with the filed bug
> in ha-jdbc :)
>
> Maybe i have overlooked something, thats why i didn't file a bug report.
>
> regards
> Christian
>
>
>
Re: ConnectionRecoveryManager collecting all PreparedStatements
Posted by Thomas Müller <th...@day.com>.
Hi,
> So if the connection stays open all time the statements will never be
> released and so they will never be gc'ed.
As I said, there is a fixed and small set of distinct statements. This
doesn't require much memory, and it's a lot faster to keep the
(prepared) statements open than to re-create them.
> But nevertheless it is a possible leak, in the case when the connection
> will not close.
If the application forgets to close all sessions, the session is
garbage collected eventually, and then the statements are garbage
collected when the repository is closed.
Regards,
Thomas
Re: ConnectionRecoveryManager collecting all PreparedStatements
Posted by Christian Schröder <ne...@l7010.de>.
Stefan Guggisberg schrieb:
>> i'am wondering if it is intended that ConnectionRecoveryManager collects
>> all PreparedStatements ever done and never removes them at all.
>
> the hashmap keeping track of the PreparedStatement instances is cleared
> on reconnect. all previously created PreparedStatement instances are now
> subject to be gc'ed. IMO a reasonable PreparedStatement implementation
> will free all bond resources once an instance is finalized. at least so far
> we haven't experienced any related issues. please create a jira issue if you do
> experience reasource leakage issues with a specific jdbc driver.
So if the connection stays open all time the statements will never be
released and so they will never be gc'ed. Right now this is more of a
theoretical problem, because it only surfaced in combination with the
not correctly working ha-jdbc driver.
But nevertheless it is a possible leak, in the case when the connection
will not close.
I do not mind now, just wanted to be sure i understood this correctly.
regards
Christian
Re: ConnectionRecoveryManager collecting all PreparedStatements
Posted by Stefan Guggisberg <st...@gmail.com>.
On Tue, Apr 7, 2009 at 10:29 AM, Christian Schröder <ne...@l7010.de> wrote:
> Hello,
> i'am wondering if it is intended that ConnectionRecoveryManager collects
> all PreparedStatements ever done and never removes them at all.
>
> I suspect this could lead to memory leak problems in the long run.
>
> It seams the preparedStatements Map inside
> org.apache.jackrabbit.core.persistence.bundle.util.ConnectionRecoveryManager
> is used as a cache. If so it really should have an eviction strategy and
> a maximum size. Otherwise it should leak sometime in my understanding.
the hashmap keeping track of the PreparedStatement instances is cleared
on reconnect. all previously created PreparedStatement instances are now
subject to be gc'ed. IMO a reasonable PreparedStatement implementation
will free all bond resources once an instance is finalized. at least so far
we haven't experienced any related issues. please create a jira issue if you do
experience reasource leakage issues with a specific jdbc driver.
cheers
stefan
>
> Just stumbled over it because of
> https://sourceforge.net/tracker/?func=detail&aid=2728324&group_id=111957&atid=660861
> where this behaviour means serious trouble together with the filed bug
> in ha-jdbc :)
>
> Maybe i have overlooked something, thats why i didn't file a bug report.
>
> regards
> Christian
>
>
>