geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Schuchardt <>
Subject Re: Loner changes its membership port when starting an acceptor
Date Wed, 16 Jan 2019 23:47:33 GMT
Hmm, okay but I was looking at this code in MBeanJMXAdapter:

public static String getMemberNameOrId(DistributedMember member) {
   if (member.getName() !=null && !member.getName().equals("")) {
     return makeCompliantName(member.getName());
   return makeCompliantName(member.getId());

So if there isn't a name set in the distribution configuration it will 
use the toString of the member ID.  I think that's what's happening to 
you.  The getName() method in InternalDistributedMember doesn't return a 
string like you've described.  It returns whatever was configured as the 
"name" in the distribution configuration properties.

On 1/16/19 1:27 PM, Kirk Lund wrote:
> It's not using toString(). It's just using DistributedMember.getName().
> This is implemented by InternalDistributedMember.getName() which delegates
> to NetMember.getName(). Are you saying we should add a new method to
> DistributedMember instead of using getName()?
> The mbeans are categorized a type of Member or Distributed. Member means
> the mbean represents something about a member, while the other type means
> that the mbean represents something about the DistributedSystem/Cluster
> (aggregating all Members together in some way). When the type is Member,
> the ObjectName contains:
> "type=Member,member={0}"
> MBeanJMXAdapter creates the ObjectNames by filling in that parameter with
> DistributedMember.getName(). We originally documented that the ObjectNames
> would contain the DistributedMember.getName(), but we could change that by
> adding a new getMBeanName() method or something like that. I think we
> originally thought it would be nice for the User if they could simply refer
> to DistributedMember.getName() as being the same value as we use in the JMX
> ObjectName.
> On Tue, Jan 15, 2019 at 11:28 AM Bruce Schuchardt <>
> wrote:
>> Yeah, let's fix this, but let's not require the toString() of an object
>> to never change.  Let's add another method that returns a Bean
>> identifier and is documented to never change.
>> On 1/15/19 9:45 AM, Kirk Lund wrote:
>>> Sorry about the confusion. I meant that the change of membership port
>>> results in DistributedMember returning a different string from its
>>> getName() method.
>>> We discovered this because the JMX layer has some error handling that
>>> results in suppressing this failure, so the failure was being hidden. We
>>> cleaned up the error handling and saw quite a few failures in precheckin
>>> caused by this. I figured it was more correct to fix the underlying
>> problem
>>> rather than restore the suppression of this bug.
>>> On Tue, Jan 15, 2019 at 7:47 AM Bruce Schuchardt <
>>> wrote:
>>>> Actually the formatting code would go in InternalDistributedMember.  The
>>>> JMX code already has a special method for handling that class.  I was
>>>> thrown off by the reference to a non-existant getName() method in
>>>> LonerDistributionManager.
>>>> On 1/15/19 7:34 AM, Bruce Schuchardt wrote:
>>>>> I think we could solve this by either moving the ID formatting code to
>>>>> the DistributionManager implementations & having
>>>>> LonerDistributionManager omit the port number or modify the
>>>>> client/server handshake to not install a port number when connecting
>>>>> to a remote GatewayReceiver.  I guess the latter wouldn't work if the
>>>>> bean is in a real client cache.
>>>>> The installation of a port number was implemented to prevent duplicate
>>>>> membership IDs in client caches when clients are being spun up in
>>>>> parallel on the same machine.  However there is also a "unique ID" in
>>>>> LonerDistributionManager that was supposed to address this problem but
>>>>> apparently didn't.
>>>>> On 1/14/19 4:45 PM, Kirk Lund wrote:
>>>>>> So I was stepping through some WAN tests in IJ debugger (on develop
>>>>>> with no
>>>>>> changes) and discovered that any MXBeans that are created before
>>>>>> starting a
>>>>>> server port (either using CacheServer or GatewayReceiver) are broken
>> and
>>>>>> fail to be updated after that -- the ObjectNames include the
>>>>>> DistributedMember.getName(). Turns out some JMX code is eating an
>>>>>> that's caused because the LonerDistributionManager changes its
>>>>>> membership
>>>>>> port when an acceptor endpoint is started up.
>>>>>> Below is the method in LonerDistributionManager (with some other
>>>>>> issues as
>>>>>> well) that does this updating. We either need to make a lot of
>>>>>> changes to
>>>>>> the JMX code to fix this or we need to make one small change to
>>>>>> LonerDistributionManager (ie, to delete this method). Question: do
>>>>>> really need the DistributedMember of a Loner to change its getName()
>>>>>> which
>>>>>> includes the membership port that changed?
>>>>>>      /**
>>>>>>       * update the loner port with an integer that may be more unique
>>>>>> than the
>>>>>> default port (zero).
>>>>>>       * This updates the ID in place and establishes new default
>>>>>> settings for
>>>>>> the manufacture of new
>>>>>>       * IDs.
>>>>>>       *
>>>>>>       * @param newPort the new port to use
>>>>>>       */
>>>>>>      public void updateLonerPort(int newPort) {
>>>>>>        this.logger.config(
>>>>>>            String.format("Updating membership port.  Port changed
>>>>>> %s to
>>>>>> %s.  ID is now %s",
>>>>>>                new Object[] {this.lonerPort, newPort, getId()}));
>>>>>>        this.lonerPort = newPort;
>>>>>>        *this.getId().setPort(this.lonerPort);*
>>>>>>      }

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message