11:45 p.m.
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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>