[jira] [Commented] (GEODE-7309) Upgrade Lucene from 6.6.2 to 8.2.0
[ https://issues.apache.org/jira/browse/GEODE-7309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17237198#comment-17237198 ] ASF GitHub Bot commented on GEODE-7309: --- mkevo commented on pull request #4395: URL: https://github.com/apache/geode/pull/4395#issuecomment-732002899 Hi, If there is no comments until the end of the week, I will go with resolving conflicts and merging this PR. BR, Mario This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Upgrade Lucene from 6.6.2 to 8.2.0 > -- > > Key: GEODE-7309 > URL: https://issues.apache.org/jira/browse/GEODE-7309 > Project: Geode > Issue Type: Sub-task >Reporter: Mario Kevo >Assignee: Mario Kevo >Priority: Major > Labels: pull-request-available > Time Spent: 5.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8442) Exception in server not identified correctly in client
[
https://issues.apache.org/jira/browse/GEODE-8442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17237208#comment-17237208
]
ASF GitHub Bot commented on GEODE-8442:
---
mkevo commented on pull request #693:
URL: https://github.com/apache/geode-native/pull/693#issuecomment-732005727
Just to add that this reproduction steps can lead to the few exceptions,
depends on which state of the transaction it fail(It can be MessageException
for CacheTransactionManager::failover or UnknownException for
TransactionDataNodeHasDepartedException).
Also the help is needed for writing a test as I need to do
containsKeyOnServer and killing server lead in parallel, but don't have an idea
how to do this in tests.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Exception in server not identified correctly in client
> --
>
> Key: GEODE-8442
> URL: https://issues.apache.org/jira/browse/GEODE-8442
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Alberto Bustamante Reyes
>Assignee: Mario Kevo
>Priority: Major
> Labels: pull-request-available
>
> Native client is not identifying correctly an exception returned by the
> server.
> This is a log from an exception properly identified (I have introduced ""
> where I think I have to hide sensitive information):
> {code}
> [error 2020/07/22 09:17:10.831337 UTC ]
> CacheTransactionManager::failover: An exception
> (org.apache.geode.cache.TransactionDataNodeHasDepartedException: Could not
> find transaction host for TXId:
> (default_GeodeDS:1:loner):3:Native_gdbdedfebe1:default_GeodeDS:6022
> at
> org.apache.geode.internal.cache.tier.sockets.command.TXFailoverCommand.cmdExecute(TXFailoverCommand.java:126)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:177)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:848)
> at
> org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:72)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1212)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:676)
> at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
> at java.base/java.lang.Thread.run(Thread.java:834)
> ) happened at remote server.
> data-access: write_element:[TransactionDataNodeHasDepartedException]
> .get()::apache::geode::client::TransactionDataNodeHasDepartedException:org.apache.geode.cache.TransactionDataNodeHasDepartedException:
> Could not find transaction host for TXId:
> (default_GeodeDS:1:loner):3:Native_gdbdedfebe1:default_GeodeDS:6022
> {code}
> But in this case, although the exception received is also a
> TransactionDataNodeHasDepartedException, it is "translated" to an Unknown
> exception:
> {code}
> [error 2020/07/22 09:17:10.979506 UTC ] Region::containsKeyOnServer:: An
> exception (org.apache.geode.cache.TransactionDataNodeHasDepartedException:
> Transaction data node 192.168.240.13(dms-server-1:1):41000 has departed.
> To proceed, rollback this transaction and begin a new one., caused by
> org.apache.geode.internal.cache.ForceReattemptException: PartitionResponse
> got remote CacheClosedException
> at
> org.apache.geode.internal.cache.tx.PartitionedTXRegionStub.containsKey(PartitionedTXRegionStub.java:247)
> at
> org.apache.geode.internal.cache.TXStateStub.containsKey(TXStateStub.java:431)
> at
> org.apache.geode.internal.cache.TXStateProxyImpl.containsKey(TXStateProxyImpl.java:530)
> at
> org.apache.geode.internal.cache.PartitionedRegion.containsKey(PartitionedRegion.java:6402)
> at
> org.apache.geode.internal.cache.tier.sockets.command.ContainsKey66.cmdExecute(ContainsKey66.java:138)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:177)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:848)
> at
> org.apache.geode.internal.cache.tier.soc
[jira] [Commented] (GEODE-8546) Colocated regions missing some buckets after restart
[ https://issues.apache.org/jira/browse/GEODE-8546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17237214#comment-17237214 ] ASF GitHub Bot commented on GEODE-8546: --- mkevo commented on pull request #5590: URL: https://github.com/apache/geode/pull/5590#issuecomment-732007820 I tried to write a test on different ways but without success. If you know someone who possible can help me with this, I will appreciate it. It is also hard to reproduce it manually, so I think that it will be more harder to create test for it. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Colocated regions missing some buckets after restart > > > Key: GEODE-8546 > URL: https://issues.apache.org/jira/browse/GEODE-8546 > Project: Geode > Issue Type: Bug > Components: regions >Affects Versions: 1.11.0, 1.12.0, 1.13.0 >Reporter: Mario Kevo >Assignee: Mario Kevo >Priority: Major > Labels: pull-request-available > > After restart all servers at the same time, some colocation regions missing > some buckets. > This issue exist for a long time and become visible from 1.11.0 by > introducing this changes GEODE-7042 . > How to reproduce the issue: > # Start two locators and two servers > # Create PARTITION_REDUNDANT_PERSISTENT region with redundant-copies=1 > # Create few PARTITION_REDUNDANT regions(I used six regions) colocated with > persistent region and redundant-copies=1 > # Put some entries. > # Restart servers(you can simply run "kill -15 " and then from > two terminals start both of them at the same time) > # It will take a time to get server startup finished and for the latest > region bucketCount will be lower than expected on one member -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8729) LGTM analysis in geode-native failing after Geode 1.13.1 has been released
[ https://issues.apache.org/jira/browse/GEODE-8729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez resolved GEODE-8729. -- Resolution: Fixed Already fixed when the solution for this ticket came. > LGTM analysis in geode-native failing after Geode 1.13.1 has been released > -- > > Key: GEODE-8729 > URL: https://issues.apache.org/jira/browse/GEODE-8729 > Project: Geode > Issue Type: Bug > Components: ci, native client >Affects Versions: 1.13.0 >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > After releasing Apache Geode 1.13.1 the LGTM analysis done on PRs is failing > because version 1.13.0 has been archived and is no longer available on the > mirrors. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8318) Shutdown hang and abort
[ https://issues.apache.org/jira/browse/GEODE-8318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17237357#comment-17237357 ] ASF GitHub Bot commented on GEODE-8318: --- lgtm-com[bot] commented on pull request #695: URL: https://github.com/apache/geode-native/pull/695#issuecomment-732152283 This pull request **fixes 2 alerts** when merging 48ab63ecdf563713e45a6ad33c3bed561436d2f6 into fcf95b32773783e86976e34c0ccfc9987fa63fec - [view on LGTM.com](https://lgtm.com/projects/g/apache/geode-native/rev/pr-7c61ec45de34bc651f8ea1fbbfa9b583c7077bd5) **fixed alerts:** * 2 for Comparison result is always the same This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Shutdown hang and abort > --- > > Key: GEODE-8318 > URL: https://issues.apache.org/jira/browse/GEODE-8318 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Matthew Reddington >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > Switching from Ace to Boost.Asio has revealed threading issues related to > shutdown. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8717) Redis INFO Command should only return specified sections when given parameter
[ https://issues.apache.org/jira/browse/GEODE-8717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17237406#comment-17237406 ] ASF subversion and git services commented on GEODE-8717: Commit c75a9eb6b737361bbc663081083192eebb087390 in geode's branch refs/heads/develop from Ray Ingles [ https://gitbox.apache.org/repos/asf?p=geode.git;h=c75a9eb ] GEODE-8717: INFO command returns specified sections (#5767) > Redis INFO Command should only return specified sections when given parameter > - > > Key: GEODE-8717 > URL: https://issues.apache.org/jira/browse/GEODE-8717 > Project: Geode > Issue Type: Improvement > Components: redis >Affects Versions: 1.14.0 >Reporter: John Hutchison >Assignee: Raymond Ingles >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > https://github.com/apache/geode/pull/5756 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8717) Redis INFO Command should only return specified sections when given parameter
[ https://issues.apache.org/jira/browse/GEODE-8717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17237404#comment-17237404 ] ASF GitHub Bot commented on GEODE-8717: --- jdeppe-pivotal merged pull request #5767: URL: https://github.com/apache/geode/pull/5767 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Redis INFO Command should only return specified sections when given parameter > - > > Key: GEODE-8717 > URL: https://issues.apache.org/jira/browse/GEODE-8717 > Project: Geode > Issue Type: Improvement > Components: redis >Affects Versions: 1.14.0 >Reporter: John Hutchison >Assignee: Raymond Ingles >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > https://github.com/apache/geode/pull/5756 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8717) Redis INFO Command should only return specified sections when given parameter
[ https://issues.apache.org/jira/browse/GEODE-8717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-8717. --- Resolution: Fixed > Redis INFO Command should only return specified sections when given parameter > - > > Key: GEODE-8717 > URL: https://issues.apache.org/jira/browse/GEODE-8717 > Project: Geode > Issue Type: Improvement > Components: redis >Affects Versions: 1.14.0 >Reporter: John Hutchison >Assignee: Raymond Ingles >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > https://github.com/apache/geode/pull/5756 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8573) SerialGatewaySenderOperationsDistributedTest.testRestartSerialGatewaySendersWhilePutting
[
https://issues.apache.org/jira/browse/GEODE-8573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17237505#comment-17237505
]
Alexander Murmann commented on GEODE-8573:
--
[~klund] Do you know which precious commit caused this? I'd love it if we could
go back and maybe discuss fixing it with the original author.
> SerialGatewaySenderOperationsDistributedTest.testRestartSerialGatewaySendersWhilePutting
>
>
> Key: GEODE-8573
> URL: https://issues.apache.org/jira/browse/GEODE-8573
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.14.0
>Reporter: Mark Hanson
>Priority: Major
> Labels: GeodeOperationAPI
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/521]
>
> {noformat}
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest
> > testRestartSerialGatewaySendersWhilePutting[1: numDispatchers=3] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest$$Lambda$356/426344166.run
> in VM 5 running on Host 538fd3213f62 with 8 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:620)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:447)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest.testRestartSerialGatewaySendersWhilePutting(SerialGatewaySenderOperationsDistributedTest.java:407)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest
> that uses org.apache.geode.internal.cache.wan.InternalGatewaySender,
> org.apache.geode.internal.cache.wan.InternalGatewaySenderint [Sender
> statistics unprocessed event map size] expected:<[0]> but was:<[3]> within 5
> minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest.validateSecondaryQueueSizeStat(SerialGatewaySenderOperationsDistributedTest.java:1216)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest.lambda$testRestartSerialGatewaySendersWhilePutting$bb17a952$23(SerialGatewaySenderOperationsDistributedTest.java:407)
> Caused by:
> org.junit.ComparisonFailure: [Sender statistics unprocessed event
> map size] expected:<[0]> but was:<[3]>
> at
> sun.reflect.GeneratedConstructorAccessor81.newInstance(Unknown Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest.lambda$validateSecondaryQueueSizeStat$8(SerialGatewaySenderOperationsDistributedTest.java:1219)
> {noformat}
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0389/test-results/distributedTest/1601774166/]
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0389/test-artifacts/1601774166/distributedtestfiles-OpenJDK8-1.14.0-build.0389.tgz]
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8634) CI failure: AsyncInvocationTimeoutDistributedTest. get_callable_timeout_includesStackTraceAsCause
[
https://issues.apache.org/jira/browse/GEODE-8634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17237547#comment-17237547
]
Geode Integration commented on GEODE-8634:
--
Seen in [DistributedTestOpenJDK8
#644|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/644]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0510/test-results/distributedTest/1606151067/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0510/test-artifacts/1606151067/distributedtestfiles-OpenJDK8-1.14.0-build.0510.tgz].
> CI failure: AsyncInvocationTimeoutDistributedTest.
> get_callable_timeout_includesStackTraceAsCause
> -
>
> Key: GEODE-8634
> URL: https://issues.apache.org/jira/browse/GEODE-8634
> Project: Geode
> Issue Type: Test
> Components: tests
>Affects Versions: 1.13.0, 1.14.0
>Reporter: Jens Deppe
>Priority: Major
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/DistributedTestOpenJDK8/builds/24
> {noformat}
> org.apache.geode.test.dunit.tests.AsyncInvocationTimeoutDistributedTest >
> get_callable_timeout_includesStackTraceAsCause FAILED
> java.lang.AssertionError:
> Expecting message to be:
> <"Stack trace for vm-0 thread-32">
> but was:
> <"Stack trace for vm-0 thread-33">
> Throwable that failed the check:
> org.apache.geode.test.dunit.internal.StackTrace: Stack trace for vm-0
> thread-33
> at sun.misc.Unsafe.park(Native Method)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
> at
> org.apache.geode.test.dunit.tests.AsyncInvocationTimeoutDistributedTest.lambda$get_callable_timeout_includesStackTraceAsCause$c2252e51$1(AsyncInvocationTimeoutDistributedTest.java:109)
> at
> org.apache.geode.test.dunit.tests.AsyncInvocationTimeoutDistributedTest$$Lambda$36/681142003.call(Unknown
> Source)
> at
> org.apache.geode.test.dunit.internal.IdentifiableCallable.call(IdentifiableCallable.java:41)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.geode.test.dunit.internal.MethodInvoker.executeObject(MethodInvoker.java:123)
> at
> org.apache.geode.test.dunit.internal.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:78)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
> at sun.rmi.transport.Transport$1.run(Transport.java:200)
> at sun.rmi.transport.Transport$1.run(Transport.java:197)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> at
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:573)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:834)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:688)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$$Lambda$15/1238667039.run(Unknown
> Source)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:687)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> at
> org.apache.geode.test.dunit.tests.AsyncInvocationTimeoutDistributedTest.get_callable_timeout_includesStackTraceAsCause(AsyncInvocationTimeoutDistributedTest.java:124)
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=
[jira] [Commented] (GEODE-8623) Timing between DNS and Geode startup can result in permanent unknown host exceptions.
[
https://issues.apache.org/jira/browse/GEODE-8623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17237549#comment-17237549
]
ASF GitHub Bot commented on GEODE-8623:
---
Bill commented on a change in pull request #5743:
URL: https://github.com/apache/geode/pull/5743#discussion_r528887872
##
File path: geode-common/src/main/java/org/apache/geode/internal/Retry.java
##
@@ -82,7 +84,9 @@ public void sleep(long sleepTime, TimeUnit sleepTimeUnit)
throws InterruptedExce
if (predicate.test(value)) {
return value;
} else {
-timer.sleep(interval, intervalUnit);
+long sleepTimeInNano =
+Math.min(NANOSECONDS.convert(interval, intervalUnit), until -
timer.nanoTime());
Review comment:
ah yes!
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Timing between DNS and Geode startup can result in permanent unknown host
> exceptions.
> -
>
> Key: GEODE-8623
> URL: https://issues.apache.org/jira/browse/GEODE-8623
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.9.0, 1.9.1, 1.10.0, 1.9.2, 1.11.0, 1.12.0, 1.13.0,
> 1.14.0, 1.13.1
>Reporter: Jacob Barrett
>Priority: Minor
> Labels: pull-request-available
>
> In a managed environment were local host name DNS entries and the startup of
> Geode happen concurrently it is possible for Geode to fail name resolution in
> the local hostname caching. If it fails to resolve the local hostname when
> loading the caching utility class then any service dependent on this name
> will fail without chance for recovery.
> {code}
> [error 2020/09/30 19:50:21.644 UTC tid=0x1] Jmx manager could not be
> started because java.net.UnknownHostException
> org.apache.geode.management.ManagementException: java.net.UnknownHostException
> at
> org.apache.geode.management.internal.ManagementAgent.startAgent(ManagementAgent.java:133)
> at
> org.apache.geode.management.internal.SystemManagementService.startManager(SystemManagementService.java:432)
> at
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheCreation(ManagementAdapter.java:181)
> at
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:127)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2063)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:606)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1239)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:219)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:171)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
> at
> org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52)
> at
> org.apache.geode.distributed.ServerLauncher.createCache(ServerLauncher.java:887)
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:803)
> at
> org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:732)
> at
> org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:251)
> Caused by: java.net.UnknownHostException
> at
> org.apache.geode.internal.net.SocketCreator.getLocalHost(SocketCreator.java:285)
> at
> org.apache.geode.management.internal.ManagementAgent.configureAndStart(ManagementAgent.java:310)
> at
> org.apache.geode.management.internal.ManagementAgent.startAgent(ManagementAgent.java:131)
> ... 14 more
> [error 2020/09/30 19:50:21.724 UTC tid=0x1]
> org.apache.geode.management.ManagementException: java.net.UnknownHostException
> Exception in thread "main" org.apache.geode.management.ManagementException:
> java.net.UnknownHostException
> at
> org.apache.geode.management.internal.ManagementAgent.startAgent(ManagementAgent.java:133)
> at
> org.apache.geode.management.internal.SystemManagementService.startManager(SystemManagementService.java:432)
> at
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheCreation(ManagementAdapter.java:181)
> at
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListen
[jira] [Commented] (GEODE-7860) Indexed query benchmarks fail with EOFException
[
https://issues.apache.org/jira/browse/GEODE-7860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17237556#comment-17237556
]
Geode Integration commented on GEODE-7860:
--
Seen in [Benchmark_base
#480|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/480].
> Indexed query benchmarks fail with EOFException
> ---
>
> Key: GEODE-7860
> URL: https://issues.apache.org/jira/browse/GEODE-7860
> Project: Geode
> Issue Type: Bug
> Components: benchmarks, querying
>Reporter: Donal Evans
>Priority: Major
>
> {noformat}
> org.apache.geode.benchmark.tests.ReplicatedIndexedQueryBenchmark > run()
> FAILED
> java.util.concurrent.CompletionException: java.lang.RuntimeException:
> java.rmi.UnmarshalException: Error unmarshaling return header; nested
> exception is:
> java.io.EOFException
> Caused by:
> java.lang.RuntimeException: java.rmi.UnmarshalException: Error
> unmarshaling return header; nested exception is:
> java.io.EOFException
> Caused by:
> java.rmi.UnmarshalException: Error unmarshaling return header;
> nested exception is:
> java.io.EOFException
> Caused by:
> java.io.EOFException
> 16 tests completed, 1 failed
> org.apache.geode.benchmark.tests.PartitionedIndexedQueryBenchmark > run()
> FAILED
> java.util.concurrent.CompletionException: java.lang.RuntimeException:
> java.rmi.UnmarshalException: Error unmarshaling return header; nested
> exception is:
> java.io.EOFException
> Caused by:
> java.lang.RuntimeException: java.rmi.UnmarshalException: Error
> unmarshaling return header; nested exception is:
> java.io.EOFException
> Caused by:
> java.rmi.UnmarshalException: Error unmarshaling return header;
> nested exception is:
> java.io.EOFException
> Caused by:
> java.io.EOFException
> 16 tests completed, 1 failed
> {noformat}
> Failure seen in this run:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/146
> but was passing in the following run.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-7860) Unmarshalling exception in Benchmark test with EOFException as cause
[
https://issues.apache.org/jira/browse/GEODE-7860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson updated GEODE-7860:
---
Summary: Unmarshalling exception in Benchmark test with EOFException as
cause (was: Indexed query benchmarks fail with EOFException)
> Unmarshalling exception in Benchmark test with EOFException as cause
>
>
> Key: GEODE-7860
> URL: https://issues.apache.org/jira/browse/GEODE-7860
> Project: Geode
> Issue Type: Bug
> Components: benchmarks, querying
>Reporter: Donal Evans
>Priority: Major
>
> {noformat}
> org.apache.geode.benchmark.tests.ReplicatedIndexedQueryBenchmark > run()
> FAILED
> java.util.concurrent.CompletionException: java.lang.RuntimeException:
> java.rmi.UnmarshalException: Error unmarshaling return header; nested
> exception is:
> java.io.EOFException
> Caused by:
> java.lang.RuntimeException: java.rmi.UnmarshalException: Error
> unmarshaling return header; nested exception is:
> java.io.EOFException
> Caused by:
> java.rmi.UnmarshalException: Error unmarshaling return header;
> nested exception is:
> java.io.EOFException
> Caused by:
> java.io.EOFException
> 16 tests completed, 1 failed
> org.apache.geode.benchmark.tests.PartitionedIndexedQueryBenchmark > run()
> FAILED
> java.util.concurrent.CompletionException: java.lang.RuntimeException:
> java.rmi.UnmarshalException: Error unmarshaling return header; nested
> exception is:
> java.io.EOFException
> Caused by:
> java.lang.RuntimeException: java.rmi.UnmarshalException: Error
> unmarshaling return header; nested exception is:
> java.io.EOFException
> Caused by:
> java.rmi.UnmarshalException: Error unmarshaling return header;
> nested exception is:
> java.io.EOFException
> Caused by:
> java.io.EOFException
> 16 tests completed, 1 failed
> {noformat}
> Failure seen in this run:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/146
> but was passing in the following run.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7860) Unmarshalling exception in Benchmark test with EOFException as cause
[
https://issues.apache.org/jira/browse/GEODE-7860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17237559#comment-17237559
]
Mark Hanson commented on GEODE-7860:
Seeing org.apache.geode.benchmark.tests.P2pPartitionedPutBenchmark test fail in
Build 480.
We think these are all related based on the stack trace and behavior.
> Unmarshalling exception in Benchmark test with EOFException as cause
>
>
> Key: GEODE-7860
> URL: https://issues.apache.org/jira/browse/GEODE-7860
> Project: Geode
> Issue Type: Bug
> Components: benchmarks, querying
>Reporter: Donal Evans
>Priority: Major
>
> {noformat}
> org.apache.geode.benchmark.tests.ReplicatedIndexedQueryBenchmark > run()
> FAILED
> java.util.concurrent.CompletionException: java.lang.RuntimeException:
> java.rmi.UnmarshalException: Error unmarshaling return header; nested
> exception is:
> java.io.EOFException
> Caused by:
> java.lang.RuntimeException: java.rmi.UnmarshalException: Error
> unmarshaling return header; nested exception is:
> java.io.EOFException
> Caused by:
> java.rmi.UnmarshalException: Error unmarshaling return header;
> nested exception is:
> java.io.EOFException
> Caused by:
> java.io.EOFException
> 16 tests completed, 1 failed
> org.apache.geode.benchmark.tests.PartitionedIndexedQueryBenchmark > run()
> FAILED
> java.util.concurrent.CompletionException: java.lang.RuntimeException:
> java.rmi.UnmarshalException: Error unmarshaling return header; nested
> exception is:
> java.io.EOFException
> Caused by:
> java.lang.RuntimeException: java.rmi.UnmarshalException: Error
> unmarshaling return header; nested exception is:
> java.io.EOFException
> Caused by:
> java.rmi.UnmarshalException: Error unmarshaling return header;
> nested exception is:
> java.io.EOFException
> Caused by:
> java.io.EOFException
> 16 tests completed, 1 failed
> {noformat}
> Failure seen in this run:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/146
> but was passing in the following run.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8623) Timing between DNS and Geode startup can result in permanent unknown host exceptions.
[
https://issues.apache.org/jira/browse/GEODE-8623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17237561#comment-17237561
]
ASF GitHub Bot commented on GEODE-8623:
---
Bill commented on a change in pull request #5743:
URL: https://github.com/apache/geode/pull/5743#discussion_r528897228
##
File path: geode-common/src/main/java/org/apache/geode/internal/Retry.java
##
@@ -0,0 +1,101 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
contributor license
+ * agreements. See the NOTICE file distributed with this work for additional
information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express
+ * or implied. See the License for the specific language governing permissions
and limitations under
+ * the License.
+ */
+package org.apache.geode.internal;
+
+import static java.util.concurrent.TimeUnit.NANOSECONDS;
+
+import java.util.concurrent.TimeUnit;
+import java.util.concurrent.TimeoutException;
+import java.util.function.Predicate;
+import java.util.function.Supplier;
+
+import org.apache.geode.annotations.VisibleForTesting;
+
+/**
+ * Utility class for retrying operations.
+ */
+public class Retry {
+
+ interface Timer {
+long nanoTime();
+
+void sleep(long sleepTimeInNano) throws InterruptedException;
+ }
+
+ static class SteadyTimer implements Timer {
+@Override
+public long nanoTime() {
+ return System.nanoTime();
+}
+
+@Override
+public void sleep(long sleepTimeInNano) throws InterruptedException {
+ long millis = NANOSECONDS.toMillis(sleepTimeInNano);
+ // avoid throwing IllegalArgumentException
+ if (millis > 0) {
+Thread.sleep(millis);
+ }
+}
+ }
+
+ private static final SteadyTimer steadyClock = new SteadyTimer();
+
+ /**
+ * Try the supplier function until the predicate is true or timeout occurs.
+ *
+ * @param timeout to retry for
+ * @param timeoutUnit the unit for timeout
+ * @param interval time between each try
+ * @param intervalUnit the unit for interval
+ * @param supplier to execute until predicate is true or times out
+ * @param predicate to test for retry
+ * @param type of return value
+ * @return value from supplier after it passes predicate or times out.
+ */
+ public static T tryFor(long timeout, TimeUnit timeoutUnit,
+ long interval, TimeUnit intervalUnit,
+ Supplier supplier,
+ Predicate predicate) throws TimeoutException, InterruptedException {
+return tryFor(timeout, timeoutUnit, interval, intervalUnit, supplier,
predicate, steadyClock);
+ }
+
+ @VisibleForTesting
+ static T tryFor(long timeout, TimeUnit timeoutUnit,
+ long interval, TimeUnit intervalUnit,
+ Supplier supplier,
+ Predicate predicate,
+ Timer timer) throws TimeoutException, InterruptedException {
+long until = timer.nanoTime() + NANOSECONDS.convert(timeout, timeoutUnit);
+long intervalNano = NANOSECONDS.convert(interval, intervalUnit);
+
+T value;
+for (;;) {
+ value = supplier.get();
+ if (predicate.test(value)) {
+return value;
+ } else {
+// if there is still more time left after we sleep for interval
period, then sleep and retry
+// otherwise break out and throw TimeoutException
+if ((timer.nanoTime() + intervalNano) < until) {
Review comment:
I think a user of the `Retry` class would (rightly) expect `tryFor()` to
keep trying if `timeout` has not yet been reached.
Computing `sleepNanos` gives good results when `intervalUnit` is greater
than (`timeoutUnit` - supplier time - predicate time). Without `sleepNanos`,
that scenario results in _no retries at all_ which I think most users of the
`Retry` class would find counterintuitive.
Failing to compute `sleepNanos` introduces an error. That error is directly
proportional to `interval` and the relative error (error / `timeout`) grows as
`interval` grows relative to `timeout`.
Computing `sleepNanos` is simple and cheap. It gives better accuracy and
meets user expectations in all cases. Unless you foresee some problem computing
`sleepNanos` I still recommend doing it.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[jira] [Commented] (GEODE-5782) LauncherMemberMXBeanIntegrationTest can fail intermittently
[
https://issues.apache.org/jira/browse/GEODE-5782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17237700#comment-17237700
]
Geode Integration commented on GEODE-5782:
--
Seen in [WindowsCoreIntegrationTestOpenJDK11
#589|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsCoreIntegrationTestOpenJDK11/builds/589]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0510/test-results/integrationTest/1606157418/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0510/test-artifacts/1606157418/windows-coreintegrationtestfiles-OpenJDK11-1.14.0-build.0510.tgz].
> LauncherMemberMXBeanIntegrationTest can fail intermittently
> ---
>
> Key: GEODE-5782
> URL: https://issues.apache.org/jira/browse/GEODE-5782
> Project: Geode
> Issue Type: Test
> Components: jmx
>Affects Versions: 1.9.0
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Noticed this failure:
> {noformat}
> org.apache.geode.distributed.LauncherMemberMXBeanIntegrationTest >
> showOSMetrics_reconstructsOSMetricsFromCompositeDataType FAILED
> org.junit.ComparisonFailure: expected:<204.[68]> but was:<204.[55]>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.distributed.LauncherMemberMXBeanIntegrationTest.showOSMetrics_reconstructsOSMetricsFromCompositeDataType(LauncherMemberMXBeanIntegrationTest.java:143)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8623) Timing between DNS and Geode startup can result in permanent unknown host exceptions.
[
https://issues.apache.org/jira/browse/GEODE-8623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17237790#comment-17237790
]
ASF GitHub Bot commented on GEODE-8623:
---
jinmeiliao commented on a change in pull request #5743:
URL: https://github.com/apache/geode/pull/5743#discussion_r529135195
##
File path: geode-common/src/main/java/org/apache/geode/internal/Retry.java
##
@@ -0,0 +1,101 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
contributor license
+ * agreements. See the NOTICE file distributed with this work for additional
information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express
+ * or implied. See the License for the specific language governing permissions
and limitations under
+ * the License.
+ */
+package org.apache.geode.internal;
+
+import static java.util.concurrent.TimeUnit.NANOSECONDS;
+
+import java.util.concurrent.TimeUnit;
+import java.util.concurrent.TimeoutException;
+import java.util.function.Predicate;
+import java.util.function.Supplier;
+
+import org.apache.geode.annotations.VisibleForTesting;
+
+/**
+ * Utility class for retrying operations.
+ */
+public class Retry {
+
+ interface Timer {
+long nanoTime();
+
+void sleep(long sleepTimeInNano) throws InterruptedException;
+ }
+
+ static class SteadyTimer implements Timer {
+@Override
+public long nanoTime() {
+ return System.nanoTime();
+}
+
+@Override
+public void sleep(long sleepTimeInNano) throws InterruptedException {
+ long millis = NANOSECONDS.toMillis(sleepTimeInNano);
+ // avoid throwing IllegalArgumentException
+ if (millis > 0) {
+Thread.sleep(millis);
+ }
+}
+ }
+
+ private static final SteadyTimer steadyClock = new SteadyTimer();
+
+ /**
+ * Try the supplier function until the predicate is true or timeout occurs.
+ *
+ * @param timeout to retry for
+ * @param timeoutUnit the unit for timeout
+ * @param interval time between each try
+ * @param intervalUnit the unit for interval
+ * @param supplier to execute until predicate is true or times out
+ * @param predicate to test for retry
+ * @param type of return value
+ * @return value from supplier after it passes predicate or times out.
+ */
+ public static T tryFor(long timeout, TimeUnit timeoutUnit,
+ long interval, TimeUnit intervalUnit,
+ Supplier supplier,
+ Predicate predicate) throws TimeoutException, InterruptedException {
+return tryFor(timeout, timeoutUnit, interval, intervalUnit, supplier,
predicate, steadyClock);
+ }
+
+ @VisibleForTesting
+ static T tryFor(long timeout, TimeUnit timeoutUnit,
+ long interval, TimeUnit intervalUnit,
+ Supplier supplier,
+ Predicate predicate,
+ Timer timer) throws TimeoutException, InterruptedException {
+long until = timer.nanoTime() + NANOSECONDS.convert(timeout, timeoutUnit);
+long intervalNano = NANOSECONDS.convert(interval, intervalUnit);
+
+T value;
+for (;;) {
+ value = supplier.get();
+ if (predicate.test(value)) {
+return value;
+ } else {
+// if there is still more time left after we sleep for interval
period, then sleep and retry
+// otherwise break out and throw TimeoutException
+if ((timer.nanoTime() + intervalNano) < until) {
Review comment:
> I think a user of the `Retry` class would (rightly) expect `tryFor()`
to keep trying if `timeout` has not yet been reached.
>
> Computing `sleepNanos` gives good results when `intervalUnit` is greater
than (`timeoutUnit` - supplier time - predicate time). Without `sleepNanos`,
that scenario results in _no retries at all_ which I think most users of the
`Retry` class would find counterintuitive.
So if say timeout is 5 second, supplier and predicate takes 3 seconds, and
interval is 3 seconds, I won't expect there would be any retries at all. I
don't think this is counterintuitive.
> Failing to compute `sleepNanos` introduces an error. That error is
directly proportional to `interval` and the relative error (error / `timeout`)
grows as `interval` grows relative to `timeout`.
>
> Computing `sleepNanos` is simple and cheap. It gives better accuracy and
meets user expectations in all cases. Unless you foresee some problem computing
`sleepNanos` I still recommend doing it.
--
[jira] [Commented] (GEODE-8656) Ping not sent to the right gateway receiver endpoint when several receivers have the same hostname-for-senders value
[ https://issues.apache.org/jira/browse/GEODE-8656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17237898#comment-17237898 ] ASF GitHub Bot commented on GEODE-8656: --- mkevo merged pull request #5670: URL: https://github.com/apache/geode/pull/5670 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Ping not sent to the right gateway receiver endpoint when several receivers > have the same hostname-for-senders value > > > Key: GEODE-8656 > URL: https://issues.apache.org/jira/browse/GEODE-8656 > Project: Geode > Issue Type: Bug > Components: wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > When several gateway receivers have the same value for hostname-for-senders > (for example when running Geode under kubernetes and a load balancer balances > the load among the remote servers), the ping messages sent from the gateway > sender client are only sent to the receiver (endpoint) to which the sender > connected first. > The other receivers will not get the ping message which will imply that the > connections towards them will be closed after the configured timeout expires. > This ticket is a continuation of the work done ticket GEODE-7565. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8656) Ping not sent to the right gateway receiver endpoint when several receivers have the same hostname-for-senders value
[ https://issues.apache.org/jira/browse/GEODE-8656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17237900#comment-17237900 ] ASF subversion and git services commented on GEODE-8656: Commit c92a91eae587800c9d24c973e536cdfe8da6f38a in geode's branch refs/heads/develop from Alberto Gomez [ https://gitbox.apache.org/repos/asf?p=geode.git;h=c92a91e ] GEODE-8656: Fix ping only sent to one gateway receiver when several r… (#5670) * GEODE-8656: Fix ping only sent to one gateway receiver when several receivers share the same hostname-for-senders When serveral receivers have the same hostname-for-senders only one of them received pings. The reason was that the structure holding the endpoints was a Map whose key was the server location. As all the endpoints for the remote gateway senders shared the same server location, only one received the ping. The structure holding endpoints in the endpoint manager has been updated to use as key a ServerLocationAndMemberId class instead of ServerLocation. > Ping not sent to the right gateway receiver endpoint when several receivers > have the same hostname-for-senders value > > > Key: GEODE-8656 > URL: https://issues.apache.org/jira/browse/GEODE-8656 > Project: Geode > Issue Type: Bug > Components: wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > When several gateway receivers have the same value for hostname-for-senders > (for example when running Geode under kubernetes and a load balancer balances > the load among the remote servers), the ping messages sent from the gateway > sender client are only sent to the receiver (endpoint) to which the sender > connected first. > The other receivers will not get the ping message which will imply that the > connections towards them will be closed after the configured timeout expires. > This ticket is a continuation of the work done ticket GEODE-7565. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8656) Ping not sent to the right gateway receiver endpoint when several receivers have the same hostname-for-senders value
[ https://issues.apache.org/jira/browse/GEODE-8656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17237899#comment-17237899 ] ASF subversion and git services commented on GEODE-8656: Commit c92a91eae587800c9d24c973e536cdfe8da6f38a in geode's branch refs/heads/develop from Alberto Gomez [ https://gitbox.apache.org/repos/asf?p=geode.git;h=c92a91e ] GEODE-8656: Fix ping only sent to one gateway receiver when several r… (#5670) * GEODE-8656: Fix ping only sent to one gateway receiver when several receivers share the same hostname-for-senders When serveral receivers have the same hostname-for-senders only one of them received pings. The reason was that the structure holding the endpoints was a Map whose key was the server location. As all the endpoints for the remote gateway senders shared the same server location, only one received the ping. The structure holding endpoints in the endpoint manager has been updated to use as key a ServerLocationAndMemberId class instead of ServerLocation. > Ping not sent to the right gateway receiver endpoint when several receivers > have the same hostname-for-senders value > > > Key: GEODE-8656 > URL: https://issues.apache.org/jira/browse/GEODE-8656 > Project: Geode > Issue Type: Bug > Components: wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > When several gateway receivers have the same value for hostname-for-senders > (for example when running Geode under kubernetes and a load balancer balances > the load among the remote servers), the ping messages sent from the gateway > sender client are only sent to the receiver (endpoint) to which the sender > connected first. > The other receivers will not get the ping message which will imply that the > connections towards them will be closed after the configured timeout expires. > This ticket is a continuation of the work done ticket GEODE-7565. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8656) Ping not sent to the right gateway receiver endpoint when several receivers have the same hostname-for-senders value
[ https://issues.apache.org/jira/browse/GEODE-8656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez resolved GEODE-8656. -- Fix Version/s: 1.14.0 Resolution: Fixed > Ping not sent to the right gateway receiver endpoint when several receivers > have the same hostname-for-senders value > > > Key: GEODE-8656 > URL: https://issues.apache.org/jira/browse/GEODE-8656 > Project: Geode > Issue Type: Bug > Components: wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > When several gateway receivers have the same value for hostname-for-senders > (for example when running Geode under kubernetes and a load balancer balances > the load among the remote servers), the ping messages sent from the gateway > sender client are only sent to the receiver (endpoint) to which the sender > connected first. > The other receivers will not get the ping message which will imply that the > connections towards them will be closed after the configured timeout expires. > This ticket is a continuation of the work done ticket GEODE-7565. -- This message was sent by Atlassian Jira (v8.3.4#803005)
