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

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.

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

On 8 Apr 2011, at 17:42, Kabir Khan wrote: >> 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.

My https://github.com/kabir/jboss-as/commits/JBAS-8680_JBAS-9178 branch contains the history stuff. I'll be attending the JAX conference in London tomorrow, but will do the command line parts around that, along with any suggestions for what I have done for the history part. The definition of 'successfully booted' is more strict in standalone and triggered by the BootstrapListener, in domain mode it is triggered in HostControllerService.start() and DomainControllerService.start(). Once the server is successfully booted we back up the xml to .initial - this is only ever done once, this file does not get overwritten by us ever (unless a user deletes it) .original - this is done for each restart .last - contains the last version of the file Then each run gets a folder, for standlone it is standalone/configuration/standalone_xml/current Each up date results in a new copy of the file: standalone.v1.xml standalone.v2.xml etc. We keep the last 100 copies of this. So once we get to v101, we delete v1, etc. domain.xml and host.xml work the same, just different names. Once the server is restarted, and if the standalone/configuration/standalone_xml/current directory exists, it is copied to standalone/configuration/standalone_xml/<timestamp-of-current-restart>. These get deleted automatically after a month . When starting the server we create a standalone/configuration/standalone_xml/snapshots/<timestampt>.xml file (this is the same as the .original file, but will never get overwritten) There are some operations to manage snapshots: [localhost:9999 /] :take-snapshot { "outcome" => "success", "result" => {"name" => "/Users/kabir/sourcecontrol/jboss-as7/git/jboss-as/build/target/jboss-7.0.0.Beta3-SNAPSHOT/standalone/configuration/standalone_xml/snapshot/20110411-204125317.xml"}, "compensating-operation" => undefined } #This ^ creates another timestamped version in the standalone/configuration/standalone_xml/snapshots/ folder [localhost:9999 /] :list-snapshots { "outcome" => "success", "result" => { "directory" => "/Users/kabir/sourcecontrol/jboss-as7/git/jboss-as/build/target/jboss-7.0.0.Beta3-SNAPSHOT/standalone/configuration/standalone_xml/snapshot", "names" => [ "20110411-204010866.xml", "20110411-204015241.xml", "20110411-204123984.xml", "20110411-204124693.xml", "20110411-204125317.xml" ] }, "compensating-operation" => undefined } #This ^ lists all the snapshots on the server [localhost:9999 /] :delete-snapshot(name=BOGUS) { "outcome" => "failed", "failure-description" => "No files beginning with 'BOGUS' found in /Users/kabir/sourcecontrol/jboss-as7/git/jboss-as/build/target/jboss-7.0.0.Beta3-SNAPSHOT/standalone/configuration/standalone_xml/snapshot" } [localhost:9999 /] :delete-snapshot(name=20110411-20401) { "outcome" => "failed", "failure-description" => "Ambiguous name '20110411-20401' in /Users/kabir/sourcecontrol/jboss-as7/git/jboss-as/build/target/jboss-7.0.0.Beta3-SNAPSHOT/standalone/configuration/standalone_xml/snapshot: [20110411-204010866.xml, 20110411-204015241.xml]" } [localhost:9999 /] :delete-snapshot(name=20110411-2040108) { "outcome" => "success", "result" => undefined, "compensating-operation" => undefined } #This ^ deletes a snapshot using its name, only enough of the name to uniquely identify a snapshot is needed. These operations exist on the root of standalone, domain and host. On 11 Apr 2011, at 13:13, Kabir Khan wrote: > > On 8 Apr 2011, at 17:54, Kabir Khan wrote: > >> >> On 8 Apr 2011, at 17:42, Kabir Khan wrote: >>>> 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. > I've gone with this option in standalone mode, writes to the model are not backed up until the standalone server has successfully booted. > Now, the question is when the domain is considered to be properly started? > -Once we are ready to start the servers? Bad config in host/domain here could screw up startup for one or more servers. > -Once all the servers have been started successfully? If a server does not start for whatever reason we won't get the domain files backed up. > > For the command line stuff, I am adding this extra system property for standalone mode (default value is 'standalone.xml': > -Djboss.server.config.file > > and these two extra possible properties for the command line for domain mode: > -Djboss.domain.config.host > -Djboss.domain.config.domain > > The default values will be 'host.xml' and 'domain.xml'. > If specified it can either be a full path: > -Djboss.domain.config.host=/somewhere/blah/some-host.xml > > Or if a simple name, a file in jboss.domain.config.dir: > -Djboss.domain.config.host=special-host.xml > > Or any of the backed up files using the known prefixes: > -Djboss.domain.config.host=initial > -Djboss.domain.config.host=last > -Djboss.domain.config.host=original > -Djboss.domain.config.host=v4 > _______________________________________________ > 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

