[jira] [Closed] (GEODE-9328) Cleanup remains of ACE library
[ https://issues.apache.org/jira/browse/GEODE-9328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres closed GEODE-9328. -- > Cleanup remains of ACE library > -- > > Key: GEODE-9328 > URL: https://issues.apache.org/jira/browse/GEODE-9328 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: obliterate-ace > > *AS A* native client contributor > *I WANT TO* remove all remaining references to ACE library > *SO THAT* eventually we can get rid of ACE library > > *Additional information.* Note that all header inclusions, lib linkage and > CMake dependency project will need to be cleaned up here. > Also, additional changes might be needed to make the project compile, take it > into account. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-9328) Cleanup remains of ACE library
[ https://issues.apache.org/jira/browse/GEODE-9328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres resolved GEODE-9328. Resolution: Fixed > Cleanup remains of ACE library > -- > > Key: GEODE-9328 > URL: https://issues.apache.org/jira/browse/GEODE-9328 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: obliterate-ace > > *AS A* native client contributor > *I WANT TO* remove all remaining references to ACE library > *SO THAT* eventually we can get rid of ACE library > > *Additional information.* Note that all header inclusions, lib linkage and > CMake dependency project will need to be cleaned up here. > Also, additional changes might be needed to make the project compile, take it > into account. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-10074) Remove ACE remains
[ https://issues.apache.org/jira/browse/GEODE-10074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres resolved GEODE-10074. - Resolution: Fixed > Remove ACE remains > -- > > Key: GEODE-10074 > URL: https://issues.apache.org/jira/browse/GEODE-10074 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: obliterate-ace, pull-request-available > > *AS A* geode-native contributor > *I WANT TO* remove all the ACE remaining > *SO THAT* geode-native does not depend on ACE anymore -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (GEODE-10074) Remove ACE remains
[ https://issues.apache.org/jira/browse/GEODE-10074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres closed GEODE-10074. --- > Remove ACE remains > -- > > Key: GEODE-10074 > URL: https://issues.apache.org/jira/browse/GEODE-10074 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: obliterate-ace, pull-request-available > > *AS A* geode-native contributor > *I WANT TO* remove all the ACE remaining > *SO THAT* geode-native does not depend on ACE anymore -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10189) Errors encountered during Apache Geode upgrade
[
https://issues.apache.org/jira/browse/GEODE-10189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17525627#comment-17525627
]
Swetha Sudheesh commented on GEODE-10189:
-
The dependencies which I have added for Apache Geode upgrade 1.14.1 version
were referred from
"[https://mvnrepository.com/artifact/org.apache.geode/geode-core/1.14.1.";|https://mvnrepository.com/artifact/org.apache.geode/geode-core/1.14.1.%22]
You may also note that, JGroups is working fine with 3.6.14.Final version, but
is giving error for 5.2.2.Final version.
> Errors encountered during Apache Geode upgrade
> --
>
> Key: GEODE-10189
> URL: https://issues.apache.org/jira/browse/GEODE-10189
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.1
>Reporter: Swetha Sudheesh
>Priority: Critical
>
> We are trying to upgrade Apache Geode from *1.8.0* version to *1.14.1*
> version to avoid any vulnerabilities. We also added all the dependencies
> mentioned in the Maven with the latest versions. Our application uses {*}JDK
> 11{*}. We faced few issues such as the one described below:
>
> Exception in thread "Locator" *java.lang.ExceptionInInitializerError*
> at
> org.apache.geode.distributed.internal.membership.gms.Services.(Services.java:155)
> at
> org.apache.geode.distributed.internal.membership.gms.MembershipBuilderImpl.create(MembershipBuilderImpl.java:114)
> at
> org.apache.geode.distributed.internal.DistributionImpl.(DistributionImpl.java:152)
> at
> org.apache.geode.distributed.internal.DistributionImpl.createDistribution(DistributionImpl.java:219)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:464)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:497)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:326)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:756)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:132)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3011)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:282)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:746)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:392)
> at
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:716)
>
> Caused by: *java.lang.IllegalStateException: JGAddress.create() returned the
> wrong class: UUID*
> at org.jgroups.conf.ClassConfigurator.add(ClassConfigurator.java:101)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.(JGroupsMessenger.java:167)
> ... 17 more
> Please let us know why we are encountering this error and how can it be
> resolved? Also let us know the right dependencies that need to be added for
> Apache Geode 1.14.1 upgrade.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10215) WAN replication not working after re-creating the partitioned region
[
https://issues.apache.org/jira/browse/GEODE-10215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17525678#comment-17525678
]
Jakov Varenina commented on GEODE-10215:
Hi [~agingade] ,
After checking this issue in more detail, the procedure described in this
ticket now doesn't seem correct. I think that it shouldn't be allowed to remove
the gateway sender with the "alter region" command from a partition region that
has no colocated sub-regions utilizing the same gateway sender. In this case,
for me, it only makes sense to destroy the gateway-sender before destroying the
region. Otherwise, if we use the "alter region" command, we leave the
gateway-sender and its colocated partition region buckets unnecessarily hanging
in the system. If we reuse that gateway-sender for the other region, we get the
issue described in this ticket.
What do you think? Do you see any valid scenario where you would use alter
region gateway-sender-id="" command for the partition region that doesn't have
colocated regions?
> WAN replication not working after re-creating the partitioned region
>
>
> Key: GEODE-10215
> URL: https://issues.apache.org/jira/browse/GEODE-10215
> Project: Geode
> Issue Type: Bug
>Reporter: Jakov Varenina
>Assignee: Jakov Varenina
>Priority: Major
>
> Steps to reproduce the issue:
> Start multi-site with at least 3 servers on each site. If there are less than
> three servers then issue will not reproduce.
> Configuration site 1:
> {code:java}
> create disk-store --name=queue_disk_store --dir=ds2
> create gateway-sender -id="remote_site_2" --parallel="true"
> --remote-distributed-system-id="1" -enable-persistence=true
> --disk-store-name=queue_disk_store
> create disk-store --name=data_disk_store --dir=ds1
> create region --name=example-region --type=PARTITION_PERSISTENT
> --gateway-sender-id="remote_site_2" --disk-store=data_disk_store
> --total-num-buckets=1103 --redundant-copies=1 --enable-synchronous-disk=false
> #Configure the remote site 2 with the region and the gateway-receiver
> #Run some traffic so that all buckets are created and data is replicated to
> the other site
> alter region --name=/example-region --gateway-sender-id=""
> destroy region --name=/example-region
> create region --name=example-region --type=PARTITION_PERSISTENT
> --gateway-sender-id="remote_site_2" --disk-store=data_disk_store
> --total-num-buckets=1103 --redundant-copies=1 --enable-synchronous-disk=false
> #run traffic to see that some data is not replicated to the remote site 2
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] (GEODE-10215) WAN replication not working after re-creating the partitioned region
[ https://issues.apache.org/jira/browse/GEODE-10215 ]
Jakov Varenina deleted comment on GEODE-10215:
was (Author: jvarenina):
Hi [~agingade] ,
After checking this issue in more detail, the procedure described in this
ticket now doesn't seem correct. I think that it shouldn't be allowed to remove
the gateway sender with the "alter region" command from a partition region that
has no colocated sub-regions utilizing the same gateway sender. In this case,
for me, it only makes sense to destroy the gateway-sender before destroying the
region. Otherwise, if we use the "alter region" command, we leave the
gateway-sender and its colocated partition region buckets unnecessarily hanging
in the system. If we reuse that gateway-sender for the other region, we get the
issue described in this ticket.
What do you think? Do you see any valid scenario where you would use alter
region gateway-sender-id="" command for the partition region that doesn't have
colocated regions?
> WAN replication not working after re-creating the partitioned region
>
>
> Key: GEODE-10215
> URL: https://issues.apache.org/jira/browse/GEODE-10215
> Project: Geode
> Issue Type: Bug
>Reporter: Jakov Varenina
>Assignee: Jakov Varenina
>Priority: Major
>
> Steps to reproduce the issue:
> Start multi-site with at least 3 servers on each site. If there are less than
> three servers then issue will not reproduce.
> Configuration site 1:
> {code:java}
> create disk-store --name=queue_disk_store --dir=ds2
> create gateway-sender -id="remote_site_2" --parallel="true"
> --remote-distributed-system-id="1" -enable-persistence=true
> --disk-store-name=queue_disk_store
> create disk-store --name=data_disk_store --dir=ds1
> create region --name=example-region --type=PARTITION_PERSISTENT
> --gateway-sender-id="remote_site_2" --disk-store=data_disk_store
> --total-num-buckets=1103 --redundant-copies=1 --enable-synchronous-disk=false
> #Configure the remote site 2 with the region and the gateway-receiver
> #Run some traffic so that all buckets are created and data is replicated to
> the other site
> alter region --name=/example-region --gateway-sender-id=""
> destroy region --name=/example-region
> create region --name=example-region --type=PARTITION_PERSISTENT
> --gateway-sender-id="remote_site_2" --disk-store=data_disk_store
> --total-num-buckets=1103 --redundant-copies=1 --enable-synchronous-disk=false
> #run traffic to see that some data is not replicated to the remote site 2
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10215) WAN replication not working after re-creating the partitioned region
[
https://issues.apache.org/jira/browse/GEODE-10215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17525696#comment-17525696
]
Jakov Varenina commented on GEODE-10215:
Hi [~agingade] ,
After checking this issue in more detail, the procedure described in this
ticket doesn't seem correct. In this case, for me, it only makes sense to
destroy the gateway-sender after altering and destroying the region. Otherwise,
we leave the gateway sender and its colocated partition region buckets
unnecessarily hanging in the system. If we reuse that gateway-sender for the
other region, we get the issue described in this ticket.
I don't see how to prevent the user from doing this because the command alter
region gateway-sender-id="" must be executed before destroying the region.
Maybe it would be good to add a note to the documentation that warns the user
about this issue and indicate good practice.
What do you think?
> WAN replication not working after re-creating the partitioned region
>
>
> Key: GEODE-10215
> URL: https://issues.apache.org/jira/browse/GEODE-10215
> Project: Geode
> Issue Type: Bug
>Reporter: Jakov Varenina
>Assignee: Jakov Varenina
>Priority: Major
>
> Steps to reproduce the issue:
> Start multi-site with at least 3 servers on each site. If there are less than
> three servers then issue will not reproduce.
> Configuration site 1:
> {code:java}
> create disk-store --name=queue_disk_store --dir=ds2
> create gateway-sender -id="remote_site_2" --parallel="true"
> --remote-distributed-system-id="1" -enable-persistence=true
> --disk-store-name=queue_disk_store
> create disk-store --name=data_disk_store --dir=ds1
> create region --name=example-region --type=PARTITION_PERSISTENT
> --gateway-sender-id="remote_site_2" --disk-store=data_disk_store
> --total-num-buckets=1103 --redundant-copies=1 --enable-synchronous-disk=false
> #Configure the remote site 2 with the region and the gateway-receiver
> #Run some traffic so that all buckets are created and data is replicated to
> the other site
> alter region --name=/example-region --gateway-sender-id=""
> destroy region --name=/example-region
> create region --name=example-region --type=PARTITION_PERSISTENT
> --gateway-sender-id="remote_site_2" --disk-store=data_disk_store
> --total-num-buckets=1103 --redundant-copies=1 --enable-synchronous-disk=false
> #run traffic to see that some data is not replicated to the remote site 2
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (GEODE-10252) Update website privacy notice
Anthony Baker created GEODE-10252: - Summary: Update website privacy notice Key: GEODE-10252 URL: https://issues.apache.org/jira/browse/GEODE-10252 Project: Geode Issue Type: Task Components: website Reporter: Anthony Baker PMC's have been instructed to: 1) Remove all use of google analytics 2) Link to the ASF privacy notice: [https://privacy.apache.org/policies/privacy-policy-public.html] AFAICT, geode.apache.org does not use google analytics. We just need to add another footer item for the privacy notice. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10242) Same tail key can be generated for different events on (different colocated regions) from different servers
[ https://issues.apache.org/jira/browse/GEODE-10242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-10242: -- Labels: GeodeOperationAPI blocks-1.15.0 pull-request-available (was: GeodeOperationAPI blocks-1.15.0 needsTriage pull-request-available) > Same tail key can be generated for different events on (different colocated > regions) from different servers > --- > > Key: GEODE-10242 > URL: https://issues.apache.org/jira/browse/GEODE-10242 > Project: Geode > Issue Type: Bug > Components: wan >Affects Versions: 1.12.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: GeodeOperationAPI, blocks-1.15.0, pull-request-available > > For colocated partition regions with parallel wan queue, rebalance could > cause primary to be moved. This can lead to a case that one server has the > primary bucket for the parent region, but another has the primary bucket for > the child region. As colocated regions show the same parallel wan queue, both > server will generate next tail key for different events. This will cause some > event not dispatched to the other wan site and thus event lost. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (GEODE-10144) Regression in geode-native test CqPlusAuthInitializeTest.reAuthenticateWithDurable
[ https://issues.apache.org/jira/browse/GEODE-10144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker reassigned GEODE-10144: - Assignee: Blake Bender (was: Jinmei Liao) > Regression in geode-native test > CqPlusAuthInitializeTest.reAuthenticateWithDurable > -- > > Key: GEODE-10144 > URL: https://issues.apache.org/jira/browse/GEODE-10144 > Project: Geode > Issue Type: Bug > Components: client/server >Affects Versions: 1.15.0 >Reporter: Blake Bender >Assignee: Blake Bender >Priority: Major > Labels: blocks-1.15.0, needsTriage > Fix For: 1.15.0 > > > This test is failing across the board in the `geode-native` PR pipeline. > Main develop pipeline is green only because nothing can get through the PR > pipeline to clear checkin gates. We have green CI runs with 1.15. build 918, > then it started failing when we picked up build 924. > > [~moleske] tracked this back to this commit: > [https://github.com/apache/geode/commit/2554f42b925f2b9b8ca7eee14c7a887436b1d9db|https://github.com/apache/geode/commit/2554f42b925f2b9b8ca7eee14c7a887436b1d9db]. > See his notes in `geode-native` PR # 947 > ([https://github.com/apache/geode-native/pull/947]) -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10144) Regression in geode-native test CqPlusAuthInitializeTest.reAuthenticateWithDurable
[ https://issues.apache.org/jira/browse/GEODE-10144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-10144: -- Labels: NativeClient (was: blocks-1.15.0 needsTriage) > Regression in geode-native test > CqPlusAuthInitializeTest.reAuthenticateWithDurable > -- > > Key: GEODE-10144 > URL: https://issues.apache.org/jira/browse/GEODE-10144 > Project: Geode > Issue Type: Bug > Components: client/server >Affects Versions: 1.15.0 >Reporter: Blake Bender >Assignee: Blake Bender >Priority: Major > Labels: NativeClient > Fix For: 1.15.0 > > > This test is failing across the board in the `geode-native` PR pipeline. > Main develop pipeline is green only because nothing can get through the PR > pipeline to clear checkin gates. We have green CI runs with 1.15. build 918, > then it started failing when we picked up build 924. > > [~moleske] tracked this back to this commit: > [https://github.com/apache/geode/commit/2554f42b925f2b9b8ca7eee14c7a887436b1d9db|https://github.com/apache/geode/commit/2554f42b925f2b9b8ca7eee14c7a887436b1d9db]. > See his notes in `geode-native` PR # 947 > ([https://github.com/apache/geode-native/pull/947]) -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10144) Regression in geode-native test CqPlusAuthInitializeTest.reAuthenticateWithDurable
[ https://issues.apache.org/jira/browse/GEODE-10144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-10144: -- Component/s: native client > Regression in geode-native test > CqPlusAuthInitializeTest.reAuthenticateWithDurable > -- > > Key: GEODE-10144 > URL: https://issues.apache.org/jira/browse/GEODE-10144 > Project: Geode > Issue Type: Bug > Components: client/server, native client >Affects Versions: 1.15.0 >Reporter: Blake Bender >Assignee: Blake Bender >Priority: Major > Labels: NativeClient > Fix For: 1.15.0 > > > This test is failing across the board in the `geode-native` PR pipeline. > Main develop pipeline is green only because nothing can get through the PR > pipeline to clear checkin gates. We have green CI runs with 1.15. build 918, > then it started failing when we picked up build 924. > > [~moleske] tracked this back to this commit: > [https://github.com/apache/geode/commit/2554f42b925f2b9b8ca7eee14c7a887436b1d9db|https://github.com/apache/geode/commit/2554f42b925f2b9b8ca7eee14c7a887436b1d9db]. > See his notes in `geode-native` PR # 947 > ([https://github.com/apache/geode-native/pull/947]) -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10144) Regression in geode-native test CqPlusAuthInitializeTest.reAuthenticateWithDurable
[ https://issues.apache.org/jira/browse/GEODE-10144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17525824#comment-17525824 ] Anthony Baker commented on GEODE-10144: --- I think the action here is to 1) update the SecurityManager implementation in the test to consistently evaluate tokens (ie never authorize an expired token) 2) Remove CQ/RI since this is not supported for reauthentication + old protocol versions > Regression in geode-native test > CqPlusAuthInitializeTest.reAuthenticateWithDurable > -- > > Key: GEODE-10144 > URL: https://issues.apache.org/jira/browse/GEODE-10144 > Project: Geode > Issue Type: Bug > Components: client/server, native client >Affects Versions: 1.15.0 >Reporter: Blake Bender >Assignee: Blake Bender >Priority: Major > Labels: NativeClient > Fix For: 1.15.0 > > > This test is failing across the board in the `geode-native` PR pipeline. > Main develop pipeline is green only because nothing can get through the PR > pipeline to clear checkin gates. We have green CI runs with 1.15. build 918, > then it started failing when we picked up build 924. > > [~moleske] tracked this back to this commit: > [https://github.com/apache/geode/commit/2554f42b925f2b9b8ca7eee14c7a887436b1d9db|https://github.com/apache/geode/commit/2554f42b925f2b9b8ca7eee14c7a887436b1d9db]. > See his notes in `geode-native` PR # 947 > ([https://github.com/apache/geode-native/pull/947]) -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-9889) LettucePubSubIntegrationTest > subscribePsubscribeSameClient FAILED
[
https://issues.apache.org/jira/browse/GEODE-9889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nabarun Nag updated GEODE-9889:
---
Affects Version/s: 1.15.0
> LettucePubSubIntegrationTest > subscribePsubscribeSameClient FAILED
> ---
>
> Key: GEODE-9889
> URL: https://issues.apache.org/jira/browse/GEODE-9889
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.14.0, 1.15.0
>Reporter: Ray Ingles
>Assignee: Jens Deppe
>Priority: Major
> Labels: redis-triage
>
> Seen in a CI build:
>
> {{> Task :geode-apis-compatible-with-redis:integrationTest}}
> {{org.apache.geode.redis.internal.executor.pubsub.LettucePubSubIntegrationTest
> > subscribePsubscribeSameClient FAILED}}
> {{org.junit.ComparisonFailure: expected:<[2]L> but was:<[0]L>}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-9889) LettucePubSubIntegrationTest > subscribePsubscribeSameClient FAILED
[
https://issues.apache.org/jira/browse/GEODE-9889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17525848#comment-17525848
]
Geode Integration commented on GEODE-9889:
--
Seen on support/1.14 in [integration-test-openjdk8
#52|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-14-main/jobs/integration-test-openjdk8/builds/52]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-support-1-14-main/1.14.5-build.0955/test-results/integrationTest/1650531090/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-14-main/1.14.5-build.0955/test-artifacts/1650531090/integrationtestfiles-openjdk8-1.14.5-build.0955.tgz].
> LettucePubSubIntegrationTest > subscribePsubscribeSameClient FAILED
> ---
>
> Key: GEODE-9889
> URL: https://issues.apache.org/jira/browse/GEODE-9889
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.14.0
>Reporter: Ray Ingles
>Assignee: Jens Deppe
>Priority: Major
> Labels: redis-triage
>
> Seen in a CI build:
>
> {{> Task :geode-apis-compatible-with-redis:integrationTest}}
> {{org.apache.geode.redis.internal.executor.pubsub.LettucePubSubIntegrationTest
> > subscribePsubscribeSameClient FAILED}}
> {{org.junit.ComparisonFailure: expected:<[2]L> but was:<[0]L>}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-9889) LettucePubSubIntegrationTest > subscribePsubscribeSameClient FAILED
[
https://issues.apache.org/jira/browse/GEODE-9889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nabarun Nag updated GEODE-9889:
---
Affects Version/s: (was: 1.15.0)
> LettucePubSubIntegrationTest > subscribePsubscribeSameClient FAILED
> ---
>
> Key: GEODE-9889
> URL: https://issues.apache.org/jira/browse/GEODE-9889
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.14.0
>Reporter: Ray Ingles
>Assignee: Jens Deppe
>Priority: Major
> Labels: redis-triage
>
> Seen in a CI build:
>
> {{> Task :geode-apis-compatible-with-redis:integrationTest}}
> {{org.apache.geode.redis.internal.executor.pubsub.LettucePubSubIntegrationTest
> > subscribePsubscribeSameClient FAILED}}
> {{org.junit.ComparisonFailure: expected:<[2]L> but was:<[0]L>}}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-6183) CI Failure: LocatorLauncherRemoteFileIntegrationTest.startDeletesStaleControlFiles failed with ConditionTimeoutException
[ https://issues.apache.org/jira/browse/GEODE-6183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17525851#comment-17525851 ] Geode Integration commented on GEODE-6183: -- Seen on support/1.14 in [windows-core-integration-test-openjdk11 #48|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-14-main/jobs/windows-core-integration-test-openjdk11/builds/48] ... see [test results|http://files.apachegeode-ci.info/builds/apache-support-1-14-main/1.14.5-build.0955/test-results/integrationTest/1650545243/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-14-main/1.14.5-build.0955/test-artifacts/1650545243/windows-coreintegrationtestfiles-openjdk11-1.14.5-build.0955.tgz]. > CI Failure: > LocatorLauncherRemoteFileIntegrationTest.startDeletesStaleControlFiles failed > with ConditionTimeoutException > > > Key: GEODE-6183 > URL: https://issues.apache.org/jira/browse/GEODE-6183 > Project: Geode > Issue Type: Bug > Components: build >Affects Versions: 1.14.0, 1.15.0 >Reporter: Eric Shu >Assignee: Kirk Lund >Priority: Major > Time Spent: 5h 50m > Remaining Estimate: 0h > > Test failed in > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/IntegrationTestOpenJDK8/builds/223 > org.apache.geode.distributed.LocatorLauncherRemoteFileIntegrationTest > > startDeletesStaleControlFiles FAILED > org.awaitility.core.ConditionTimeoutException: Assertion condition > defined as a lambda expression in > org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase that > uses org.apache.geode.distributed.LocatorLauncher expected:<[online]> but > was:<[not responding]> within 300 seconds. > Caused by: > org.junit.ComparisonFailure: expected:<[online]> but was:<[not > responding]> -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-9880) Cluster with multiple locators in an environment with no host name resolution, leads to null pointer exception
[
https://issues.apache.org/jira/browse/GEODE-9880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-9880:
---
Labels: blocks-1.12.10 blocks-1.15.0 membership (was: blocks-1.12.10
blocks-1.15.0 membership pull-request-available)
> Cluster with multiple locators in an environment with no host name
> resolution, leads to null pointer exception
> --
>
> Key: GEODE-9880
> URL: https://issues.apache.org/jira/browse/GEODE-9880
> Project: Geode
> Issue Type: Bug
> Components: locator, membership
>Affects Versions: 1.12.5
>Reporter: Tigran Ghahramanyan
>Assignee: Patrick Johnsn
>Priority: Major
> Labels: blocks-1.12.10, blocks-1.15.0, membership
>
> In our use case we have two locators that are initially configured with IP
> addresses, but _AutoConnectionSourceImpl.UpdateLocatorList()_ flow keeps on
> adding their corresponding host names to the locators list, while these host
> names are not resolvable.
> Later in {_}AutoConnectionSourceImpl.queryLocators(){_}, whenever a client
> tries to use such non resolvable host name to connect to a locator it tries
> to establish a connection to {_}socketaddr=0.0.0.0{_}, as written in
> {_}SocketCreator.connect(){_}. Which seems strange.
> Then, if there is no locator running on the same host, the next locator in
> the list is contacted, until reaching a locator contact configured with IP
> address - which succeeds eventually.
> But, when there happens to be a locator listening on the same host, then we
> have a null pointer exception in the second line below, because _inetadd=null_
> _socket.connect(sockaddr, Math.max(timeout, 0)); // sockaddr=0.0.0.0,
> connects to a locator listening on the same host_
> _configureClientSSLSocket(socket, inetadd.getHostName(), timeout); // inetadd
> = null_
>
> As a result, the cluster comes to a failed state, unable to recover.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-9880) Cluster with multiple locators in an environment with no host name resolution, leads to null pointer exception
[
https://issues.apache.org/jira/browse/GEODE-9880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17525866#comment-17525866
]
Donal Evans commented on GEODE-9880:
@ginga Following discussion with team members, the questions above were
answered as follows:
Unconditional construction of an SNIHostName is a topic that needs further
discussion, and if deemed to be something we want to avoid, a new ticket will
be created.
Name resolution is required for a valid configuration. In order to support the
use case described here, where clients are not able to resolve hostnames into
IP addresses or vice versa, a significant amount of additional testing would be
required, and would potentially need a lot of code changes. This is not
something we intend to support.
As such, it's recommended that this ticket be closed as "workaround" or "will
not fix" and the "blocks-1.15.0" label be removed.
> Cluster with multiple locators in an environment with no host name
> resolution, leads to null pointer exception
> --
>
> Key: GEODE-9880
> URL: https://issues.apache.org/jira/browse/GEODE-9880
> Project: Geode
> Issue Type: Bug
> Components: locator, membership
>Affects Versions: 1.12.5
>Reporter: Tigran Ghahramanyan
>Assignee: Patrick Johnsn
>Priority: Major
> Labels: blocks-1.12.10, blocks-1.15.0, membership
>
> In our use case we have two locators that are initially configured with IP
> addresses, but _AutoConnectionSourceImpl.UpdateLocatorList()_ flow keeps on
> adding their corresponding host names to the locators list, while these host
> names are not resolvable.
> Later in {_}AutoConnectionSourceImpl.queryLocators(){_}, whenever a client
> tries to use such non resolvable host name to connect to a locator it tries
> to establish a connection to {_}socketaddr=0.0.0.0{_}, as written in
> {_}SocketCreator.connect(){_}. Which seems strange.
> Then, if there is no locator running on the same host, the next locator in
> the list is contacted, until reaching a locator contact configured with IP
> address - which succeeds eventually.
> But, when there happens to be a locator listening on the same host, then we
> have a null pointer exception in the second line below, because _inetadd=null_
> _socket.connect(sockaddr, Math.max(timeout, 0)); // sockaddr=0.0.0.0,
> connects to a locator listening on the same host_
> _configureClientSSLSocket(socket, inetadd.getHostName(), timeout); // inetadd
> = null_
>
> As a result, the cluster comes to a failed state, unable to recover.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (GEODE-9880) Cluster with multiple locators in an environment with no host name resolution, leads to null pointer exception
[
https://issues.apache.org/jira/browse/GEODE-9880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17525866#comment-17525866
]
Donal Evans edited comment on GEODE-9880 at 4/21/22 5:18 PM:
-
[~agingade] Following discussion with team members, the questions above were
answered as follows:
Unconditional construction of an SNIHostName is a topic that needs further
discussion, and if deemed to be something we want to avoid, a new ticket will
be created.
Name resolution is required for a valid configuration. In order to support the
use case described here, where clients are not able to resolve hostnames into
IP addresses or vice versa, a significant amount of additional testing would be
required, and would potentially need a lot of code changes. This is not
something we intend to support.
As such, it's recommended that this ticket be closed as "workaround" or "will
not fix" and the "blocks-1.15.0" label be removed.
was (Author: donalevans):
@ginga Following discussion with team members, the questions above were
answered as follows:
Unconditional construction of an SNIHostName is a topic that needs further
discussion, and if deemed to be something we want to avoid, a new ticket will
be created.
Name resolution is required for a valid configuration. In order to support the
use case described here, where clients are not able to resolve hostnames into
IP addresses or vice versa, a significant amount of additional testing would be
required, and would potentially need a lot of code changes. This is not
something we intend to support.
As such, it's recommended that this ticket be closed as "workaround" or "will
not fix" and the "blocks-1.15.0" label be removed.
> Cluster with multiple locators in an environment with no host name
> resolution, leads to null pointer exception
> --
>
> Key: GEODE-9880
> URL: https://issues.apache.org/jira/browse/GEODE-9880
> Project: Geode
> Issue Type: Bug
> Components: locator, membership
>Affects Versions: 1.12.5
>Reporter: Tigran Ghahramanyan
>Assignee: Patrick Johnsn
>Priority: Major
> Labels: blocks-1.12.10, blocks-1.15.0, membership
>
> In our use case we have two locators that are initially configured with IP
> addresses, but _AutoConnectionSourceImpl.UpdateLocatorList()_ flow keeps on
> adding their corresponding host names to the locators list, while these host
> names are not resolvable.
> Later in {_}AutoConnectionSourceImpl.queryLocators(){_}, whenever a client
> tries to use such non resolvable host name to connect to a locator it tries
> to establish a connection to {_}socketaddr=0.0.0.0{_}, as written in
> {_}SocketCreator.connect(){_}. Which seems strange.
> Then, if there is no locator running on the same host, the next locator in
> the list is contacted, until reaching a locator contact configured with IP
> address - which succeeds eventually.
> But, when there happens to be a locator listening on the same host, then we
> have a null pointer exception in the second line below, because _inetadd=null_
> _socket.connect(sockaddr, Math.max(timeout, 0)); // sockaddr=0.0.0.0,
> connects to a locator listening on the same host_
> _configureClientSSLSocket(socket, inetadd.getHostName(), timeout); // inetadd
> = null_
>
> As a result, the cluster comes to a failed state, unable to recover.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-9880) Cluster with multiple locators in an environment with no host name resolution, leads to null pointer exception
[
https://issues.apache.org/jira/browse/GEODE-9880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Johnsn updated GEODE-9880:
--
Labels: blocks-1.12.10 membership (was: blocks-1.12.10 blocks-1.15.0
membership)
> Cluster with multiple locators in an environment with no host name
> resolution, leads to null pointer exception
> --
>
> Key: GEODE-9880
> URL: https://issues.apache.org/jira/browse/GEODE-9880
> Project: Geode
> Issue Type: Bug
> Components: locator, membership
>Affects Versions: 1.12.5
>Reporter: Tigran Ghahramanyan
>Assignee: Patrick Johnsn
>Priority: Major
> Labels: blocks-1.12.10, membership
>
> In our use case we have two locators that are initially configured with IP
> addresses, but _AutoConnectionSourceImpl.UpdateLocatorList()_ flow keeps on
> adding their corresponding host names to the locators list, while these host
> names are not resolvable.
> Later in {_}AutoConnectionSourceImpl.queryLocators(){_}, whenever a client
> tries to use such non resolvable host name to connect to a locator it tries
> to establish a connection to {_}socketaddr=0.0.0.0{_}, as written in
> {_}SocketCreator.connect(){_}. Which seems strange.
> Then, if there is no locator running on the same host, the next locator in
> the list is contacted, until reaching a locator contact configured with IP
> address - which succeeds eventually.
> But, when there happens to be a locator listening on the same host, then we
> have a null pointer exception in the second line below, because _inetadd=null_
> _socket.connect(sockaddr, Math.max(timeout, 0)); // sockaddr=0.0.0.0,
> connects to a locator listening on the same host_
> _configureClientSSLSocket(socket, inetadd.getHostName(), timeout); // inetadd
> = null_
>
> As a result, the cluster comes to a failed state, unable to recover.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (GEODE-9880) Cluster with multiple locators in an environment with no host name resolution, leads to null pointer exception
[
https://issues.apache.org/jira/browse/GEODE-9880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Johnsn resolved GEODE-9880.
---
Resolution: Workaround
The issue only exists when running in an environment without the ability to do
DNS lookups from the client which, according to Charlie, is something we
shouldn't support.
> Cluster with multiple locators in an environment with no host name
> resolution, leads to null pointer exception
> --
>
> Key: GEODE-9880
> URL: https://issues.apache.org/jira/browse/GEODE-9880
> Project: Geode
> Issue Type: Bug
> Components: locator, membership
>Affects Versions: 1.12.5
>Reporter: Tigran Ghahramanyan
>Assignee: Patrick Johnsn
>Priority: Major
> Labels: blocks-1.12.10, membership
>
> In our use case we have two locators that are initially configured with IP
> addresses, but _AutoConnectionSourceImpl.UpdateLocatorList()_ flow keeps on
> adding their corresponding host names to the locators list, while these host
> names are not resolvable.
> Later in {_}AutoConnectionSourceImpl.queryLocators(){_}, whenever a client
> tries to use such non resolvable host name to connect to a locator it tries
> to establish a connection to {_}socketaddr=0.0.0.0{_}, as written in
> {_}SocketCreator.connect(){_}. Which seems strange.
> Then, if there is no locator running on the same host, the next locator in
> the list is contacted, until reaching a locator contact configured with IP
> address - which succeeds eventually.
> But, when there happens to be a locator listening on the same host, then we
> have a null pointer exception in the second line below, because _inetadd=null_
> _socket.connect(sockaddr, Math.max(timeout, 0)); // sockaddr=0.0.0.0,
> connects to a locator listening on the same host_
> _configureClientSSLSocket(socket, inetadd.getHostName(), timeout); // inetadd
> = null_
>
> As a result, the cluster comes to a failed state, unable to recover.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (GEODE-10209) [CI Failure] : bind exception in InternalCacheForClientAccessDistributedTest
[
https://issues.apache.org/jira/browse/GEODE-10209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery reassigned GEODE-10209:
--
Assignee: Kirk Lund
> [CI Failure] : bind exception in InternalCacheForClientAccessDistributedTest
>
>
> Key: GEODE-10209
> URL: https://issues.apache.org/jira/browse/GEODE-10209
> Project: Geode
> Issue Type: Bug
> Components: ci
>Affects Versions: 1.15.0
>Reporter: Nabarun Nag
>Assignee: Kirk Lund
>Priority: Major
>
> This test class needs to be refactored to use AvailablePortHelper
> {code:java}
> InternalCacheForClientAccessDistributedTest > serverUsesFilteredCache FAILED
> org.gradle.internal.exceptions.DefaultMultiCauseException: Multiple
> Failures (2 failures)
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.InternalCacheForClientAccessDistributedTest$$Lambda$402/0x000100357c40.run
> in VM 0 running on Host
> heavy-lifter-48c728b8-c947-5573-8aaa-909b857e1986.c.apachegeode-ci.internal
> with 4 VMs
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.InternalCacheForClientAccessDistributedTest$$Lambda$404/0x000100354840.run
> in VM 1 running on Host
> heavy-lifter-48c728b8-c947-5573-8aaa-909b857e1986.c.apachegeode-ci.internal
> with 4 VMs
> at
> org.junit.vintage.engine.execution.TestRun.getStoredResultOrSuccessful(TestRun.java:196)
> at
> org.junit.vintage.engine.execution.RunListenerAdapter.fireExecutionFinished(RunListenerAdapter.java:226)
> at
> org.junit.vintage.engine.execution.RunListenerAdapter.testFinished(RunListenerAdapter.java:192)
> at
> org.junit.vintage.engine.execution.RunListenerAdapter.testFinished(RunListenerAdapter.java:79)
> at
> org.junit.runner.notification.SynchronizedRunListener.testFinished(SynchronizedRunListener.java:87)
> at
> org.junit.runner.notification.RunNotifier$9.notifyListener(RunNotifier.java:225)
> at
> org.junit.runner.notification.RunNotifier$SafeNotifier.run(RunNotifier.java:72)
> at
> org.junit.runner.notification.RunNotifier.fireTestFinished(RunNotifier.java:222)
> at
> org.junit.internal.runners.model.EachTestNotifier.fireTestFinished(EachTestNotifier.java:38)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:372)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42)
> at
> org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
> at
> org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:54)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.withInterceptedStreams(EngineExecutionOrchestrator.java:67)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:52)
> at
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:96)
> at
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:75)
> at
> org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.processAllTestClasses(JUnitPlatformTestClassProcessor.java:99)
> at
> org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.access$000(JUnitPlatformTestClassProcessor.java:79)
> at
> org.gradle.api.inter
[jira] [Commented] (GEODE-10243) Old clients with durable queues should fail early if AuthenticationExpiredException is thrown
[
https://issues.apache.org/jira/browse/GEODE-10243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17526012#comment-17526012
]
ASF subversion and git services commented on GEODE-10243:
-
Commit 740d5e56758566146a1034f885197b742832c436 in geode's branch
refs/heads/develop from Jinmei Liao
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=740d5e5675 ]
GEODE-10243: Fail early if old client auth expires (#7603)
* change the default "waitForReAuth" time to 60 seconds
> Old clients with durable queues should fail early if
> AuthenticationExpiredException is thrown
> -
>
> Key: GEODE-10243
> URL: https://issues.apache.org/jira/browse/GEODE-10243
> Project: Geode
> Issue Type: Improvement
> Components: client queues
>Reporter: Dan Smith
>Assignee: Dan Smith
>Priority: Major
> Labels: pull-request-available
>
> As part of the changes for GEODE-9457, when an AuthenticationExpiredException
> is thrown from the SecurityManager during message dispatching, we send a
> message to 1.15 and newer clients asking them to re-authenticate.
> For 1.14 and older clients, we do not send a message. Instead, we just wait
> for the {color:#00875a}reauthenticate.wait.time{color} to elapse and then
> close the connection.
> The net effect of this is that if users are doing cache operations from 1.14
> and older clients, and their SecurityManager expires the credentials of the
> old clients, they will sometimes see their clients re-authenticate themselves
> in that time window. This will mislead users into thinking that
> re-authentication works with old clients and client queues, even though we
> [have documented that we don't support
> it|https://github.com/apache/geode/blob/09b8b46ef2fa1d463be885c6fa39dbfe1f0e3e83/geode-docs/managing/security/implementing_authentication_expiry.html.md.erb#L35].
> Instead of allowing re-authentication to sometimes work in this unsupported
> use case, we should always fail so that is clear to users that this use case
> is not supported.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (GEODE-10243) Old clients with durable queues should fail early if AuthenticationExpiredException is thrown
[
https://issues.apache.org/jira/browse/GEODE-10243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao resolved GEODE-10243.
-
Fix Version/s: 1.15.0
Assignee: Jinmei Liao (was: Dan Smith)
Resolution: Fixed
> Old clients with durable queues should fail early if
> AuthenticationExpiredException is thrown
> -
>
> Key: GEODE-10243
> URL: https://issues.apache.org/jira/browse/GEODE-10243
> Project: Geode
> Issue Type: Improvement
> Components: client queues
>Reporter: Dan Smith
>Assignee: Jinmei Liao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> As part of the changes for GEODE-9457, when an AuthenticationExpiredException
> is thrown from the SecurityManager during message dispatching, we send a
> message to 1.15 and newer clients asking them to re-authenticate.
> For 1.14 and older clients, we do not send a message. Instead, we just wait
> for the {color:#00875a}reauthenticate.wait.time{color} to elapse and then
> close the connection.
> The net effect of this is that if users are doing cache operations from 1.14
> and older clients, and their SecurityManager expires the credentials of the
> old clients, they will sometimes see their clients re-authenticate themselves
> in that time window. This will mislead users into thinking that
> re-authentication works with old clients and client queues, even though we
> [have documented that we don't support
> it|https://github.com/apache/geode/blob/09b8b46ef2fa1d463be885c6fa39dbfe1f0e3e83/geode-docs/managing/security/implementing_authentication_expiry.html.md.erb#L35].
> Instead of allowing re-authentication to sometimes work in this unsupported
> use case, we should always fail so that is clear to users that this use case
> is not supported.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (GEODE-10253) remove prepareForSample from StatisticsImpl
Darrel Schneider created GEODE-10253: Summary: remove prepareForSample from StatisticsImpl Key: GEODE-10253 URL: https://issues.apache.org/jira/browse/GEODE-10253 Project: Geode Issue Type: Improvement Components: statistics Reporter: Darrel Schneider The internal implementation of stats in geode has a prepareForSample method on StatisticsImpl. It used to do something in a subclass but is now always a noop. So it should be removed and the callers of it (in HostStatSampler) can be simplified. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-10161) Clean up synchronization in RedisList
[
https://issues.apache.org/jira/browse/GEODE-10161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe resolved GEODE-10161.
Fix Version/s: 1.15.0
Resolution: Fixed
> Clean up synchronization in RedisList
> -
>
> Key: GEODE-10161
> URL: https://issues.apache.org/jira/browse/GEODE-10161
> Project: Geode
> Issue Type: Improvement
> Components: redis
>Reporter: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> Prior to adding versioning, we needed {{synchronized}} on various helper
> methods that modified the internal list data structure. This was in order to
> ensure exclusive access in the event of a {{toData()}} call (during
> GII/bucket movement). {{toData()}} is also synchronized. However, now that
> we're synchronizing within more of the 'top-level' methods in RedisList,
> (because we're also changing the {{version}} value), I think that we should
> be able to remove all of the {{synchronized}} modifiers on the smaller helper
> methods.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10209) [CI Failure] : bind exception in InternalCacheForClientAccessDistributedTest
[
https://issues.apache.org/jira/browse/GEODE-10209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-10209:
---
Labels: pull-request-available (was: )
> [CI Failure] : bind exception in InternalCacheForClientAccessDistributedTest
>
>
> Key: GEODE-10209
> URL: https://issues.apache.org/jira/browse/GEODE-10209
> Project: Geode
> Issue Type: Bug
> Components: ci
>Affects Versions: 1.15.0
>Reporter: Nabarun Nag
>Assignee: Kirk Lund
>Priority: Major
> Labels: pull-request-available
>
> This test class needs to be refactored to use AvailablePortHelper
> {code:java}
> InternalCacheForClientAccessDistributedTest > serverUsesFilteredCache FAILED
> org.gradle.internal.exceptions.DefaultMultiCauseException: Multiple
> Failures (2 failures)
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.InternalCacheForClientAccessDistributedTest$$Lambda$402/0x000100357c40.run
> in VM 0 running on Host
> heavy-lifter-48c728b8-c947-5573-8aaa-909b857e1986.c.apachegeode-ci.internal
> with 4 VMs
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.InternalCacheForClientAccessDistributedTest$$Lambda$404/0x000100354840.run
> in VM 1 running on Host
> heavy-lifter-48c728b8-c947-5573-8aaa-909b857e1986.c.apachegeode-ci.internal
> with 4 VMs
> at
> org.junit.vintage.engine.execution.TestRun.getStoredResultOrSuccessful(TestRun.java:196)
> at
> org.junit.vintage.engine.execution.RunListenerAdapter.fireExecutionFinished(RunListenerAdapter.java:226)
> at
> org.junit.vintage.engine.execution.RunListenerAdapter.testFinished(RunListenerAdapter.java:192)
> at
> org.junit.vintage.engine.execution.RunListenerAdapter.testFinished(RunListenerAdapter.java:79)
> at
> org.junit.runner.notification.SynchronizedRunListener.testFinished(SynchronizedRunListener.java:87)
> at
> org.junit.runner.notification.RunNotifier$9.notifyListener(RunNotifier.java:225)
> at
> org.junit.runner.notification.RunNotifier$SafeNotifier.run(RunNotifier.java:72)
> at
> org.junit.runner.notification.RunNotifier.fireTestFinished(RunNotifier.java:222)
> at
> org.junit.internal.runners.model.EachTestNotifier.fireTestFinished(EachTestNotifier.java:38)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:372)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42)
> at
> org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
> at
> org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:54)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.withInterceptedStreams(EngineExecutionOrchestrator.java:67)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:52)
> at
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:96)
> at
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:75)
> at
> org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.processAllTestClasses(JUnitPlatformTestClassProcessor.java:99)
> at
> org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.access$000(JUnitPlatf
[jira] [Commented] (GEODE-9466) ByteBufferInputStream.OffHeapByteSource fails on Java 16 and later
[
https://issues.apache.org/jira/browse/GEODE-9466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17526103#comment-17526103
]
ASF subversion and git services commented on GEODE-9466:
Commit ad615d16ccc071354521a8c921fa23ccdb5dda14 in geode's branch
refs/heads/develop from Darrel Schneider
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=ad615d16cc ]
GEODE-9466: change offheap to not use Bits.unaligned (#7611)
offheap no longer depends on java.nio.Bits.unaligned
> ByteBufferInputStream.OffHeapByteSource fails on Java 16 and later
> --
>
> Key: GEODE-9466
> URL: https://issues.apache.org/jira/browse/GEODE-9466
> Project: Geode
> Issue Type: Bug
> Components: offheap
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>Priority: Major
> Labels: Java16, Java17, pull-request-available
>
> ByteBufferInputStream.OffHeapByteSource has a method determineUnaligned that
> will always fail on java 16 and later. This is because it calls
> Method.setAccessible which is not allowed under normal conditions starting
> with java 16 (see:
> [https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16]).
> The method is called when the class is loaded so it will cause the class load
> to fail. It tries to handle exceptions on return false but the exception java
> 16 throws is a RuntimeException and that is not caught. The exception it will
> fail with is java.lang.reflect.InaccessibleObjectException.
> A workaround for this bug is to start the jvm with --illegal-access=permit
> This causes ByteBufferInputStream to do a bunch of its work a byte at a time
> instead of using the optimal multi-byte methods like readShort, readInt, and
> readLong.
> It would be simple to change determineUnaligned to catch RuntimeException
> from setAccessible and then to read the "os.arch" system property and if it
> is any of the following to return true:
> {code:java}
> arch.equals("i386") || arch.equals("x86")
> || arch.equals("amd64") || arch.equals("x86_64")
> || arch.equals("ppc64") || arch.equals("ppc64le")
> {code}
> This is what the Bits class does in jdk 8. In jdk 16 this logic has moved to
> UnsafeConstants and its value is injected by the JVM so it is unclear if the
> list has grown.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (GEODE-9466) ByteBufferInputStream.OffHeapByteSource fails on Java 16 and later
[
https://issues.apache.org/jira/browse/GEODE-9466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider resolved GEODE-9466.
-
Fix Version/s: 1.15.0
Resolution: Fixed
> ByteBufferInputStream.OffHeapByteSource fails on Java 16 and later
> --
>
> Key: GEODE-9466
> URL: https://issues.apache.org/jira/browse/GEODE-9466
> Project: Geode
> Issue Type: Bug
> Components: offheap
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>Priority: Major
> Labels: Java16, Java17, pull-request-available
> Fix For: 1.15.0
>
>
> ByteBufferInputStream.OffHeapByteSource has a method determineUnaligned that
> will always fail on java 16 and later. This is because it calls
> Method.setAccessible which is not allowed under normal conditions starting
> with java 16 (see:
> [https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16]).
> The method is called when the class is loaded so it will cause the class load
> to fail. It tries to handle exceptions on return false but the exception java
> 16 throws is a RuntimeException and that is not caught. The exception it will
> fail with is java.lang.reflect.InaccessibleObjectException.
> A workaround for this bug is to start the jvm with --illegal-access=permit
> This causes ByteBufferInputStream to do a bunch of its work a byte at a time
> instead of using the optimal multi-byte methods like readShort, readInt, and
> readLong.
> It would be simple to change determineUnaligned to catch RuntimeException
> from setAccessible and then to read the "os.arch" system property and if it
> is any of the following to return true:
> {code:java}
> arch.equals("i386") || arch.equals("x86")
> || arch.equals("amd64") || arch.equals("x86_64")
> || arch.equals("ppc64") || arch.equals("ppc64le")
> {code}
> This is what the Bits class does in jdk 8. In jdk 16 this logic has moved to
> UnsafeConstants and its value is injected by the JVM so it is unclear if the
> list has grown.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (GEODE-10036) Joining Locators in a cluster is not possible on Java 17
[
https://issues.apache.org/jira/browse/GEODE-10036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider reassigned GEODE-10036:
Assignee: Darrel Schneider
> Joining Locators in a cluster is not possible on Java 17
>
>
> Key: GEODE-10036
> URL: https://issues.apache.org/jira/browse/GEODE-10036
> Project: Geode
> Issue Type: Sub-task
>Affects Versions: 1.14.3
>Reporter: John Blum
>Assignee: Darrel Schneider
>Priority: Critical
> Labels: Java17, jdk17
>
> When trying to add multiple _Locators_ to the same cluster, particularly when
> "_direct_" {{ByteBuffers}} are used, the following Exception is thrown:
> {code:java}
> Caused by: org.apache.geode.SystemConnectException: One or more peers
> generated exceptions during connection attempt
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1634)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:361)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:756)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:132)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3011)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:282)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:746)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:392)
> at
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:716)
> at
> org.springframework.data.gemfire.LocatorFactoryBean.init(LocatorFactoryBean.java:120)
> ... 44 more
> Caused by: org.apache.geode.InternalGemFireException: unable to retrieve
> underlying byte buffer
> at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:346)
> at
> org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:310)
> at
> org.apache.geode.internal.net.BufferPool.releaseSenderBuffer(BufferPool.java:213)
> at
> org.apache.geode.internal.tcp.MsgStreamer.release(MsgStreamer.java:101)
> at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:258)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:318)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:187)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:525)
> at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:348)
> at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:293)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2064)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1991)
> at
> org.apache.geode.distributed.internal.StartupOperation.sendStartupMessage(StartupOperation.java:75)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1631)
> ... 56 more
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> public java.lang.Object java.nio.DirectByteBuffer.attachment() accessible:
> module java.base does not "opens java.nio" to unnamed module @2e0fa5d3
> at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
> at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
> at
> java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:199)
> at java.base/java.lang.reflect.Method.setAccessible(Method.java:193)
> at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:343)
> ... 69 more
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-9402) Automatic Reconnect Failure: Address already in use
[
https://issues.apache.org/jira/browse/GEODE-9402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17526130#comment-17526130
]
Bill Burcham commented on GEODE-9402:
-
Here’s a draft PR with my experiments:
[https://github.com/apache/geode/pull/7614]
(In my testing I enabled TLS for all components. I don’t think it matters for
this ticket but it’s become a habit.)
I wrote a test that starts a three-member cluster and then binds a server
socket to port X and then calls geode.cache.Cache.addCacheServer() to create a
CacheServer and then calls setPort(X) on it and then start(). Here’s the
exception I get:
{{BGB caught: java.net.BindException: Address already in use (Bind failed)
at java.net.PlainSocketImpl.socketBind(Native Method)
at java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387)
at java.net.ServerSocket.bind(ServerSocket.java:390)
at
org.apache.geode.internal.net.SCClusterSocketCreator.createServerSocket(SCClusterSocketCreator.java:79)
at
org.apache.geode.internal.net.SocketCreator.createServerSocket(SocketCreator.java:491)
at
org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.(AcceptorImpl.java:574)
at
org.apache.geode.internal.cache.tier.sockets.AcceptorBuilder.create(AcceptorBuilder.java:291)
at
org.apache.geode.internal.cache.CacheServerImpl.createAcceptor(CacheServerImpl.java:421)
at
org.apache.geode.internal.cache.CacheServerImpl.start(CacheServerImpl.java:378)
at
org.apache.geode.cache30.ReconnectWithTlsAndClientsCacheServerDistributedTest.startClientsCacheServer(ReconnectWithTlsAndClientsCacheServerDistributedTest.java:126)
at
org.apache.geode.cache30.ReconnectWithTlsAndClientsCacheServerDistributedTest.disconnectAndReconnectTest(ReconnectWithTlsAndClientsCacheServerDistributedTest.java:105)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)}}
Part of that stack trace, from the exception to CacheServerImpl.start matches
the stack trace from GEM-3359. The test does not create the cache from cache
XML (e.g. ClusterConfigurationLoader.applyClusterXmlConfiguration()) as
described in the ticket however. *This may be an area we want to explore
further.*
By explicitly causing the bind exception (in my new
preBindToClientsCacheServerPortTest() test) I can see that the AcceptorImpl
constructor is retrying when it encounters the BindException (a
SocketException). It’ll repeatedly try to create the server socket for 120
seconds (CacheServerImpl.getTimeLimitMillis()), sleeping 1 second in between
tries. This is also true of the code path described by the stack trace in the
ticket.
Calling ServerSocket.setReuseAddress(true) when I bind to port X, does not
eliminate the bind exception. From the documentation:
Enabling SO_REUSEADDR prior to binding the socket using bind(SocketAddress)
allows the socket to be bound even though a previous connection is in a timeout
state.
This setting only allows something else to bind to the port when the original
socket is in the timeout state. A socket not in the timeout state, bound to a
port, simply monopolizes that port. The short of it is that
setReuseAddress(true) is helpful for addressing certain race conditions but it
can’t address them all.
I did confirm that Geode does always call setReuseAddress(true) whenever
creating a server socket for a SocketCreator:
non-TLS case:
SocketCreator.createServerSocket()
TLS case:
SCClusterSocketCreator.createServerSocket()
I’ve got a test (disconnectAndReconnectTest()) that enables TLS for all Geode
components (including clients) and creates a three-member cluster. Then it
repeatedly starts a client’s CacheServer (bound to port X), crashes the
distributed system via MembershipManagerHelper.crashDistributedSystem() and
verifies that the disconnected member reconnects. I haven’t been able to
reproduce the problem with this test.
This is not exactly the way the forced-disconnect was generated in GEM-3359. In
that case a network partition caused the forced-disconnection. *This may be an
area we want to explore further.*
Searching for asynchrony that could lead to a race condition I took a look at
GMSMembership.ManagerImpl.forceDisconnect(). When that calls
uncleanShutdownDS() a thread is spawned to do the actual work of shutting down
the distributed system. Inserting at 30 second delay at the start of that
thread’s task (run()) did not reproduce GEM-3359.
The path from uncleanShutdownDS() that actually leads to closing the client’s
CacheServer’s ServerSocket can be seen in this stack trace:
{{BGB in AcceptorImpl.close() closing server socket bound to port: 20009,
java.lang.Throwable
at
org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.close(AcceptorImpl.java:1617)
at
org.apache.geode.internal.cache.CacheServerImpl.stop(CacheServerImpl.java:485)
at
org.apache.geode.internal.cache.GemF
[jira] [Created] (GEODE-10254) NullPointerException in DistributionLocatorID.marshalForClients()
Jacob Barrett created GEODE-10254:
-
Summary: NullPointerException in
DistributionLocatorID.marshalForClients()
Key: GEODE-10254
URL: https://issues.apache.org/jira/browse/GEODE-10254
Project: Geode
Issue Type: Bug
Affects Versions: 1.15.0
Reporter: Jacob Barrett
When constructed via {{unmarshal()}} with an unresolvable hostname subsequent
calls to {{marshalForClients()}} will result in {{NullPointerException}}.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10254) NullPointerException in DistributionLocatorID.marshalForClients()
[
https://issues.apache.org/jira/browse/GEODE-10254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10254:
--
Labels: needsTriage (was: )
> NullPointerException in DistributionLocatorID.marshalForClients()
> -
>
> Key: GEODE-10254
> URL: https://issues.apache.org/jira/browse/GEODE-10254
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Jacob Barrett
>Priority: Major
> Labels: needsTriage
>
> When constructed via {{unmarshal()}} with an unresolvable hostname subsequent
> calls to {{marshalForClients()}} will result in {{NullPointerException}}.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (GEODE-10254) NullPointerException in DistributionLocatorID.marshalForClients()
[
https://issues.apache.org/jira/browse/GEODE-10254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett reassigned GEODE-10254:
-
Assignee: Jacob Barrett
> NullPointerException in DistributionLocatorID.marshalForClients()
> -
>
> Key: GEODE-10254
> URL: https://issues.apache.org/jira/browse/GEODE-10254
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.12.0, 1.13.0, 1.14.0, 1.15.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: needsTriage
>
> When constructed via {{unmarshal()}} with an unresolvable hostname subsequent
> calls to {{marshalForClients()}} will result in {{NullPointerException}}.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10254) NullPointerException in DistributionLocatorID.marshalForClients()
[
https://issues.apache.org/jira/browse/GEODE-10254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-10254:
---
Labels: needsTriage pull-request-available (was: needsTriage)
> NullPointerException in DistributionLocatorID.marshalForClients()
> -
>
> Key: GEODE-10254
> URL: https://issues.apache.org/jira/browse/GEODE-10254
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.12.0, 1.13.0, 1.14.0, 1.15.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> When constructed via {{unmarshal()}} with an unresolvable hostname subsequent
> calls to {{marshalForClients()}} will result in {{NullPointerException}}.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10254) NullPointerException in DistributionLocatorID.marshalForClients()
[
https://issues.apache.org/jira/browse/GEODE-10254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett updated GEODE-10254:
--
Affects Version/s: 1.14.0
1.13.0
1.12.0
> NullPointerException in DistributionLocatorID.marshalForClients()
> -
>
> Key: GEODE-10254
> URL: https://issues.apache.org/jira/browse/GEODE-10254
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.12.0, 1.13.0, 1.14.0, 1.15.0
>Reporter: Jacob Barrett
>Priority: Major
> Labels: needsTriage
>
> When constructed via {{unmarshal()}} with an unresolvable hostname subsequent
> calls to {{marshalForClients()}} will result in {{NullPointerException}}.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
