[
https://issues.apache.org/jira/browse/OAK-3301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14718297#comment-14718297
]
Robert Munteanu edited comment on OAK-3301 at 8/28/15 9:58 AM:
---------------------------------------------------------------
{quote}IIRC the fields are static because they hold the source repository (JR2)
for an upgrade. Since this is somewhat expensive to set up it makes some sense
to cache it statically{quote}
Right, that makes sense.
{quote}Maybe an @Rule can help achieve the same goal.{quote}
{{@Rule}} s are only available for instance fields, and {{@ClassRule}} s have
to be static anyway ...
I tried to make everything instance-based, but I got more than I bargained for.
Some tests break when everything is instance-based, due to the combination of
overriding super-class methods which assume that everything is already
initialised.
For instance
[RepeatedRepositorySidegradeTest.createTargetNodeStore|https://github.com/apache/jackrabbit-oak/blob/1b6e52242be61c162be4b1f1280d6545cc489d37/oak-upgrade/src/test/java/org/apache/jackrabbit/oak/upgrade/RepeatedRepositoryUpgradeTest.java#L61-L63]
is called from a {{@Before}} method in the superclass but requires a field
which is (with my experimental changes) initialised in another {{@Before}}
method, which happens too late.
My conclusion is that this would require a larger change than I'm able to
provide now, so my suggestion would be to apply the minimal change and fix the
leak. ( cc [~alex.parvulescu] )
was (Author: rombert):
{quote}IIRC the fields are static because they hold the source repository (JR2)
for an upgrade. Since this is somewhat expensive to set up it makes some sense
to cache it statically{quote}
Right, that makes sense.
{quote}Maybe an @Rule can help achieve the same goal.{quote}
{{@Rule}}s are only available for instance fields, and {{@ClassRule}}s have to
be static anyway ... I tried to make everything instance-based, but I got more
than I bargained for. Some tests break when everything is based, due to the
combination of overriding super-class methods which assume that everything is
already initialised. For instance
[RepeatedRepositorySidegradeTest.createTargetNodeStore|https://github.com/apache/jackrabbit-oak/blob/1b6e52242be61c162be4b1f1280d6545cc489d37/oak-upgrade/src/test/java/org/apache/jackrabbit/oak/upgrade/RepeatedRepositoryUpgradeTest.java#L61-L63]
is called from a {{@Before}} method in the superclass but requires a field
which is (with my experimental changes) initialised in another {{@Before}}
method, which happens too late. My conclusion is that this would require a
larger change than I'm able to provide now, so my suggestion would be to apply
the minimal change and fix the leak. ( cc [~alex.parvulescu] )
> AbstractRepositoryUpgrade leaks Repository instances
> ----------------------------------------------------
>
> Key: OAK-3301
> URL: https://issues.apache.org/jira/browse/OAK-3301
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: upgrade
> Reporter: Robert Munteanu
> Fix For: 1.4
>
> Attachments:
> 0001-OAK-3301-AbstractRepositoryUpgrade-leaks-Repository-.patch
>
>
> AbstractRepositoryUpgradeTest creates (JCR) repository instances but does not
> close them ( actually creates a repository each time a session is requested ).
> This leads to out of memory errors when the process limit is hit on a machine.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)