Relaunching bootstrap with additional configuration information

[starksm64]

One thing we discussed a week ago during the domain model work around JBossAS was the need to be able to read jvm settings from the domain model, and to be able to restart the jvm with the bootstrap configuration. I just checked in a couple of simple tests for launching a jvm from within a java process using the ProcessCreator. Currently the test is org.jboss.test.bootstrap.jvm.launch.LaunchTestCase in the jboss-bootstrap-api project.

I want to discuss where the functionality of restarting the bootstrap jvm should live and what the api needs to look like. Some requirements that were discussed as configuration that should be in the domain model includes:

- jvm parameters such as memory, heap, debug, etc. settings

- jvm version/location

- System properties

- Environment properties

- endorsed library location

- native library locations/properties

- run directory

I'm thinking that the test belongs in jboss-bootstrap-impl-base, and that we need a new BootstrapFactory api for dealing with launching a jvm in a default state, and then relaunching it with the proper bootstrap configuration before moving on to launching the Server. What are your thoughts?

[dmlloyd]

Scott Stark wrote:

One thing we discussed a week ago during the domain model work around JBossAS was the need to be able to read jvm settings from the domain model, and to be able to restart the jvm with the bootstrap configuration. I just checked in a couple of simple tests for launching a jvm from within a java process using the ProcessCreator. Currently the test is org.jboss.test.bootstrap.jvm.launch.LaunchTestCase in the jboss-bootstrap-api project.

[...]

I'm thinking that the test belongs in jboss-bootstrap-impl-base, and that we need a new BootstrapFactory api for dealing with launching a jvm in a default state, and then relaunching it with the proper bootstrap configuration before moving on to launching the Server. What are your thoughts?

I think it makes more sense to view this differently.  Rather than thinking of it as an AS bootstrap which re-executes itself or other AS instances, instead we should have a separate project for the AS server manager role (described in the domain requirements docs that Brian was maintaining).   The server manager would be a separate, self-contained process which would have responsibilities such as:

• Kicking off zero or more server instances (including the stuff like passing JVM options, properties, environment, etc., processed from domain.xml)
  • Though the domain.xml may contain info for all server groups, only the info for the target server's group need be sent to the server instance
• Maintaining a (stdio- or socket-based) control channel with each server instance
• Shutting down server instances (via the control channel)
• Managing the server binary image (installing patches and coordinating server instance shutdown/restart around that process)
• Adding and removing deployments to each server instance (via the control channel)
• Coordinating with the domain controller to accept updates to the domain model (be it push- or pull-based)
• "Remembering" the last domain model state (to allow servers to start up even if the domain controller isn't available)

In order to run AS, our "run.sh" would simply start up the server manager, which would use the domain configuration to start up server instances as needed.  Given a properly designed API, the embedded case can be covered by including the server manager and server instance (and possibly the domain controller) in a single JVM.

[dmlloyd]

In addition, since the scope of the server manager process would strictly controlled, we can simply ship it with a specific JVM config (small heap & stack sizes, etc.) so none of that needs to be reconfigured normally for the server manager.

[dmlloyd]

One other nice/interesting facet of this approach is that when you have the notion of a JBoss AS "service" (init.d script on *nix, or a windows service, etc.), the "service" corresponds to the server manager, which meshes nicely with the concept of a 1:1 relationship between a server manager process and an AS installed binary image.

[starksm64]

David Lloyd wrote:

...

In order to run AS, our "run.sh" would simply start up the server manager, which would use the domain configuration to start up server instances as needed.  Given a properly designed API, the embedded case can be covered by including the server manager and server instance (and possibly the domain controller) in a single JVM.

Ok, the embedded case was what I was thinking of driving this being a bootstrap function. I do think there are circumstances where everything including the domain controller are all running in a single process. Let's see if this can be done with the server manager.

[emuckenhuber]

David Lloyd wrote:

In order to run AS, our "run.sh" would simply start up the server manager, which would use the domain configuration to start up server instances as needed.  Given a properly designed API, the embedded case can be covered by including the server manager and server instance (and possibly the domain controller) in a single JVM.

I would to see this as well. Most likely this would be also interesting for our own testsuite.

Maybe this could even be the base for a CLI, since it would already be able to communicate with a domain and instances?

[wolfc]

For unit testing Embedded must not startup anything that's not directly related to the unit test. For a simple SLSB I don't need Server Manager.

[alrubinger]

Carlo de Wolf wrote:

For unit testing Embedded must not startup anything that's not directly related to the unit test. For a simple SLSB I don't need Server Manager.

To expand a bit, I think this is to say that jboss-bootstrap should not be made aware of PS, ServerManager, or the like.  That's why we have configurable bootstraps.

S,

ALR

[starksm64]

Right, we are all on the same page that neither embedded nor bootstrap has new profileservice/domain server dependencies. This was about allowing for configurations driven by those layers. At this point this thread is essentially dead until there are requirements driven by the domain server work.