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.

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.

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.

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?

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.

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