[jboss-as7-dev] Domain mode server launch command

[Brian Stansberry]

Then how about this:

<launch-command prefix="numactl --membind 1 --cpubind 1"/>

If we ever find a use case for a suffix, we just add the attribute.

On 8/14/12 12:28 PM, John O'Hara wrote:
> I think the launch-command-prefix is probably more suitable, as
> ModelCombiner already does a good job at defining which java command to run.
>
> atm I can not think of a use case for a launch-command-suffix element
>
> re [1] - I noticed this up after I sent the email
>
> On 08/14/2012 06:03 PM, Brian Stansberry wrote:
>> That's along the lines of what I was thinking for the "different user
>> account" case.
>>
>> Something to think about is whether "java" should be in the
>> launch-command[1] value (with a default value of just "java".) If not
>> it's really a launch-command-prefix, and then is there a use case for
>> launch-command-suffix?
>>
>> I think using a separate child element for this instead of an attribute
>> is better.
>>
>> Another question is whether it makes sense to allow this to be
>> configured at the server-group level, with servers by default inheriting
>> that config. My vote is "no." KISS. If there is demand for doing it at
>> the server-group level, we'll here about it and can add it later.
>>
>> As for validation, I doubt we can do much there. I think this would be
>> an advanced feature where users are going to have to be careful and test
>> things.
>>
>> [1] Note our schema uses lower case names with "-" as a separator, not
>> camel case. So "launch-command" not "launchCommand".
>>
>> On 8/14/12 11:49 AM, John O'Hara wrote:
>>> When running AS7 in a domain, we need to be able to bind each host to
>>> explicit numa nodes when the process is launched. We need to be able to
>>> insert a numa command before the java command for each server process
>>> that is launched by the HostController. The numa command needs to be
>>> configurable for each host, i.e. we might want to bind hosts to
>>> different numa nodes or the same numa node.
>>>
>>> Another use case that I am aware of is running the server process under
>>> a different user account to the HostController, e.g. prefixing the java
>>> command with something like "sudo joe java"
>>>
>>> Having thought about our use case and a use case where the host should
>>> start start under a different account , a possible solution could be to
>>> modify the AS config schema to allow a generic "launch command" for each
>>> server entity, so that the host.xml would look something like;
>>>
>>>              <server name="server-one" group="main-server-group"
>>> launchCommand="numactl --membind 0 --cpubind 0"/>
>>>              <server name="server-two" group="main-server-group"
>>> auto-start="true" launchCommand="numactl --membind 1 --cpubind 1">
>>>                  <!-- server-two avoids port conflicts by incrementing the
>>> ports in
>>>                       the default socket-group declared in the server-group
>>> -->
>>>                  <socket-bindings port-offset="150"/>
>>>              </server>
>>>              <server name="server-three" group="main-server-group"
>>> auto-start="true" launchCommand="sudo joe">
>>>                  <!-- server-two avoids port conflicts by incrementing the
>>> ports in
>>>                       the default socket-group declared in the server-group
>>> -->
>>>                  <socket-bindings port-offset="150"/>
>>>              </server>
>>>
>>> If a launchCommand attribute was defined for a server, you could parse
>>> the attribute value and add the parsed commands to the ProcessBuilder
>>> before the java command.
>>>
>>> The main difficulty would be validating any commands added in
>>> launchCommand attribute, not sure how problematic this would be?
>>>
>>> Regards,
>>>
>>> John
>>>
>>
>
>


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat