[wildfly-dev] WF10 Deployment Changes

[Scott Marlow]

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 [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).

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.

Scott

[2] 
https://github.com/hibernate/hibernate-orm/blob/4.3/hibernate-entitymanager/src/main/java/org/hibernate/jpa/boot/internal/EntityManagerFactoryBuilderImpl.java

>
> Scott
>
> [1]
> https://github.com/jipijapa/jipijapa/blob/master/hibernate4_1/src/main/java/org/jboss/as/jpa/hibernate4/HibernateAnnotationScanner.java#L55
>
> 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:deployment-service-restart
>>
>> 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 at redhat.com
>> <mailto:jason.greene at 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 at lists.jboss.org <mailto:wildfly-dev at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>