The node name concept configured via -Djboss.node.name is a clustering concept not a
general managment one. You can set the node name by setting the server name, so that’s the
way to do it. Don’t try the other way around.
The server name can also be set via system property for standalone servers:
-Djboss.server.name
So there is no need to edit xml.
In a managed domain if a server process doesn’t have jboss.node.name set, the node name
will be <hc_name>:<server_name>. It needs to be a tuple like that as only that
tuple is required to be unique in a domain. Node name needs to be unique across a
cluster.
The discrepancy is because the jboss.node.name property is only used for some clustering
stuff and has never been part of AS 7+’s algorithm for establishing the server’s name for
management purposes. IIRC it was added to AS7 account for some use case previously not
handled in domain mode — but now handled better — or perhaps it was added in to be more
like AS < 7 where that property was long used in clustering. Probably both.
I don’t think the jboss.node.name property is even needed any more. But, we’re not going
to drop support of jboss.node.name as that may break some people. And I don’t think we’ll
add jboss.node.name to the algorithm for setting the server name, as that may break people
as well.
--
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat
On Jun 28, 2016, at 4:56 PM, John Mazzitelli <mazz(a)redhat.com>
wrote:
> Dear John,
>
> Suppose you have two JBoss instances running on one (the same) host (using
> e.g. port offset) identifying both would be done by explicitly setting the
> jboss.node.name so this is expected behavior. Otherwise there would be a
> conflict. (In our development stage we have over 30 JBoss servers running
> on the same host, all being tied up to JGroups).
In that case, both of your servers would have identical "name" values (your
hostname). That seems "odd" in that the name for multiple servers are the same -
so their "name"s are not unique - but perhaps that is why WF 10 introduced the
UUID attribute?
Still, not sure why the discrepancy between jboss.node.name and <server name> - you
would think they both would behave the same, but do not.
>
> Regards Dennis
>
> On Tue, Jun 28, 2016 at 11:30 PM, John Mazzitelli <mazz(a)redhat.com> wrote:
>
>> There is some confusion about setting the WildFly node name (at least in
>> the standalone server case).
>>
>> <tl;dr>
>> QUESTION: How does one change the server's cluster node name (say, for
>> the JGroups configuration). I thought both would be equivalent (either
>> setting <server name="a"> or setting -Djboss.node.name=a) but
that does
>> not seem to be the case.
>> </tl;dr>
>>
>> Suppose I start WildFly via standalone.sh (with its stock out of box
>> standalone.xml) but with the command line option:
>>
>> -Djboss.node.name=wotgorilla
>>
>> When I do this, I see the node-name (in the server-environment subsystem)
>> set to "wotgorilla" but the server's name is my normal hostname (in
this
>> case "mazztower"):
>>
>> /core-service=server-environment/:read-attribute(name=node-name)
>> {
>> "outcome" => "success",
>> "result" => "wotgorilla"
>> }
>>
>> /:read-attribute(name=name)
>> {
>> "outcome" => "success",
>> "result" => "mazztower"
>> }
>>
>> OK, but now suppose I edit standalone.xml - in the top-level root element
>> <server> I add the name attribute:
>>
>> <server name="foobar">
>>
>> and I start the server WITHOUT any commmand line options (just
>> "standalone.sh"). I see that BOTH "name" and
"node-name" match my new
>> server name:
>>
>> /core-service=server-environment/:read-attribute(name=node-name)
>> {
>> "outcome" => "success",
>> "result" => "foobar"
>> }
>>
>> /:read-attribute(name=name)
>> {
>> "outcome" => "success",
>> "result" => "foobar"
>> }
>>
>> QUESTION: Why the discrepency? Is this a bug or expected behavior? How
>> does one change the server's cluster node name (say, for the JGroups
>> configuration). I thought both would be equivalent (either setting <server
>> name="a"> or setting jboss.node.name) but that does not seem to be
the
>> case.
>>
>> Thanks,
>> John Mazz
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
>
> --
> Best regards,
>
> *Dennis Brouwer*
> Extraordinary Goalkeeper
>
>
>
>
> ZEEF - Kizitos B.V.
> Amstelboulevard 184
> 1096 HM Amsterdam
>
www.ZEEF.com <
http://www.zeef.com/> <
http://www.zeef.com/
<
http://www.zeef.com/>>
> US: +1 (415) 992-9409
> NL: +31 (085) 888-3186
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
<
https://lists.jboss.org/mailman/listinfo/wildfly-dev>