[JBoss AS7 Development] - Overall control of graceful shutdown
by Brian Stansberry
Brian Stansberry [http://community.jboss.org/people/bstansberry%40jboss.com] created the discussion
"Overall control of graceful shutdown"
To view the discussion, visit: http://community.jboss.org/message/562906#562906
--------------------------------------------------------------
Wanted to document some thoughts (mostly David's) on overall handling of graceful shutdown in AS 7.
The first core requirement is users need to be able to ask the server to shut down gracefully. Shutting down gracefully means allowing ongoing work, including long-running tasks, to complete before shutting down or, if possible, shifting the long running work to another server and cleanly telling the client of the change. The second core requirement is allowing the user to provide an overall timeout for how long to allow ongoing work to complete before accepting possible disruption to that work and pushing forward with the shutdown.
The individual services within the AS are the ones who understand what the ongoing tasks are, how to monitor them for completeness, how to push them to other servers and how to terminate them "gracelessly" if needed.
The overall AS knows how long it's been since graceful shutdown was requested and thus whether a timeout has been exceeded.
The gist of our thoughts on this is the normal behaviour of any AS subsystem should be to shut down gracefully. That is, the stop() method of the services that comprise the subsystem should understand what the ongoing tasks are, monitor them for completeness, try if possible to push them to other servers, and only shut down when ongoing work is complete. The stop() method should allow this to take as long as necessary.
However, the services should also provide a hook to allow the overall AS to signal that the shutdown timeout has passed and that shutdown needs to now proceed without regard for disruption to ongoing work. That signal would come on a separate thread from the one that invoked the service's stop() method. When that signal is received the thread executing stop() should be informed of that (e.g. via setting flags that stop() periodically checks, interrupting the thread running stop(), etc) and then the stop() execution should proceed down a code path that promptly stops the service.
The hook provided by the AS would consist of a service that any service that supports graceful shutdown could have injected:
public interface GracefulShutdownService() {
void registerGracefulShutdownTerminator(GracefulShutdownTerminator terminator);
}
The service that supports graceful shutdown would register a callback with GracefulShutdownService that the AS would use to signal that the "graceful" aspect of shutdown no longer applies:
public interface GracefulShutdownTerminator() {
void terminateGracefulShutdown();
}
I think it might be better though to just simplify this, skip GracefulShutdownTerminator and have services register a Runnable with GracefulShutdownService.
public interface GracefulShutdownService() {
void registerGracefulShutdownTerminator(Runnable terminator);
}
All this is just about the overall control of the shutdown. The complexity is in the subsystem's graceful shutdown handling. That's where tricky stuff needs to happen, e.g.
1) Identifying existing long running work that extends beyond a single request
2) Preventing external clients creating new long running work that extends beyond a single request
3) Allowing internal clients to continue creating new long running tasks (i.e. trust the internal client to properly do 2) and assume any new work it submits is needed to allow some overall existing work to gracefully complete)
4) Moving long running tasks to other servers or letting them complete
5) Leaving external connectors open until 4) is done but stopping them as soon as possible once externally generated long running work is handled
6) Final shutdown
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/562906#562906]
Start a new discussion in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years
[jBPM Development] - nodes not loading in processDefinition
by shilan kalhor
shilan kalhor [http://community.jboss.org/people/shiloon] created the discussion
"nodes not loading in processDefinition"
To view the discussion, visit: http://community.jboss.org/message/562904#562904
--------------------------------------------------------------
Hi forum,
recently we have upgraded from jbpm 3.0.1 to 3.2.8. but new problem occurs with the old code.
when i try to find the regarding processDefinition from database using this code
GraphSession graphSession = jbpmContext.getGraphSession();
processDefinition = graphSession.findLatestProcessDefinition("processCoreName");
i note that processDefintion nodes don't load giving following exception:
Method threw 'org.hibernate.LazyInitializationException' exception.- illegal access to loading collection
but if i hard code the xml definition in the code and then just load the processDefinition, everything would be okay and
all nodes will be load respectively.
can you please help me to resolve the issue, is some newly added columns is empty or null causing this problem?
thanks
chilli
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/562904#562904]
Start a new discussion in jBPM Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years
[JBoss AS7 Development] - Hacking on AS7
by Jason Greene
Jason Greene [http://community.jboss.org/people/jason.greene%40jboss.com] modified the document:
"Hacking on AS7"
To view the document, visit: http://community.jboss.org/docs/DOC-15596
--------------------------------------------------------------
h4. 1. Create a github account
http://github.com http://github.com
h4. 2. Fork jboss-as into your account
http://github.com/jbossas/jboss-as http://github.com/jbossas/jboss-as
h4. 3. Clone your newly forked copy onto your local workspace
$ git clone git@github.com:[your user]/jboss-as.git
Initialized empty Git repository in /devel/jboss-as/.git/
remote: Counting objects: 2444, done.
remote: Compressing objects: 100% (705/705), done.
remote: Total 2444 (delta 938), reused 2444 (delta 938)
Receiving objects: 100% (2444/2444), 1.71 MiB | 205 KiB/s, done.
Resolving deltas: 100% (938/938), done.
$ cd jboss-as
h4. 4. Add a remote ref to upstream, for pulling future updates
git remote add upstream git://github.com/jbossas/jboss-as.git
h4. 5. Use maven (or build.sh) (make sure you use maven 3)
$ mvn install
.....
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] JBoss Application Server: BOM ..................... SUCCESS [1.834s]
[INFO] JBoss Application Server: Parent Aggregator ....... SUCCESS [0.022s]
[INFO] JBoss Application Server: Domain Core ............. SUCCESS [3.051s]
[INFO] JBoss Application Server: Server Manager .......... SUCCESS [0.204s]
[INFO] JBoss Application Server: Server .................. SUCCESS [0.283s]
[INFO] JBoss Application Server: Domain Controller ....... SUCCESS [0.084s]
[INFO] JBoss Application Server: Process Manager ......... SUCCESS [0.314s]
[INFO] JBoss Application Server: Remoting ................ SUCCESS [0.390s]
[INFO] JBoss Application Server: Build ................... SUCCESS [5.696s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
h4. 6. Pulling later updates from upstream
$ git pull upstream master
>From git://github.com/jbossas/jboss-as
* branch master -> FETCH_HEAD
Updating 3382570..1fa25df
Fast-forward
{parent => bom}/pom.xml | 70 ++++----------
build/pom.xml | 13 +--
domain/pom.xml | 10 ++
.../src/main/resources/examples/host-example.xml | 2 +-
.../resources/examples/jboss-domain-example.xml | 28 +++---
.../main/resources/schema/jboss-domain-common.xsd | 12 +--
.../main/resources/schema/jboss-domain-host.xsd | 2 +-
domain/src/main/resources/schema/jboss-domain.xsd | 17 ++--
pom.xml | 100 ++++++++++++++++++--
process-manager/pom.xml | 3 +-
10 files changed, 156 insertions(+), 101 deletions(-)
rename {parent => bom}/pom.xml (85%)
h4. 7. Pushing pulled updates (or local commits if you aren't using topic branches) to your private github repo (origin)
$ git push
Counting objects: 192, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (44/44), done.
Writing objects: 100% (100/100), 10.67 KiB, done.
Total 100 (delta 47), reused 100 (delta 47)
To git@github.com:[your user]/jboss-as.git
3382570..1fa25df master -> master
h4. 8. Discuss your planned changes (if you want feedback)
* On the forums - http://community.jboss.org/en/jbossas/dev/jboss_as7_development http://community.jboss.org/en/jbossas/dev/jboss_as7_development
* On IRC - irc://irc.freenode.org/jboss-as7 or https://webchat.freenode.net/?channels=jboss-as7 (http://webchat.freenode.net/?channels=jboss-as7)
h4. 9. Make sure there is a JIRA somewhere for the enhancement/fix
http://jira.jboss.org http://jira.jboss.org
h4. 10. Create a simple topic branch to isolate that work (just a recommendation)
git checkout -b my_cool_feature
h4. 11. Make the changes and commit one or more times (Don't forget to push)
git commit -m 'JBAS-XXXX Frunubucate the Fromungulator'
git commit -m 'JBAS-YYYY Tripple Performance of Fromungulation'
git push my_cool_feature
+Note that git push references the branch you are pushing and defaults to master, *not your working branch*.+
h4. 12. Rebase your branch against the latest master (applies your patches on top of master)
git fetch upstream
git rebase -i upstream/master
# if you have conflicts fix them and rerun rebase
git push my_cool_feature
The -i triggers an interactive update which also allows you to combine commits, alter commit messages etc. It's a good idea to make the commit log very nice for external consumption. Note that if any of your changes have conflicts, you will have to edit them and
h4. 13. Get your changes merged into upstream
1. Make sure your repo is in sync with other unrelated changes in upstream before requesting your changes be merged into upstream by repeating step 12.
2. Email a pull request to mailto:jbossas-pull-requests@lists.jboss.org jbossas-pull-requests(a)lists.jboss.org (if I haven't subscribed the list, do it https://lists.jboss.org/mailman/listinfo/jbossas-pull-requests here) with a link to your repo, a description of the changes, and who reviewed (if any)
3. After review a maintainer will merge your patch, update/resolve issues by request, and reply when complete
h4. Appendix A. Adding a new external dependency
1. Edit pom.xml and add a property of the form "version.groupId.artifactId" which contains the Maven version of the dependency. Add your dependency to the <dependencyManagement> section, and use the property for the version. If your new dependency has any transitive dependencies, be sure to <exclude> them (or if possible, update the project so that all its dependencies are of *provided* scope).
2. Add your dependency to any AS modules that require it, but only with group/artifact.
3. Edit build/pom.xml and add your dependency with only group/artifact.
4. Create a directory in build/src/modules corresponding to the *module's* name (which will differ from the Maven group/artifact name; look at other modules to get a feel for the naming scheme), with a version of "main", like this: "build/src/modules/org/jboss/foo/main".
5. Create a module.xml file inside the "main" directory. Use a module.xml from another similar module as a template.
6. Edit build/build.xml and add a <module-def> element. The name listed in the <module-def> element corresponds to the *module* name. The group/artifact listed in the nested maven-resource element(s) refer to the *Maven* group/artifact name.
7. *Important:* Make sure you did not introduce any transitive dependencies by using "mvn dependency:tree". If you did, be sure to add <exclusion>s for each of them to your dependency as described above.
Please be sure to preserve the alphabetical ordering of all POMs and the build.xml file.
h4. Appendix B. Adding a new AS submodule
1. Create the directory corresponding to the submodule and add it to the root pom.xml file. The convention is to leave off the "jboss-as-" portion, so "jboss-as-remoting" becomes "remoting".
2. Create a POM for your submodule (use another submodule as a template). Make sure all dependencies you specify do *not* include a version. The group ID should be "org.jboss.as", and the artifact ID should begin with "jboss-as-" and there should be a proper <name> for the new module.
3. Add the new submodule to the top section of the <dependencyManagement> of the top-level pom.xml. The version should be set to "${project.version}". This section is sorted alphabetically by artifact name so please preserve that ordering.
4. Add your submodule dependency to any AS modules that require it, but only with group/artifact.
5. Edit build/pom.xml and add the new submodule with only group/artifact.
6. Create a directory in build/src/modules corresponding to the submodule, with a version of "main", like this: "build/src/modules/org/jboss/as/new-subsystem/main".
7. Create a module.xml file inside the "main" directory. Use a module.xml from another subsystem as a template.
8. Edit build/build.xml and add a <module-def> element for the subsystem. Use the module name and Maven coordinates from steps 6 and 2 respectively. Use another submodule as a template.
Please be sure to preserve the alphabetical ordering of all POMs and the build.xml file.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-15596]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
16 years
[JBoss AS7 Development] - Domain Requirements
by Jason Greene
Jason Greene [http://community.jboss.org/people/jason.greene%40jboss.com] modified the document:
"Domain Requirements"
To view the document, visit: http://community.jboss.org/docs/DOC-15098
--------------------------------------------------------------
This document is meant to facilitate discussion of the design of the AS 7 domain management features. More specifically, it is a list of requirements for those features. The intent is not to focus on how those requirements are realized; see other documents such as the https://community.jboss.org/docs/DOC-15215 Domain Management Model Design wiki for that. It is helpful to familiarize yourself with the definitions in that wiki, as the requirements below often use those terms.
At this point these requirements are organized
1. A *+domain+* is a management policy that applies to one or more servers/nodes, which may or may not be part of a cluster
2. The primary and authoritative representation of the domain, the +*domain model*+, will be stored in the domain.xml file.
3. All changes made to the in-memory model must be written to the domain.xml file
4. Various client interfaces to the domain will also be provided including * JON/JOPR
* Java based management API
* AS Admin Console
* CLI tool
5. All client interfaces must be able to view the complete logical domain model representation
6. All client interfaces must also be able to view +*non-classified components, those which are not part of the domain but instead come from deployments or legacy management mechanisms.*+
7. The domain model *always* takes precedence over deployment specified resources/components.
8. It must be clear in all client interfaces which actions:1. affect the domain model
2. affect components associated with the domain model but not the domain model itself (e.g. an obscure property exposed via a component's managment interface that isn't part of the domain model).
3. affect non-classified components
9. Deployment of applications will only take place at the Server Group, and Cluster level, as well as being able to be a part of an Action Group.
10. We will support configuration changes that are made one time, that apply to the entire Server Group or Cluster.
11. Run-time configuration changes can be applied without restarting the server, if its defined in the API for that component.
12. We will have three main startup modes: 1. Stand alone - single private domain, intended for the developer case, and would have the default EE set of services available after startup.
2. Domain controller - server that runs the domain controller profile.1. No consideration of HA for the domain controller.
3. Domain member - a server that gets its profile from a domain controller.
13. Domain configuration information will be allowed to be hand edited only with the server down.
14. We will have a "server/lib" profile. (+Comment: let's disambiguate the term 'profile'. What's discussed here is an element in the overall set of capabilities a server is running.+)1. This handles the case of things like JDBC drivers, and third party libraries for applications, that are provided by the customer, and not provided by us.
15. At the server group level we would have the ability to keep each InstalledImage in sync with the MasterRepository, or not.1. If synchronization is turned off, the customers provisioning scripts/tools, etc. would be responsible for keeping all the InstalledImages in the server group in sync.
2. When a server joins a server group/cluster, end user applications and "server/lib" would be kept in sync, if syncing is turned on.1. We still need to isolate end user jars from our jars in the "server/lib" profile. This must encompass all end user provided content.
2. What about all the binaries, and configuration files?1. Yes, these should have an index, with hashes, etc., and be synced as a server joins a server group/cluster.
16. We will allow dynamic addition of a server to a domain/server group/cluster, etc.1. The domain controller will have a setting that will either allow this or not.
2. The options for when you don't allow the dynamic addition of the server would be:1. Die (server is shutdown).
2. Put in stand-by mode, without starting any services, until an administrator has added the server to the domain.
17. A server will always be in a server group. 1. This may be a one-to-one relationship.
18. The domain controller will always have the complete list of services that are possible to be started.
19. A server group will also contain the full list of services, but with only certain services enabled, unless of course it requires all the services, then all of them would be enabled.
20. Maven, Ant, JBoss Tools/JDBS deployment scenarios all need to continue to function as they do today, from a user point of view.
21. The following elements need to be configurable at the server level1. Logging levels (default can be pulled from group)
2. JVM Parameters (default can be pulled from group)
3. System properties (default can be pulled from group)
4. Pool sizes [Thread,DB, etc] (default can be pulled from group)
5. IP addresses
22. When the domain controller is down the servers in the group or cluster will continue to work, but no administration will be possible until the domain controller becomes available.1. HA solution TBD (could be as simple as telling the customer to use a monitoring process that restarts if it fails, like watchdog, or if they have solutions like Tivoli, HP OpenView, they provide those functions).
2. The requirement here, is that we need to be able to create a new domain controller to replace the current one, and have all the servers within the domain, understand where the new domain controller is.
23. When a server starts, and cannot contact the domain controller, then the following applies:1. Start with the last known state, but log a BIG warning!.
2. Don't start, because there may have been administration changes that would mean the last known state (synchronization) could be incorrect for the server group/cluster.
3. Don't start and you know that a synchronization operation has failed as the last operation.
4. You shouldn't be able to start if you have never joined a domain to begin with.1. Obviously, doesn't include the developer case with a private domain.
24. We will need an "agent" or "server manager" or "domain slave", call it what you will, that the domain controller will talk to it. 1. The "agent" will need to be local to the server (may be a one to one relationship, if every server is on its own OS instance, or may be one to many if there are many servers on one OS instance).
2. We must have one "agent", regardless of whether the customer is using JON or not, or has multiple products or not. 1. This may not be possible in the case where we have multiple version families deployed in one customer environment.
25. We will have a REST interface for management.1. May not cover the entire management API, but will evolve.
26. The profile server API will be the programmatic API (Java).
27. The REST interface will be the basis for the CLI (it sits on top of it).
28. We must have a domain controller API.1. This is also part of the programmatic API.
29. Changes to the profile service API do not have to be backward compatible, since only JON and the Admin Console are the current users.
30. We will expose selected management capabilities through JMX, but not everything.1. Exactly what this would be is TBD
2. There are quite of few projects that have exposed their management interface through JMX.1. So, we will need to add profile service support, via wrapper over their internal management API.
31. Projects must have an internal management API, and not be directly dependent on JMX for their management API.
32. Projects must maintain a profile service management API wrapper over their internal management API.1. This is an integration requirement.
33. We will not have a management capability for the old "pruned" or "deprecated" parts of EE 6.
34. We need to have the ability to have a profile generator.1. Post install, can use the services in the domain model, with dependency information to allow users to create their own profile, that will actually work.
2. This gives formal support to what customers do with "slimming" today.
35. We need to be able to manage all the network request paths:1. JMS
2. HTTP
3. IIOP
4. Remoting
36. It shall be possible within domain.xml to specify what capabilities/subsystems are allowed (whitelist) or disallowed (blacklist) in order to ensure that undesired subsystems are not inadvertently started causing unexpected performance penalties.
37. Domain subsystems and extensions are the recommended SPI for adding custom configuration driven services. Legacy models, such as single xml file deployments, will be deferred until community demand drives a particular solution
38. Domain Controller is just a Server Manager running in "master" mode (one less JVM)
39. Admin console will run in a Server instance, with a possible many-to-one relationship to the "controller"
40. The Standalone class will be renamed to ServerModel to avoid confusion with the "standalone" use case
41. Domain and Standalone will not share bootstrap as they are fundamentally different (AbstractServer bytes the dust)
42. Statistics will be associated with the domain
43. ServerManager will handle stats/runtime queries to allow load distribution
44. DC will potentially redirect to the SM to simplify this
45. The "update" objects will be responsible for determining if the update is "runtime" or "requires restart" or "may require restart"
46. Incremental domain updates are low-priority for 7 GA.
47. Logging will be passed to the server via a stdin command pattern to solve the chicken egg problem. Security Manager Policies will not be in the domain
. Policy file location and security manager impl class will be part of the JVM section of the domain
. Domain will have password element for clear-text and inline encrypted passwords and a password ref to keystore
. Domain will contain SSL element with keystore, truststore, keyPassword, trustPassword, module-ref to alternative keymanager, trustmanager
. Ability to load custom security providers in domain.xml
. Ability to sync keystores
. security realms (e.g. login-config.xml) will be represented as a subsystem in the domain.xml, other subsystems will reference it, and it will provide natural language configs for login modules
. DC & SM will use authentication
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-15098]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
16 years
[JBoss AS7 Development] - Domain Management Model Design
by Jason Greene
Jason Greene [http://community.jboss.org/people/jason.greene%40jboss.com] modified the document:
"Domain Management Model Design"
To view the document, visit: http://community.jboss.org/docs/DOC-15215
--------------------------------------------------------------
This document is meant to facilitate discussion of the design of the AS 7 domain management features. It is not a list of requirements; for that see the http://community.jboss.org/docs/DOC-15098 requirements document. The intent of this document is to focus more on how we see those requirements being realized.
(Note: this document includes embedded images, in image formats. At least the initial ones come from the MagicDraw tool; the underlying MagicDraw file is attached. Going forward this should end up in version control somewhere, perhaps in an sharable format like XMI.)
h2. The Logical Model
In this section, we define the logical representation of the domain management model. First an image, followed by some definitions
http://community.jboss.org/servlet/JiveServlet/showImage/102-15215-11-296... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-15215-11...
h4. Agreed Definitions:
Following are definitions for items in the above model or related concepts, as agreed in various discussions. However, people are still welcome to challenge these.
* *Domain*: Set installed images required to run *N* applications using the same version family of JBoss AS, ESB etc (single project) managed by one or more administrators/users.
* *Version Family*: A version family is any project release with the same major version number, e.g. 5.0.0, 5.0.1, 5.1.0, 5.1.1, 5.2.0, etc are all the same version family.
* *Multi-Domain*:++ Two or more domains, encompassing hundreds of domains, thousands of instances, and multiple XYZs +(Not shown on the above diagram as multi-domain management is beyond the scope of the domain management model.)+
* *ServerGroup*: User defined set of server instances that will be managed and configured as one. All members must be at the same platform version and have the same application(s) and all their dependencies.
* *Cluster*: Server group with group communication services configured.
* *Server*: One JBoss AS, ESB, etc instance (JVM process), that must belong to only one server group.
* *ActionGroup*: User defined set of manageable property or properties within a single domain that will be managed as one.
* *Profile*: The set of subsystems that are included in the server group configuration along with the deployment repository reference. A profile can include one or more other profiles provided that there is no logical conflict (two definitions of the same subsystem)
* *DomainController*: The authoritative source of domain content and changes.
h2. Physical Deployment
This section focuses less on the logical model and more on how the runtime components of the model map to the physical infrastructure on which a domain runs. For more on how some of these concepts are going to be used, see https://community.jboss.org/docs/DOC-15303 this page on server lifecycle use cases.
http://community.jboss.org/servlet/JiveServlet/showImage/102-15215-11-389... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-15215-11...
h4. Agreed Definitions:
Following are definitions for items in the above model or related concepts, as agreed in various discussions. However, people are still welcome to challenge these.
* *Host*: An OS instance that can contain one or more Servers, ServerGroups, Clusters, Domains. +(Comment: a Host 'contains' ServerGroups, Clusters or Domains in the sense that it can contain multiple Servers which may be associated with different ServerGroups, Clusters or Domains. Further, all Servers associated with a ServerGroup, Cluster or Domain may be running on the same Host.)+
* *Server*: see above in "Logical Model" section. Here we are referring to a running Server process.
* *Provisioning*: Installing a new binary of a runnable instance of a Server.
* *Patching*: Notification and installation of fixes against a server, server group/cluster.
* *Patches*: Content containing fixes for servers.
* *InstalledImage*: Content (binaries, configuration and miscellaneous resources) that is physically installed on a particular Host (see Provisioning) that allows one or more Servers to function. An Installed Image only contains content associated with a single Domain. Multiple Servers may share the same Installed Image. (+Comment: we need to clarify how writeable areas relate to this.+) A Host may contain multiple InstalledImages, either associated with different Domains, or associated with the same Domain (for use by different Servers).
* *DomainController*: A role played by a ServerManager process that is responsible for managing the domain. An AS instance running in domain mode will have most one ServerManager process instance acting as a DomainController. All persistent management operations will be performed against the DomainController. Other ServerManager processes will be subservient to the DomainController. If no ServerManager is acting as a domain controller, all Servers in the domain will continue to work, but no administration will be possible until a DomainController becomes available. Other ServerManager process might be able to assume the DomainController role, provided they have a complete copy of the domain.
* *Process Manager*: a very lightweight process whose primary function is to spawn Server processes and ServerManagerProcesses and manage their stdio streams. This would be a very simple piece of code. The intent is to increase the resiliency of the Server processes by not having their parent process be a complex one like the ServerManager. This also allows the ServerManager to be patched and restarted without impact the associated Servers.
* *ServerManager*: A process which is responsible for coordinating with a Domain Controller to control the lifecycle of Server processes (via the process manager), the distribution of deployments from the Domain Controller to the Server instances, and the management of the Installed Image. (Comment: this definition subsumes the DomainSynchronizer concept mentioned below.)
* *MasterRepository*: Component to which the DomainController delegates the management of the master copy of all content used by any Server in the domain. Any content in any InstalledImage is synchronized (via the DomainController and a ServerManager) with the content in the MasterRepository before a Server is allowed to boot. (Note that the requirements document will describe rules for an "assumed synchronization" in cases where no DomainController is available.)
*
*
A couple notes on the above image:
1. The Host that is running the DomainController does not include other components like ServerManager, InstalledImage. This is both for simplicity and because how the bootstrap of the DomainController itself will work is as yet undiscussed.
2. The Host that is running the DomainController can of course also run other Servers.
h2. Standalone Server
The above Physical Deployment section is oriented toward a more complex, multi-server topology. However, there is another significant type of use case that AS 7 needs to handle well: the single, standalone server that needs to be individually managed. Such a server would be appropriate for use cases where the end user does not want a complex managment infrastructure with separate domain controller and server manager processes:
* Developer usage
* Embedded AS (a special case of developer usage)
* Production deployments where the end user is comfortable scripting against the management API exposed by a standalone server, and handling the multi-server coordination themselves
h4. Logical Model:
Internally, the object model representing the domain configuration for a standalone server may be quite similar to that shown above. However, the XML configuration schema and perhaps the management API will be simplified to remove extraneous concepts like the ServerGroup. (+Whether creating a distinct management API for this use case is appropriate needs discussion. A separate API means clients like JON and the embedded console need to be coded against two APIs in order to cover all use cases.+)
h4. Physical Topology:
For the standalone server use case, all processes shown on both hosts in the Physical Topology image shown above will be collapsed into a single process. The ProcessManager becomes irrelevant. In this use case, the DomainController component represents the management capability the standalone server exposes.
h2. Domain Model Schema
See the http://community.jboss.org/docs/DOC-15403 JBossAS Domain Schema document for the current metadata schema.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-15215]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
16 years
