11:42 a.m.
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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev