<div dir="ltr">ORM 6.0 introduces changes to how we handle bootstrap-only resource like Jandex to make sure we release hard references to them after we are done bootstrapping the SessionFactory. However, any version prior to that (aka all versions used in any WF releases) do currently hold hard references to it as part of the SessionFactory.<div><br></div><div>So having WF close the Jandex Index (or otherwise release the resource it holds) would be a useful change until WF pulls in 6.0 after it is released.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Nov 7, 2016 at 11:03 AM Scott Marlow <<a href="mailto:smarlow@redhat.com">smarlow@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF" class="gmail_msg">
<p class="gmail_msg"><br class="gmail_msg">
</p>
<br class="gmail_msg">
<div class="m_-5626757689112296441moz-cite-prefix gmail_msg">On 10/27/2016 08:42 AM, Gunnar Morling
wrote:<br class="gmail_msg">
</div>
<blockquote type="cite" class="gmail_msg">
<div dir="ltr" class="gmail_msg">Hi,
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">---</div>
<div class="gmail_msg">TL,DR: Hibernate components would like to receive the
Jandex index during deployment. A new method IndexView#close()
may help to address concerns about long-living index view
references</div>
<div class="gmail_msg">---<br class="gmail_msg">
</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">Different projects from the Hibernate umbrella (e.g. ORM,
Validator and Search) rely heavily on meta-data given via
annotations. In order to speed up annotation retrieval, we are
looking into using the Jandex index created for deployments by
the container.</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">This would require subsystems like JipiJapa or the one for
Bean Validation to pass the IndexView for the deployment to
the bootstrapped component. The change itself should be easy,
I hope. But Scott expressed concerns about components keeping
references to the index after the deployment phase has
succeeded. As indexes can be large, this may potentially
block a big chunk of memory for as long as the deployment is
running.</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">Of course we can promise that Hibernate components wouldn't
keep such references ;) But if that's not enough, could this
concern be mitigated by adding a new method IndexView#close()?</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">This method would free all resources of the index and would
be called by the container after the deployment has finished.
Any operation on a closed index view would throw an exception
indicating that the view has been closed. Then, even if a
component accidentally kept a reference to an IndexView, it
wouldn't retain much memory (of course the index view wouldn't
be of much use to the component in that state).</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">Would that be an acceptable way forward? If so, I could
send a pull request towards Jandex. In a next step WF would
have to make use of that new version and invoke close() on a
deployment's index at a suitable time during the deployment
lifecycle and eventually pass the index to ORM et al.<br class="gmail_msg">
</div>
</div>
</blockquote>
<br class="gmail_msg"></div><div text="#000000" bgcolor="#FFFFFF" class="gmail_msg">
We have been talking about wanting to pass the
"hibernate.jandex_index" into Hibernate ORM, from Jipijapa but
haven't been able to yet since there are no safe guards to ensure
the "hibernate.jandex_index" reference is cleared after application
deployment completes. <br class="gmail_msg">
<br class="gmail_msg">
If an IndexView could be closed, versus just be garbage collected
when there are zero references, it would probably be closed by
something higher up the (deployment) call stack in WildFly, than the
JPA container (or Jipijapa integration code). <br class="gmail_msg">
<br class="gmail_msg">
However, if there are references to the Jandex (partially) loaded
class definitions, those probably also need to be cleared, for us to
benefit from this idea. Just clearing the top down IndexView
reference is probably not enough to reduce memory usage.</div><div text="#000000" bgcolor="#FFFFFF" class="gmail_msg"><br class="gmail_msg">
<br class="gmail_msg">
<blockquote type="cite" class="gmail_msg">
<div dir="ltr" class="gmail_msg"><br class="gmail_msg">
<div class="gmail_msg">In a subsequent step we may consider to address use cases
such as dynamic reconfiguration which would require to access
the index *after* deployment time. One way for addressing this
may be to allow for passing in some kind of executor which
would expect e.g. a Lambda doing work on an IndexView passed
in by the executor. That way components could access the index
at runtime, while not keeping a reference to it themselves and
thus allowing the container to manage the index and e.g. close
or re-open it upon execution. But I think this could be done
as a follow-up.</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">Any thoughts?</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">Thanks,</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">--Gunnar</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
<div class="gmail_msg">PS: As a side note, Hibernate Validator currently reads
annotations lazily at runtime (when first validating a
specific bean type). When using Jandex, we'd have to change
this to eagerly build up all the meta-data for the types
listed in the index passed during bootstrap. A bit of work,
but as said we hope to gain a nice performance improvement
from it.</div>
<div class="gmail_msg"><br class="gmail_msg">
</div>
</div>
<br class="gmail_msg">
<fieldset class="m_-5626757689112296441mimeAttachmentHeader gmail_msg"></fieldset>
<br class="gmail_msg">
<pre class="gmail_msg">_______________________________________________
wildfly-dev mailing list
<a class="m_-5626757689112296441moz-txt-link-abbreviated gmail_msg" href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a>
<a class="m_-5626757689112296441moz-txt-link-freetext gmail_msg" href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a></pre>
</blockquote>
<br class="gmail_msg">
</div>
_______________________________________________<br class="gmail_msg">
wildfly-dev mailing list<br class="gmail_msg">
<a href="mailto:wildfly-dev@lists.jboss.org" class="gmail_msg" target="_blank">wildfly-dev@lists.jboss.org</a><br class="gmail_msg">
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a></blockquote></div>