geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Schuchardt <bschucha...@pivotal.io>
Subject Re: Loner changes its membership port when starting an acceptor
Date Tue, 15 Jan 2019 19:28:28 GMT
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 <bschuchardt@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);*
>>>>     }
>>>>

Mime
View raw message