On 03/17/2015 11:11 AM, Scott Marlow wrote:
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 
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
Currently, Hibernate 4.3 is building its own Jandex IndexView  but we
could probably build/pass one in (via "hibernate.jandex_index"), so that
Hibernate won't build its own indexes anymore. We discussed doing this
for integrating with Hibernate 5.0 (WFLY-3291) but the same should also
work for 4.3.x.
On 03/15/2015 04:51 PM, Stuart Douglas wrote:
> I started a branch that forces a redeploy on any deployment service
> 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).
> On Mon, 16 Mar 2015 at 02:06 Jason T. Greene <jason.greene(a)redhat.com
> <mailto:firstname.lastname@example.org>> 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.
> Sent from my iPhone
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org <mailto:email@example.com>
> wildfly-dev mailing list
wildfly-dev mailing list