[jboss-as7-dev] Update to deferred resolve and start/stop

[Thomas Diesler]

On 09/20/2012 02:29 PM, Scott Marlow wrote:
> On 09/20/2012 09:18 AM, Thomas Diesler wrote:
>> Folks,
>>
>> I rebased the as2777 <https://github.com/tdiesler/jboss-as/tree/as2777>
>> branch on the current as3694
>> <https://github.com/tdiesler/jboss-as/tree/as3694> approach.
>>
>> This integrates with the CLI and you can do
>>
>>          <deployment name="simple.war" runtime-name="simple.war">
>>              <content sha1="be6f7ba1ceaa2028c86d080648e1467904999f8e"/>
>>              <properties>
>>                 <property name="start.policy" value="deferred"/>
>>              </properties>
>>          </deployment>
>>
>> [tdiesler at tdvaio jboss-as-7.2.0.Alpha1-SNAPSHOT]$ bin/jboss-cli.sh 
>> --connect
>> [standalone at localhost:9999 /] start simple.war
>> [standalone at localhost:9999 /] stop simple.war
>>
>> on the server you should see
>>
>> 08:56:30,002 INFO  [org.jboss.web] (MSC service thread 1-2) JBAS018210:
>> Register web context: /simple
>> 08:57:16,533 INFO  [org.jboss.web] (MSC service thread 1-3) JBAS018224:
>> Unregister web context: /simple
>>
>> The current implementation sets the initial mode of the CONFIGURE_MODULE
>> to NEVER for start.policy=deferred
>> The start/stop operations toggle the mode of the INSTALL phase service
>> between ACTIVE/NEVER.
>>
>> The CLEANUP phase is currently a problem on repeated start. You'll see
>>
>>     Caused by: java.lang.NullPointerException
>> atorg.jboss.as.ejb3.deployment.processors.merging.AbstractMergingProcessor.deploy(AbstractMergingProcessor.java:61)
>>          at
>> org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:124)
>>     [jboss-as-server-7.2.0.Alpha1-SNAPSHOT.jar:7.2
>>
>> because the EEModuleDescription is no longer attached.
>>
>> Stopping a deployment would not need to take the Module and associated
>> ClassLoader down. So any datastructures needed to configure the Module
>> can safely be cleaned up IMHO. I presume the DUPs can reasonably be
>> fixed by moving them to the appropriate phases (see below) and by making
>
> Which DUPs do you propose moving and to which phase?  Currently, the 
> first DUP to use a deployment module classloader, is JPA (for class 
> enhancing (rewriting) in the FIRST_MODULE_USE phase as part of 
> creating the EntityManagerFactory).  If class enhancing is not 
> enabled, the JPA entity manager factory is created during the INSTALL 
> phase.
All DUPs currently assume that they run in a single transaction. IOW, 
the DUPs in the INSTALL phase are not designed for the deployment to 
yo-yo in that phase, which they would have to do if we are going to 
implement deployment start/stop behaviour (without reconstruction on the 
Module) properly.

I suggest the review the DUPs in the INSTALL phase to see whether they 
use data structures that are removed in the CLEANUP phase. There are two 
possibilities

#1 DUP (in INSTALL) should be moved to a phase that is only executed 
once. Then the associated data can safely be discarded in CLEANUP

#2 DUP (in INSTALL) should only use data that stays attached with the DU 
and is not discarded in CLEANUP

I guess this has to be decided on a case-by-case basis. Each subsystem 
would have to make up its mind what it means to start/stop their 
respective deployments. For a webapp that probably means to start/stop 
the web context.
>
>> sure they still have the data structures attached to do yo-yo on the
>> activate phases.
>>
>> Using this terminology <https://issues.jboss.org/browse/AS7-3585>
>>
>>     STRUCTURE         =>   STRUCTURE
>>
>>     PARSE             =>   PRE_INSTALL
>>     REGISTER          =>   INSTALL
>>                        =>   POST_INSTALL
>>
>>     DEPENDENCIES      =>   PRE_RESOLVE
>>     CONFIGURE_MODULE  =>   RESOLVE
>>     FIRST_MODULE_USE  =>   POST_RESOLVE
>>
>>     POST_MODULE       =>   PRE_ACTIVATE
>>     INSTALL           =>   ACTIVATE
>>                        =>   POST_ACTIVATE
>>
>>     CLEANUP           =>   CLEANUP
>>
>> We could stop at PRE_RESOLVE. Subsequent start would go up to and
>> including CLEANUP. Subsequent stop would go back including PRE_ACTIVATE.
>> Subsequent start as before.
>>
>> cheers
>> --thomas
>>
>>
>> -- 
>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>> Thomas Diesler
>> JBoss OSGi Lead
>> JBoss, a division of Red Hat
>> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>>
>>
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>

-- 
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx