[
https://issues.apache.org/jira/browse/GEODE-6285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-6285:
-----------------------------
Description:
When the default member name is empty, Geode uses DistributedMember.getId()
instead of DistributedMember.getName() in the MBean names. If the member is a
Loner (no cluster) then it will mutate the string returned from
DistributedMember.getId() at runtime if a CacheServer or GatewayReceiver is
created and started.
Example:
When GatewayReceiver is created, Geode creates a GatewayReceiverMXBean with the
ObjectName
``"GemFire:service=CacheServer,port=`{0`},type=Member,member=`{1`}"``. The
```{1`}`` parameter value is ``10.118.20.84(28927-loner)-0-6ea32c5`` which
contains a zero where the membership port would normally be displayed:
bq.
GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-0-6ea32c59
Then when the GatewayReceiver is started, Geode fails to update the
GatewayReceiverMXBean state to reflect that it's running because the simple act
of starting the GatewayReceiver resulted in the changing of
DistributedMember.getId() to replace the membership port of zero with the port
that the GatewayReceiver is now listening on:
bq.
GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-5362-6ea32c59
Internally the code tries to find an existing GatewayReceiverMXBean with that
ObjectName and returns null. The code after that doesn't expect the MBean to be
null, so updating it fails. Later if the GatewayReceiver is destroyed, it also
fails to unregister the MBean as well.
was:
When the default member name is empty, Geode uses DistributedMember.getId()
instead of DistributedMember.getName() in the MBean names. If the member is a
Loner (no cluster) then it will mutate the string returned from
DistributedMember.getId() at runtime if a CacheServer or GatewayReceiver is
created and started.
Example:
When GatewayReceiver is created, Geode creates a GatewayReceiverMXBean with the
ObjectName ``"GemFire:service=CacheServer,port={0},type=Member,member={1}"``.
The ``{1}`` parameter value is ``10.118.20.84(28927-loner)-0-6ea32c5`` which
contains a zero where the membership port would normally be displayed:
bq.
GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-0-6ea32c59
Then when the GatewayReceiver is started, Geode fails to update the
GatewayReceiverMXBean state to reflect that it's running because the simple act
of starting the GatewayReceiver resulted in the changing of
DistributedMember.getId() to replace the membership port of zero with the port
that the GatewayReceiver is now listening on:
bq.
GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-5362-6ea32c59
Internally the code tries to find an existing GatewayReceiverMXBean with that
ObjectName and returns null. The code after that doesn't expect the MBean to be
null, so updating it fails. Later if the GatewayReceiver is destroyed, it also
fails to unregister the MBean as well.
> MBean names in Loner are not stable when member name is empty
> -------------------------------------------------------------
>
> Key: GEODE-6285
> URL: https://issues.apache.org/jira/browse/GEODE-6285
> Project: Geode
> Issue Type: Bug
> Components: jmx
> Reporter: Kirk Lund
> Priority: Major
>
> When the default member name is empty, Geode uses DistributedMember.getId()
> instead of DistributedMember.getName() in the MBean names. If the member is a
> Loner (no cluster) then it will mutate the string returned from
> DistributedMember.getId() at runtime if a CacheServer or GatewayReceiver is
> created and started.
> Example:
> When GatewayReceiver is created, Geode creates a GatewayReceiverMXBean with
> the ObjectName
> ``"GemFire:service=CacheServer,port=`{0`},type=Member,member=`{1`}"``. The
> ```{1`}`` parameter value is ``10.118.20.84(28927-loner)-0-6ea32c5`` which
> contains a zero where the membership port would normally be displayed:
> bq.
> GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-0-6ea32c59
> Then when the GatewayReceiver is started, Geode fails to update the
> GatewayReceiverMXBean state to reflect that it's running because the simple
> act of starting the GatewayReceiver resulted in the changing of
> DistributedMember.getId() to replace the membership port of zero with the
> port that the GatewayReceiver is now listening on:
> bq.
> GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-5362-6ea32c59
> Internally the code tries to find an existing GatewayReceiverMXBean with that
> ObjectName and returns null. The code after that doesn't expect the MBean to
> be null, so updating it fails. Later if the GatewayReceiver is destroyed, it
> also fails to unregister the MBean as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
