Making Jandex annotation index available to components

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Making Jandex annotation index available to components

Gunnar Morling
Hi,

---
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
---

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.

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.

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()?

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).

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.

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.

Any thoughts?

Thanks,

--Gunnar

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.


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Making Jandex annotation index available to components

Scott Marlow



On 10/27/2016 08:42 AM, Gunnar Morling wrote:
Hi,

---
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
---

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.

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.

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()?

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).

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.

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. 

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). 

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.


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.

Any thoughts?

Thanks,

--Gunnar

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.



_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Making Jandex annotation index available to components

Steve Ebersole
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.

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.


On Mon, Nov 7, 2016 at 11:03 AM Scott Marlow <[hidden email]> wrote:



On 10/27/2016 08:42 AM, Gunnar Morling wrote:
Hi,

---
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
---

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.

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.

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()?

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).

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.

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. 

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). 

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.



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.

Any thoughts?

Thanks,

--Gunnar

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.



_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Making Jandex annotation index available to components

Scott Marlow
In reply to this post by Gunnar Morling



On 10/27/2016 08:42 AM, Gunnar Morling wrote:
Hi,

---
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
---

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.

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.

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()?

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).

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.

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.

A related question might be if creating a Jandex Index after application deployment completes, could be backed by the application classloader defined classes and whether that would be memory space efficient enough for runtime use.


Any thoughts?

Thanks,

--Gunnar

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.



_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Loading...