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 https://lists.jboss.org/mailman/listinfo/wildfly-dev

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 > _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

> > Currently, Hibernate 4.3 is building its own Jandex IndexView [2] 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. > We cannot pass our Jandex indexes into Hibernate until the deployment-service-restart changes are merged into WildFly (or something like that). On a partial restart, we will need access to the Jandex indexes, which need to be rebuilt (as already pointed out by Jason on this thread).

_______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

On Tue, Mar 17, 2015 at 07:13:37PM -0400, Scott Marlow wrote: > Currently, Hibernate 4.3 is building its own Jandex IndexView [2] 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. Interesting, afair 4.3 does not use Jandex. I wonder whether there is really a need for Jandex in 4.3? I can see it contains the metamodel code, but that could be removed afaiu.

--Hardy