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