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);*
> >> }
> >>
>
