You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Kirk Lund <kl...@apache.org> on 2019/01/15 00:45:20 UTC
Loner changes its membership port when starting an acceptor
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);*
}
Re: Loner changes its membership port when starting an acceptor
Posted by Kirk Lund <kl...@apache.org>.
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 <bs...@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 <
> bschuchardt@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 <
> 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);*
> >>>>>> }
> >>>>>>
>
Re: Loner changes its membership port when starting an acceptor
Posted by Bruce Schuchardt <bs...@pivotal.io>.
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 <bs...@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 <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);*
>>>>>> }
>>>>>>
Re: Loner changes its membership port when starting an acceptor
Posted by Kirk Lund <kl...@pivotal.io>.
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 <bs...@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 <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);*
> >>>> }
> >>>>
>
Re: Loner changes its membership port when starting an acceptor
Posted by Bruce Schuchardt <bs...@pivotal.io>.
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 <bs...@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);*
>>>> }
>>>>
Re: Loner changes its membership port when starting an acceptor
Posted by Kirk Lund <kl...@apache.org>.
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 <bs...@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);*
> >> }
> >>
>
Re: Loner changes its membership port when starting an acceptor
Posted by Bruce Schuchardt <bs...@pivotal.io>.
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);*
>> }
>>
Re: Loner changes its membership port when starting an acceptor
Posted by Bruce Schuchardt <bs...@pivotal.io>.
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);*
> }
>