[
https://issues.apache.org/jira/browse/GEODE-6285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund resolved GEODE-6285.
------------------------------
Resolution: Fixed
Fix Version/s: 1.9.0
Introduced new DistributedMember.getUniqueId() API which is now used for naming
MBeans if member name is not provided by User.
> 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
> Assignee: Kirk Lund
> Priority: Major
> Labels: pull-request-available
> Fix For: 1.9.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> 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:
> {noformat}
> GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-0-6ea32c59
> {noformat}
> 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:
> {noformat}
> GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-5362-6ea32c59
> {noformat}
> 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)