Ooops, that was not a merge request :-) I should have been clearer. Anyway, I'll make any modifications subsequent commits On 12 Apr 2011, at 03:24, Brian Stansberry wrote: > Nice! Merged. > > On 4/11/11 3:03 PM, Kabir Khan wrote: >> My https://github.com/kabir/jboss-as/commits/JBAS-8680_JBAS-9178 branch contains the history stuff. I'll be attending the JAX conference in London tomorrow, but will do the command line parts around that, along with any suggestions for what I have done for the history part. >> >> The definition of 'successfully booted' is more strict in standalone and triggered by the BootstrapListener, in domain mode it is triggered in HostControllerService.start() and DomainControllerService.start(). Once the server is successfully booted we back up the xml to >> .initial - this is only ever done once, this file does not get overwritten by us ever (unless a user deletes it) >> .original - this is done for each restart >> .last - contains the last version of the file >> >> Then each run gets a folder, for standlone it is >> standalone/configuration/standalone_xml/current >> Each up date results in a new copy of the file: >> standalone.v1.xml >> standalone.v2.xml >> etc. >> We keep the last 100 copies of this. So once we get to v101, we delete v1, etc. >> domain.xml and host.xml work the same, just different names. >> >> Once the server is restarted, and if the standalone/configuration/standalone_xml/current directory exists, it is copied to standalone/configuration/standalone_xml/<timestamp-of-current-restart>. These get deleted automatically after a month . >> >> When starting the server we create a >> standalone/configuration/standalone_xml/snapshots/<timestampt>.xml file (this is the same as the .original file, but will never get overwritten) >> >> There are some operations to manage snapshots: >> [localhost:9999 /] :take-snapshot >> { >> "outcome" => "success", >> "result" => {"name" => "/Users/kabir/sourcecontrol/jboss-as7/git/jboss-as/build/target/jboss-7.0.0.Beta3-SNAPSHOT/standalone/configuration/standalone_xml/snapshot/20110411-204125317.xml"}, >> "compensating-operation" => undefined >> } >> #This ^ creates another timestamped version in the standalone/configuration/standalone_xml/snapshots/ folder >> >> [localhost:9999 /] :list-snapshots >> { >> "outcome" => "success", >> "result" => { >> "directory" => "/Users/kabir/sourcecontrol/jboss-as7/git/jboss-as/build/target/jboss-7.0.0.Beta3-SNAPSHOT/standalone/configuration/standalone_xml/snapshot", >> "names" => [ >> "20110411-204010866.xml", >> "20110411-204015241.xml", >> "20110411-204123984.xml", >> "20110411-204124693.xml", >> "20110411-204125317.xml" >> ] >> }, >> "compensating-operation" => undefined >> } >> #This ^ lists all the snapshots on the server >> >> [localhost:9999 /] :delete-snapshot(name=BOGUS) >> { >> "outcome" => "failed", >> "failure-description" => "No files beginning with 'BOGUS' found in /Users/kabir/sourcecontrol/jboss-as7/git/jboss-as/build/target/jboss-7.0.0.Beta3-SNAPSHOT/standalone/configuration/standalone_xml/snapshot" >> } >> [localhost:9999 /] :delete-snapshot(name=20110411-20401) >> { >> "outcome" => "failed", >> "failure-description" => "Ambiguous name '20110411-20401' in /Users/kabir/sourcecontrol/jboss-as7/git/jboss-as/build/target/jboss-7.0.0.Beta3-SNAPSHOT/standalone/configuration/standalone_xml/snapshot: [20110411-204010866.xml, 20110411-204015241.xml]" >> } >> [localhost:9999 /] :delete-snapshot(name=20110411-2040108) >> { >> "outcome" => "success", >> "result" => undefined, >> "compensating-operation" => undefined >> } >> #This ^ deletes a snapshot using its name, only enough of the name to uniquely identify a snapshot is needed. >> >> These operations exist on the root of standalone, domain and host. >> >> On 11 Apr 2011, at 13:13, Kabir Khan wrote: >> >>> >>> On 8 Apr 2011, at 17:54, Kabir Khan wrote: >>> >>>> >>>> On 8 Apr 2011, at 17:42, Kabir Khan wrote: >>>>>> 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. >>> I've gone with this option in standalone mode, writes to the model are not backed up until the standalone server has successfully booted. >>> Now, the question is when the domain is considered to be properly started? >>> -Once we are ready to start the servers? Bad config in host/domain here could screw up startup for one or more servers. >>> -Once all the servers have been started successfully? If a server does not start for whatever reason we won't get the domain files backed up. >>> >>> For the command line stuff, I am adding this extra system property for standalone mode (default value is 'standalone.xml': >>> -Djboss.server.config.file >>> >>> and these two extra possible properties for the command line for domain mode: >>> -Djboss.domain.config.host >>> -Djboss.domain.config.domain >>> >>> The default values will be 'host.xml' and 'domain.xml'. >>> If specified it can either be a full path: >>> -Djboss.domain.config.host=/somewhere/blah/some-host.xml >>> >>> Or if a simple name, a file in jboss.domain.config.dir: >>> -Djboss.domain.config.host=special-host.xml >>> >>> Or any of the backed up files using the known prefixes: >>> -Djboss.domain.config.host=initial >>> -Djboss.domain.config.host=last >>> -Djboss.domain.config.host=original >>> -Djboss.domain.config.host=v4 >>> _______________________________________________ >>> 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 > > > -- > 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

