[
https://issues.apache.org/jira/browse/GEODE-9290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kamilla Aslami updated GEODE-9290:
----------------------------------
Description:
This issue was found on RedHat8. While running a test that creates a
partitioned region with redundancy 1 and does various entry operations, we
noticed this warning in the logs:
Configured redundancy level could not be satisfied. Advise you to start enough
data store nodes to satisfy redundancy for the region. Partitioned Region name
= /partitionedRegion Redundancy level set to 1 . Number of available data
stores: 10 . Number successfully allocated = 1 .
Additional logging showed that Geode thinks all the hosts are equivalent, i.e.
the values of {{equivalentHosts}} map in {{ClusterDistributionManager}} contain
localhost addresses:
{noformat}
{/10.32.110.176=[/10.32.110.176, /127.0.0.1], /127.0.0.1=[/10.32.109.148,
/127.0.0.1], /10.32.109.148=[/10.32.109.148, /127.0.0.1],
/0:0:0:0:0:ffff:7f00:1%lo=[/10.32.109.148, /0:0:0:0:0:ffff:7f00:1%lo]}
{noformat}
Further analysis revealed that the issue is related to
{{LocalHostUtil.getMyAddresses()}} method. Additional logging showed that this
method always returns an IPv4 and this IPv6
address:{{0:0:0:0:0:ffff:7f00:1%lo}} . Looking closer at the IPv6 address, we
realized that it is in fact an IPv4-mapped IPv6 address that represents
{{127.0.0.1}}. The problem with {{0:0:0:0:0:ffff:7f00:1%lo}} is that
isLoopbackAddress() method returns false for this address because the IPv6
loopback address is {{/0:0:0:0:0:0:0:1%lo}}. This part of the [Inet6Address
documentation|https://docs.oracle.com/javase/8/docs/api/java/net/Inet6Address.html#format]:
{quote}IPv4-mapped address:
Of the form::ffff:w.x.y.z, this IPv6 address is used to represent an IPv4
address. It allows the native program to use the same address data structure
and also the same socket when communicating with both IPv4 and IPv6 nodes.In
InetAddress and Inet6Address, it is used for internal representation; it has no
functional role. Java will never return an IPv4-mapped address. These classes
can take an IPv4-mapped address as input, both in byte array and text
representation. However, it will be converted into an IPv4 address.
{quote}
claims that {{Java will never return an IPv4-mapped address}}. And the
implementation of {{InetAddress.getByAddress()}} and
{{InetAddress.getByName()}} methods is consistent with this claim because both
internally call {{IPAddressUtil.convertFromIPv4MappedAddress()}} that converts
an IPv4-mapped IPv6 address to IPv4 address. However,
{{NetworkInterface.getInetAddresses()}} method (which is used in
{{LocalHostUtil.getMyAddresses()}}) should also not return an IPv4-mapped IPv6
address, but it does.
Although this looks like a bug in the jdk, we can avoid IPv4 mapped IPv6
addresses by manually converting them to IPv4 addresses in
{{LocalHostUtil.getMyAddresses()}}.
was:
This issue was found on RedHat8. While running a test that creates a
partitioned region with redundancy 1 and does various entry operations, we
noticed this warning in the logs:
Configured redundancy level could not be satisfied. Advise you to start enough
data store nodes to satisfy redundancy for the region. Partitioned Region name
= /partitionedRegion Redundancy level set to 1 . Number of available data
stores: 10 . Number successfully allocated = 1 .
Additional logging showed that Geode thinks all the hosts are equivalent, i.e.
the values of {{equivalentHosts}} map in {{ClusterDistributionManager}} contain
localhost addresses:
{noformat}
{/10.32.110.176=[/10.32.110.176, /127.0.0.1], /127.0.0.1=[/10.32.109.148,
/127.0.0.1], /10.32.109.148=[/10.32.109.148, /127.0.0.1],
/0:0:0:0:0:ffff:7f00:1%lo=[/10.32.109.148, /0:0:0:0:0:ffff:7f00:1%lo]}
{noformat}
Further analysis revealed that the issue is related to
{{LocalHostUtil.getMyAddresses()}} method. Additional logging showed that this
method always returns an IPv4 and this IPv6
address:{{0:0:0:0:0:ffff:7f00:1%lo}} . Looking closer at the IPv6 address, we
realized that it is in fact an IPv4-mapped IPv6 address that represents
{{127.0.0.1}}. The problem with {{0:0:0:0:0:ffff:7f00:1%lo}} is that
isLoopbackAddress() method returns false for this address because the IPv6
loopback address is {{/0:0:0:0:0:0:0:1%lo}}. This part of the [Inet6Address
documentation|https://docs.oracle.com/javase/8/docs/api/java/net/Inet6Address.html#format]:
{quote}{{IPv4-mapped address:
Of the form::ffff:w.x.y.z, this IPv6 address is used to represent an IPv4
address. It allows the native program to use the same address data structure
and also the same socket when communicating with both IPv4 and IPv6 nodes.In
InetAddress and Inet6Address, it is used for internal representation; it has no
functional role. Java will never return an IPv4-mapped address. These classes
can take an IPv4-mapped address as input, both in byte array and text
representation. However, it will be converted into an IPv4 address.}}
{quote}
claims that {{Java will never return an IPv4-mapped address}}. And the
implementation of {{InetAddress.getByAddress()}} and
{{InetAddress.getByName()}} methods is consistent with this claim because both
internally call {{IPAddressUtil.convertFromIPv4MappedAddress()}} that converts
an IPv4-mapped IPv6 address to IPv4 address. However,
{{NetworkInterface.getInetAddresses()}} method (which is used in
{{LocalHostUtil.getMyAddresses()}}) should also not return an IPv4-mapped IPv6
address, but it does.
Although this looks like a bug in the jdk, we can avoid IPv4 mapped IPv6
addresses by manually converting them to IPv4 addresses in
{{LocalHostUtil.getMyAddresses()}}.
> LocalHostUtil.getMyAddresses should not return IPv4-mapped IPv6 addresses
> -------------------------------------------------------------------------
>
> Key: GEODE-9290
> URL: https://issues.apache.org/jira/browse/GEODE-9290
> Project: Geode
> Issue Type: Bug
> Components: membership
> Reporter: Kamilla Aslami
> Assignee: Kamilla Aslami
> Priority: Major
>
> This issue was found on RedHat8. While running a test that creates a
> partitioned region with redundancy 1 and does various entry operations, we
> noticed this warning in the logs:
> Configured redundancy level could not be satisfied. Advise you to start
> enough data store nodes to satisfy redundancy for the region. Partitioned
> Region name = /partitionedRegion Redundancy level set to 1 . Number of
> available data stores: 10 . Number successfully allocated = 1 .
> Additional logging showed that Geode thinks all the hosts are equivalent,
> i.e. the values of {{equivalentHosts}} map in {{ClusterDistributionManager}}
> contain localhost addresses:
> {noformat}
> {/10.32.110.176=[/10.32.110.176, /127.0.0.1], /127.0.0.1=[/10.32.109.148,
> /127.0.0.1], /10.32.109.148=[/10.32.109.148, /127.0.0.1],
> /0:0:0:0:0:ffff:7f00:1%lo=[/10.32.109.148, /0:0:0:0:0:ffff:7f00:1%lo]}
> {noformat}
> Further analysis revealed that the issue is related to
> {{LocalHostUtil.getMyAddresses()}} method. Additional logging showed that
> this method always returns an IPv4 and this IPv6
> address:{{0:0:0:0:0:ffff:7f00:1%lo}} . Looking closer at the IPv6 address, we
> realized that it is in fact an IPv4-mapped IPv6 address that represents
> {{127.0.0.1}}. The problem with {{0:0:0:0:0:ffff:7f00:1%lo}} is that
> isLoopbackAddress() method returns false for this address because the IPv6
> loopback address is {{/0:0:0:0:0:0:0:1%lo}}. This part of the [Inet6Address
> documentation|https://docs.oracle.com/javase/8/docs/api/java/net/Inet6Address.html#format]:
> {quote}IPv4-mapped address:
> Of the form::ffff:w.x.y.z, this IPv6 address is used to represent an IPv4
> address. It allows the native program to use the same address data structure
> and also the same socket when communicating with both IPv4 and IPv6 nodes.In
> InetAddress and Inet6Address, it is used for internal representation; it has
> no functional role. Java will never return an IPv4-mapped address. These
> classes can take an IPv4-mapped address as input, both in byte array and text
> representation. However, it will be converted into an IPv4 address.
> {quote}
> claims that {{Java will never return an IPv4-mapped address}}. And the
> implementation of {{InetAddress.getByAddress()}} and
> {{InetAddress.getByName()}} methods is consistent with this claim because
> both internally call {{IPAddressUtil.convertFromIPv4MappedAddress()}} that
> converts an IPv4-mapped IPv6 address to IPv4 address. However,
> {{NetworkInterface.getInetAddresses()}} method (which is used in
> {{LocalHostUtil.getMyAddresses()}}) should also not return an IPv4-mapped
> IPv6 address, but it does.
> Although this looks like a bug in the jdk, we can avoid IPv4 mapped IPv6
> addresses by manually converting them to IPv4 addresses in
> {{LocalHostUtil.getMyAddresses()}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
