[bv-dev] Caching of provider resolvers

[Marco Molteni]

Hi Gunnar,

> how Apache BVAL deals with this (via geronimo-validation-spec), e.g.
> within TomEE?

Not sure if it can help. It seems that there is no caching:
https://github.com/apache/bval/blob/bval-11/bval-jsr/
src/main/java/org/apache/bval/jsr/DefaultValidationProviderResolver.java


> Nevertheless this can cause the memory to be retained for a long time,
> esp. in an application server it may cause a reference to application
> class loaders be retained if a validation provider has been obtained
> from a deployment

I think in most of the use cases there is one application per
server/container and the server/container is restarted at each deploy. For
these cases there is no issue.

> Thus my preferred way for addressing this issue is to
> declare a non-public method such as releaseProviderCache()
> [...] In a future version of BV we could consider to make this a public
API,

Ok for me. This is not a regression from BV 1.1 and there is a workaround
until the next version of BV.

> [Scott, from JIRA] My vote is to keep good performance by default (e.g.
keep the caching) but address the problem that we are caching things that
we > don't know when to release from the cache.

Totally agree.


Marco


On Tue, Jun 13, 2017 at 4:41 PM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> All,
>
> We've come across an issue related to bootstrapping BV providers in
> application servers and I'd be interested in your ideas around it.
>
> The issue (BVAL-551 [1]) is about the javax.validation.Validation
> class and the way it loads -- and caches -- validation providers.
> j.v.Validation is essentially the only class in the entire API with
> some actual implementation, so it's a bit special in that way.
>
> The validation-api.jar we provide alongside the RI maintains a cache
> of resolved validation providers [2], this is to avoid repeated
> look-ups via the service loader. In order to avoid any memory leaks,
> this is implemented as a weak map with soft references as values. This
> guarantees this map to be freed before an OutOfMemoryError occurs.
> Nevertheless this can cause the memory to be retained for a long time,
> esp. in an application server it may cause a reference to application
> class loaders be retained if a validation provider has been obtained
> from a deployment (again, eventually, that reference will be
> released).
>
> For that case it'd be beneficial to have a way to pro-actively flush
> that cache upon application undeployment. Now the thing is that the BV
> API and the docs of j.v.Validation don't make any assumption on the
> implementation and naturally there's no public notion of such caching
> part of the API. Thus my preferred way for addressing this issue is to
> declare a non-public method such as releaseProviderCache() in
> j.v.Validation of our validation-api.jar. This method wouldn't be part
> of the specified API. Interested application servers could call that
> method reflectively as needed.
>
> In a future version of BV we could consider to make this a public API,
> e.g. there could be Validation#getDefaultProviderResolver() and a new
> default method ValidationProviderResolver#release() which could be
> called to release any resources hold by a provider resolver (the cache
> is hold within the default implementation of ProviderResolver).
> Theoretically, this could also added to BV 2.0, but I feel it's a bit
> rushed and I'd rather gather some experiences with this very special
> purpose functionality before committing to it as part of the spec.
>
> Any thoughts on this one would be highly welcomed. Does anyone know
> how Apache BVAL deals with this (via geronimo-validation-spec), e.g.
> within TomEE?
>
> Thanks,
>
> --Gunnar
>
> [1] https://hibernate.atlassian.net/browse/BVAL-551
> [2] https://github.com/beanvalidation/beanvalidation-api/blob/
> master/src/main/java/javax/validation/Validation.java#L317
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170613/e9c241c4/attachment.html