On Monday 11 April 2011 05:43 PM, Kabir Khan wrote: > > On 8 Apr 2011, at 17:54, Kabir Khan wrote: > > > For the command line stuff, I am adding this extra system property for standalone mode (default value is 'standalone.xml': > -Djboss.server.config.file > > and these two extra possible properties for the command line for domain mode: > -Djboss.domain.config.host > -Djboss.domain.config.domain Shouldn't those 2 properties be -Djboss.domain.config.host.file and -Djboss.domain.config.domain.file to be similar to -Djboss.server.config.file? -Jaikiran _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

This seems like a common enough use case to justify formal parameters, e.g. --domain-config --host-config --server-config On 4/14/11 12:00 PM, Kabir Khan wrote: > It is in master f you want to change them go ahead, I just wanted to keep things as short as possible. > > Maybe -Djboss.server.config.standalone instead of -Djboss.server.config.file > On 14 Apr 2011, at 15:31, Jaikiran Pai wrote: > >> On Monday 11 April 2011 05:43 PM, Kabir Khan wrote: >>> >>> On 8 Apr 2011, at 17:54, Kabir Khan wrote: >>> >>> >>> For the command line stuff, I am adding this extra system property for standalone mode (default value is 'standalone.xml': >>> -Djboss.server.config.file >>> >>> and these two extra possible properties for the command line for domain mode: >>> -Djboss.domain.config.host >>> -Djboss.domain.config.domain >> Shouldn't those 2 properties be -Djboss.domain.config.host.file and >> -Djboss.domain.config.domain.file to be similar to >> -Djboss.server.config.file? >> >> -Jaikiran >> _______________________________________________ >> 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 -- 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