JBossDeveloper

One thing missing is the notion of a hot deployment dir, which we said in Westford we'd support.

What's tricky is where that is scoped.

1) At a domain level, in which case DC runs scanner thread, detects change, invokes mgmt API to add deployment to domain, and then, how it gets to any server-groups/servers is....

2) At a server-group level, in which DC runs scanner thread, detects change, invokes mgmt API to add  deployment to domain, and then adds it to the server group.

3) Server level with a DC. Not allowed.

4) Standalone server.

Brian Stansberry wrote:

 

Not sure if we'll use ServerManager, but we should support multiple standalone servers running off the same installed image.

 

Good point about needing to specify the module repo root via command line.

I'm not sure about the multiple standalone thing.  With domain:servers we have a single domain, single host, multiple server config.  But with standalone the equivalent of doman+host is merged right in.  So conceptually there can only be one standalone because the host or domain level things are expected to be wholly owned by the standalone server instance.

If someone wants to conserve disk space or something they can always use symlinks to share the module repository which constitutes the bulk of the installed image.

This would purely be a disk space saving thing; definitely it wouldn't be a case of multiple standalone servers running off the same configuration file. Emanuel's example above has multiple config files:

For standalone we might want think about something like:

configuration/

- server1-standalone.xml

- server2-standalone.xml

Not allowing this is a takeaway, since you can run multiple AS 3/4/5/6 instances off the same unzipped distribution, simply by copying a config dir.

Semi-OT, currently the configuration/ area includes domain.xml and host.xml. There may be other writable content that should be kept somewhere else (e.g. if the SM persists the domain state in some form other than domain.xml, domain update log etc.)

Brian Stansberry wrote:

 

This would purely be a disk space saving thing; definitely it wouldn't be a case of multiple standalone servers running off the same configuration file. Emanuel's example above has multiple config files:

 

For standalone we might want think about something like:

configuration/

- server1-standalone.xml

- server2-standalone.xml

 

Not allowing this is a takeaway, since you can run multiple AS 3/4/5/6 instances off the same unzipped distribution, simply by copying a config dir.

It could be confusing because with a domain, each server gets its own directory (for runtime state) but the configuration is shared between them, whereas in the standalone case they'll be more separated - the configuration lives in each server directory.  I guess I just have a hard time visualizing what the user would to do start and stop standalone servers versus the domain case, and how that would interact with the directory structure, and whether/how we support standalone servers on a domain-managed image, and in this case why we wouldn't support allowing an image to participate in multiple domains (via multiple server manager processes).

Brian Stansberry wrote:

 

Semi-OT, currently the configuration/ area includes domain.xml and host.xml. There may be other writable content that should be kept somewhere else (e.g. if the SM persists the domain state in some form other than domain.xml, domain update log etc.)

Yeah.  I think that we need to decide: will domain.xml only actually exist on the DC?  If so does it make sense to put it in the configuration area (which I picture as being more of a SM-controlled area)?  If not, should we bother trying to do any magic to avoid replicating parts of the domain model that don't apply to a host (I'm talking the core model here, not the deployments which I think should be pulled from the DC, not pushed to the servers)?

I only ask that last question because I still haven't worked out a good way to do it.

Emanuel Muckenhuber wrote:

 

In the end it seems that domain concepts don't really fit very well together with the standalone. Maybe trying to unify this might not work overall.

In terms of implementation, a server should be implemented in terms of the Standalone object model (the object model corresponding to standalone.xml).  In a domain setting, something (the SM maybe?) will merge the Domain and Host config and pick out the specific server in question to produce the Standalone object model, which is used to bootstrap the individual server.  In the standalone case it will be read from standalone.xml (obviously).

Emanuel Muckenhuber wrote:

 

Not sure how much sense a hot-deployment directory makes on a domain level? I mean we could obviously create a directory structure representing the server-groups with a deploy folder - which kind of sucks IMHO. I mean redeployment itself should not be a big deal, since we can track the previous deployment and distribute it to the server groups where it's deployed - although a failed deployment cannot be really rolled back.

New deployments also don't really seem to work since you would need to associate the deployment with it's server-groups/servers - where this cannot be really added that by default.

Yeah I don't see any other way to do hot-deployment at the domain level.  A directory per server group, and then I guess we'd generate a deployment plan based on what directory/directories a deployment is installed in?  Maybe the rollback policy would be applied to the hot deploy system as a whole.  Dunno it all sounds pretty complicated.  Maybe we should just limit hot deployment to standalone instances.

Your standalone structure could support multiple servers, if we wanted; just copy server/ to server1/ and pass a cmd line flag indicating which you want. That's ok for a developer use case.

Not so good for a production use case, due to patching. If someone patches the Server associated with server/, then server1/ is patched as well. Which may or may not be desirable.

This kind of problem is one reason I don't want to support multiple domains on the same repository. This, plus it's just not a required thing and we have a lot on our plate without adding new unrequired things. :-).  The domain case though is a bit different from standalone server; we've never had a domain, so there is no "takeaway" involved in not allowing multiple domains on the same installation.

Bottom line though, I'm ok with not supporting multiple standalone servers off the same installation. IMO the production problem with patching trumps. If devs want to run multiple servers, we should make it easy to set up a domain. If devs or production really really want to share the same module repository from multiple standalone servers, they can use symlinks or cmd line args to point to a shared repo, but then they take responsibility for problems like coordinating patching.