I'm trying to grok what impact this have on endusers ?
do they need to wait longer/less/same as before when certain
changes/deployments occur ?
/max
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