Our JPA container is only caching the Jandex indexes for restart of
Hibernate ORM versions less than 4.3.0. Once the caching is no longer
needed (deployment-service-restart is merged in), we should update [1]
to not cache the jandex indexes anymore. We don't do any Jandex index
caching for the default Hibernate ORM 4.3.8 version in WildFly 9.0 today.
We might pass the Jandex indexes into Hibernate 5.0, which is something
we talked about doing a while back (via "hibernate.jandex_index"
integration map property). I'll check to make sure that Hibernate ORM
5.0, doesn't keep a reference to the Jandex indexes after deployment
completes (since we won't be able to pass "hibernate.jandex_index" in if
it does).
Scott
[1]
https://github.com/jipijapa/jipijapa/blob/master/hibernate4_1/src/main/ja...
On 03/15/2015 04:51 PM, Stuart Douglas wrote:
I started a branch that forces a redeploy on any deployment service
restart:
https://github.com/wildfly/wildfly-core/compare/master...stuartwdouglas:d...
It does break some singleton functionality though, although that should
be easy enough to work around (perhaps some kind of marker interface to
mark services as restartable).
Stuart
On Mon, 16 Mar 2015 at 02:06 Jason T. Greene <jason.greene(a)redhat.com
<mailto:jason.greene@redhat.com>> wrote:
Currently we are a bit inconsistent with whether or not partial
deployment services are allowed to restart. This is because most
require metadata that is intended to be temporary and is intended to
be wiped out at the end of deployment. A major exception is JPA
which is holding on to jandex annotation indexes, so that if its
underlying JCA datasource bounces, it's able to restart.
This is bad though because it wastes more memory than is actually
needed (the state that JPA requires is less than the combined state
of all annotation indexes and other deployment info). It's
particular bad when we upgrade to jandex 2 since it stores a lot
more information (generics, all method and field signatures, type
annotations etc).
IMO based on this inconsistency and the time we have on the
schedule, I think we need to momentarily suspend the not really
attained goal of partial restart-ability. We should change JPA to
stop keeping a hard reference to the indexes, and once that service
goes down, a full redeployment is required. Stuart has a hack that
can restart this automatically as part of a listener. We should
probably look at extending this further.
Longer term I think we need to redesign the deployment service
hierarchy to better represent the reality that restarting a portion
deployment requires rerunning the initial scanning phases.
Thoughts?
Sent from my iPhone
_________________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
https://lists.jboss.org/__mailman/listinfo/wildfly-dev
<
https://lists.jboss.org/mailman/listinfo/wildfly-dev>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev