[jboss-as7-dev] JBAS-8680 and JBAS-9178

[Kabir Khan]

On 8 Apr 2011, at 17:18, Kabir Khan wrote:

> Regarding JBAS_8660 Brian asked me to post what I am doing. I'll focus on standalone.xml since that is what I am playing with but the same will apply to domain.xml and host.xml.
> 
> The very first time the server boots cleanly, we back up standalone.xml to standalone.xml.initial. This copy will be kept indefinitely, or be recreated if it does not exist.
> 
> For each clean server boot standalone.xml is copied to standalone.xml.original (need a better name than ".original" to distinguish frrom ".initial").
> 
> Once the server is up and running and operations modify standalone.xml the previous version is written as standalone.xml.last. This is the same as the current standalone.xml.last-known-good, which I got rid of. Also, we keep versions of standalone.xml in a subdirectory of standalone.xml's parent dir, called standalone_xml/. standalone_xml/ contains the full history for the current server run. These are named
> standalone.xml.v1
> standalone.xml.v2
> etc.
> 
> Currently, a clean server restart will
> delete any standalone_xml_old/ directory
> rename any standalone_xml/ directory to standalone_xml_old
> recreate standalone_xml to keep the versions.
> 
> Maybe the _old directories should be kept around longer? At the same time for a running server with a lot of model updates happening we will probably want to limit the number of versions of the file kept in standalone_xml.
> 
> A more important question is what constitutes a clean server boot? We'll need some callback in the persister to be triggered when that happens (since ConfigurationPersister.store()) is not called until people start changing the model). Some thoughts about when this could get called are either:
> -Once we have parsed the config file into updates and successfully executed those in the model controller
> -The above but all services have successfully started (similar to what we do in ApplicationServerService.BootstrapListener()). I think a problem with this is that people could have started issuing management commands once the protocol + handlers are up and running before all the other services are up and running.

Maybe instead of worrying about this I create a standalone.xml.booting file when initializing the persister. If ConfigurationPersister.store() gets called we "know" we booted cleanly, and copy this across to .original as needed? If nobody issues any ops that change the model, we'd not get those files created but at least we would have .booting to fall back on?

So the flow would be
Initialising persister:
create .booting
create .intial and .original if they don't exist

On model save:
If .booting exists and it is newer than .original, create .original
initialize checkpoint
create .last and versioned copy

> 
> Brian mentioned being able to create checkpoint copies, which will be kept around until a user deletes them manually or via a management operation. A checkpoint will be created per clean server boot, and also it will be possible to create them via a management operation.
> 
> 
> On 8 Apr 2011, at 15:23, Brian Stansberry wrote:
> 
>> Awesome.
>> 
>> I just made a comment on JBAS-8680, basically just brainstorming a bit.
>> 
>> On 4/8/11 5:53 AM, Kabir Khan wrote:
>>> I'm taking these unassigned issues
>>> 	• JBAS-8680 More robust handling of previous versions of the configuration files
>>> 	• JBAS-9178 Ability to specify config file from the command line
>>> If anybody is already working on these please let me know :-)
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> jboss-as7-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>> 
>> 
>> -- 
>> Brian Stansberry
>> Principal Software Engineer
>> JBoss by Red Hat
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
> 
> 
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev