Ah! I forgot about that (trying to do too many things at once). I'll file a
ticket to fix it up. Thanks!
On Wed, Jan 16, 2019 at 3:47 PM Bruce Schuchardt <bschucha...@pivotal.io>
wrote:
> 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 <
> bschucha...@pivotal.io>
> > 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 <
> bschucha...@pivotal.io
> >>>
> >>> 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
> NPE
> >>>>>> 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
> we
> >>>>>> 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
> from
> >>>>>> %s to
> >>>>>> %s. ID is now %s",
> >>>>>> new Object[] {this.lonerPort, newPort, getId()}));
> >>>>>> this.lonerPort = newPort;
> >>>>>> *this.getId().setPort(this.lonerPort);*
> >>>>>> }
> >>>>>>
>
