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