[jira] [Commented] (GEODE-7912) cacheWriter should be triggered when PR.clear
[ https://issues.apache.org/jira/browse/GEODE-7912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17070737#comment-17070737 ] ASF subversion and git services commented on GEODE-7912: Commit b412d216683fbc28fbc5fe8fb6d36d5edaa7d92f in geode's branch refs/heads/feature/GEODE-7912 from zhouxh [ https://gitbox.apache.org/repos/asf?p=geode.git;h=b412d21 ] GEODE-7912: cacheWriter should be triggered when PR.clear Co-authored-by: Anil Co-authored-by: Xiaojian Zhou > cacheWriter should be triggered when PR.clear > - > > Key: GEODE-7912 > URL: https://issues.apache.org/jira/browse/GEODE-7912 > Project: Geode > Issue Type: Improvement >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeCommons > > If server configured cacheWriter, PR.clear should trigger it the same way as > PR.destroyRegion does. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7852) Add client side configuration option to support a SNI proxy
[ https://issues.apache.org/jira/browse/GEODE-7852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17071080#comment-17071080 ] ASF subversion and git services commented on GEODE-7852: Commit e10cf659e82ea536e8edac2b85048cf921ccb674 in geode's branch refs/heads/develop from Dan Smith [ https://gitbox.apache.org/repos/asf?p=geode.git;h=e10cf65 ] GEODE-7852: Move sni test files to a test specific dir Most of these resources are fairly specific to this test. Moving them all to a package named sni. > Add client side configuration option to support a SNI proxy > --- > > Key: GEODE-7852 > URL: https://issues.apache.org/jira/browse/GEODE-7852 > Project: Geode > Issue Type: Improvement > Components: client/server, membership >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Fix For: 1.13.0 > > Time Spent: 2h 10m > Remaining Estimate: 0h > > Add an option to the client side configuration to support a the use of a [SNI > proxy|https://www.bamsoftware.com/computers/sniproxy/]. > See also GEODE-7837, which adds a system property to support a SNI proxy. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7908) Generate error when user attempts to configure SNI without SSL
[ https://issues.apache.org/jira/browse/GEODE-7908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Burcham resolved GEODE-7908. - Resolution: Won't Fix > Generate error when user attempts to configure SNI without SSL > -- > > Key: GEODE-7908 > URL: https://issues.apache.org/jira/browse/GEODE-7908 > Project: Geode > Issue Type: Improvement > Components: membership >Reporter: Ernest Burghardt >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > SNI is only usable in the context of (client-to-locator and client-to-server) > TLS/SSL. But we're using system properties and Geode configuration properties > to configure TLS/SSL. The possibility arises that a user may specify one > without the other. > When this story is done there will be a test that verifies that when a user > configures SNI without (client-to-locator and client-to-server) SSL, an > error/exception TBD is generated (thrown, logged) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7908) Generate error when user attempts to configure SNI without SSL
[ https://issues.apache.org/jira/browse/GEODE-7908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17071117#comment-17071117 ] Bill Burcham commented on GEODE-7908: - Without major changes, there is no good place to do this checking. > Generate error when user attempts to configure SNI without SSL > -- > > Key: GEODE-7908 > URL: https://issues.apache.org/jira/browse/GEODE-7908 > Project: Geode > Issue Type: Improvement > Components: membership >Reporter: Ernest Burghardt >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > SNI is only usable in the context of (client-to-locator and client-to-server) > TLS/SSL. But we're using system properties and Geode configuration properties > to configure TLS/SSL. The possibility arises that a user may specify one > without the other. > When this story is done there will be a test that verifies that when a user > configures SNI without (client-to-locator and client-to-server) SSL, an > error/exception TBD is generated (thrown, logged) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-2458) RegionManagementDUnitTest fails with AssertionError in verifyMemberNotifications
[
https://issues.apache.org/jira/browse/GEODE-2458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17071132#comment-17071132
]
Dale Emery commented on GEODE-2458:
---
Failure in CI today:
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/1690
Test results:
http://files.apachegeode-ci.info/builds/apache-develop-main/1.13.0-SNAPSHOT.0128/test-results/distributedTest/1585547397/
Stack trace:
{noformat}
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.management.RegionManagementDUnitTest$$Lambda$54/840813390.run
in VM 0 running on Host 202d105afa0a with 4 VMs
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
at
org.apache.geode.management.RegionManagementDUnitTest.testPartitionedRegion(RegionManagementDUnitTest.java:215)
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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at
org.apache.geode.test.dunit.rules.AbstractDistributedRule$1.evaluate(AbstractDistributedRule.java:59)
at
org.apache.geode.test.dunit.rules.AbstractDistributedRule$1.evaluate(AbstractDistributedRule.java:59)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
at
org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
at
org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
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.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at
org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
at
org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
at
org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:118)
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.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(Reflec
[jira] [Updated] (GEODE-7460) CI failure: DistributedMemberDUnitTest.testGroupsInAllVMs ForcedDisconnectException Failure
[ https://issues.apache.org/jira/browse/GEODE-7460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Burcham updated GEODE-7460: Summary: CI failure: DistributedMemberDUnitTest.testGroupsInAllVMs ForcedDisconnectException Failure (was: CI failure: DistributedMemberDUnitTest.testGroupsInAllVMs Failure) > CI failure: DistributedMemberDUnitTest.testGroupsInAllVMs > ForcedDisconnectException Failure > --- > > Key: GEODE-7460 > URL: https://issues.apache.org/jira/browse/GEODE-7460 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Robert Houghton >Assignee: Bill Burcham >Priority: Major > Fix For: 1.12.0 > > > From the failing job: > =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > http://files.apachegeode-ci.info/builds/apache-develop-main/1.12.0-SNAPSHOT.0016/test-results/distributedTest/1573784422/ > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Test report artifacts from this job are available at: > http://files.apachegeode-ci.info/builds/apache-develop-main/1.12.0-SNAPSHOT.0016/test-artifacts/1573784422/distributedtestfiles-OpenJDK8-1.12.0-SNAPSHOT.0016.tgz > DistributedTest failure due to exception: > org.apache.geode.distributed.DistributedMemberDUnitTest > testGroupsInAllVMs > FAILED > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.distributed.DistributedMemberDUnitTest$6.run in VM 0 running > on Host 3e09f1029b44 with 4 VMs > at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579) > at org.apache.geode.test.dunit.VM.invoke(VM.java:406) > at > org.apache.geode.distributed.DistributedMemberDUnitTest.testGroupsInAllVMs(DistributedMemberDUnitTest.java:333) > 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:1625) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:354) > at > org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:759) > at > org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:136) > at > org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3009) > at > org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:269) > at > org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:159) > at > org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.getSystem(JUnit4DistributedTestCase.java:181) > at > org.apache.geode.distributed.DistributedMemberDUnitTest$6.run(DistributedMemberDUnitTest.java:339) > Caused by: > > org.apache.geode.distributed.DistributedSystemDisconnectedException: > DistributedSystem is shutting down, caused by > org.apache.geode.ForcedDisconnectException: Exiting due to possible network > partition event due to loss of 1 cache processes: > [172.17.0.14(myName:1):41001] > at > org.apache.geode.distributed.internal.membership.adapter.GMSMembershipManager.directChannelSend(GMSMembershipManager.java:1591) > at > org.apache.geode.distributed.internal.membership.adapter.GMSMembershipManager.send(GMSMembershipManager.java:1751) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2058) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1985) > at > org.apache.geode.distributed.internal.StartupOperation.sendStartupMessage(StartupOperation.java:74) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1622) > ... 8 more > Caused by: > org.apache.geode.ForcedDisconnectException: Exiting due to > possible network partition event due to loss of 1 cache processes: > [172.17.0.14(myName:1):41001] > java.lang.AssertionError: Suspicious strings were written to the log > during this run. > Fix the strings or use IgnoredException.addIgnoredException to ignore. > --- > Found
[jira] [Commented] (GEODE-6903) CI Failure: GemFireTransactionDataSourceIntegrationTest.testExceptionHandlingGetConnection failed with Assertion
[
https://issues.apache.org/jira/browse/GEODE-6903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17071142#comment-17071142
]
Dale Emery commented on GEODE-6903:
---
Failure in CI:
[https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsCoreIntegrationTestOpenJDK8/builds/884]
Test results:
[http://files.apachegeode-ci.info/builds/apache-develop-main/1.13.0-SNAPSHOT.0126/test-results/integrationTest/1585536868/classes/org.apache.geode.internal.datasource.GemFireTransactionDataSourceIntegrationTest.html#testExceptionHandlingGetConnection]
Stack trace looks the same as earlier reports.
> CI Failure:
> GemFireTransactionDataSourceIntegrationTest.testExceptionHandlingGetConnection
> failed with Assertion
>
>
> Key: GEODE-6903
> URL: https://issues.apache.org/jira/browse/GEODE-6903
> Project: Geode
> Issue Type: Bug
> Components: transactions
>Reporter: Eric Shu
>Assignee: Kirk Lund
>Priority: Major
> Labels: flaky
>
> {noformat}
> org.apache.geode.internal.datasource.GemFireTransactionDataSourceIntegrationTest
> > testExceptionHandlingGetConnection FAILED
> org.junit.ComparisonFailure: expected:<[0]> but was:<[2]>
> at sun.reflect.GeneratedConstructorAccessor26.newInstance(Unknown
> Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.datasource.GemFireTransactionDataSourceIntegrationTest.testExceptionHandlingGetConnection(GemFireTransactionDataSourceIntegrationTest.java:141)
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0399/test-results/integrationTest/1561170841/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0399/test-artifacts/1561170841/integrationtestfiles-OpenJDK8-1.10.0-SNAPSHOT.0399.tgz
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-7924) Upgrade Connect2id Nimbus JOSE+JWT library used by Pulse oAuth work
Jinmei Liao created GEODE-7924: -- Summary: Upgrade Connect2id Nimbus JOSE+JWT library used by Pulse oAuth work Key: GEODE-7924 URL: https://issues.apache.org/jira/browse/GEODE-7924 Project: Geode Issue Type: Improvement Components: pulse Reporter: Jinmei Liao use Connect2id Nimbus JOSE+JWT greater than v7.9 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7905) RedisDistDUnitTest failing intermittently in CI
[
https://issues.apache.org/jira/browse/GEODE-7905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17071152#comment-17071152
]
Dale Emery commented on GEODE-7905:
---
New failure in CI:
[https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/1668]
Test results:
[http://files.apachegeode-ci.info/builds/apache-develop-main/1.13.0-SNAPSHOT.0126/test-results/distributedTest/1585531160/classes/org.apache.geode.redis.RedisDistDUnitTest.html#classMethod]
> RedisDistDUnitTest failing intermittently in CI
> ---
>
> Key: GEODE-7905
> URL: https://issues.apache.org/jira/browse/GEODE-7905
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Sarah Abbey
>Assignee: Raymond Ingles
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Fix RedisDistDUnitTest, which fails intermittently:
> [https://concourse.apachegeode-ci.info/builds/141130]
>
> {code:java}
> org.apache.geode.redis.RedisDistDUnitTest > classMethod FAILED
> java.lang.AssertionError: Suspicious strings were written to the log during
> this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 5030
> [error 2020/03/23 19:26:51.559 GMT tid=99]
> org.apache.geode.ToDataException: toData failed on DataSerializer with id=0
> for class class java.util.HashSet
> 6 tests completed, 1 failed
> {code}
>
> ASSIGNED TO: sabbey37 [Sarah Abbey] / ringles [Raymond Ingles]
> (unfortunately we can't assign it to ourselves, though we've sent an email to
> : [d...@geode.apache.org|mailto:d...@geode.apache.org] requesting access.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7851) Pulse should support OAuth2 authorization code flow
[ https://issues.apache.org/jira/browse/GEODE-7851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17071155#comment-17071155 ] ASF subversion and git services commented on GEODE-7851: Commit 4984ed9894e0b0a2018c9f12262a1a6f79a46d69 in geode's branch refs/heads/develop from Jinmei Liao [ https://gitbox.apache.org/repos/asf?p=geode.git;h=4984ed9 ] GEODE-7851: use the latest version of nimbus-jose-jwt.jar (#4851) > Pulse should support OAuth2 authorization code flow > --- > > Key: GEODE-7851 > URL: https://issues.apache.org/jira/browse/GEODE-7851 > Project: Geode > Issue Type: New Feature > Components: docs, pulse >Reporter: Jinmei Liao >Assignee: Dale Emery >Priority: Major > Time Spent: 6h 50m > Remaining Estimate: 0h > > Instead of using username/password to log in to pulse, pulse should redirect > to a configured authentication provider to get access token to login. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7924) Upgrade Connect2id Nimbus JOSE+JWT library used by Pulse oAuth work
[ https://issues.apache.org/jira/browse/GEODE-7924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-7924. Fix Version/s: 1.13.0 Resolution: Fixed fixed by this PR: https://github.com/apache/geode/pull/4851 > Upgrade Connect2id Nimbus JOSE+JWT library used by Pulse oAuth work > --- > > Key: GEODE-7924 > URL: https://issues.apache.org/jira/browse/GEODE-7924 > Project: Geode > Issue Type: Improvement > Components: pulse >Reporter: Jinmei Liao >Priority: Major > Fix For: 1.13.0 > > > use Connect2id Nimbus JOSE+JWT greater than v7.9 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7925) Add concurrency test to PubSubDUnitTest
Jens Deppe created GEODE-7925: - Summary: Add concurrency test to PubSubDUnitTest Key: GEODE-7925 URL: https://issues.apache.org/jira/browse/GEODE-7925 Project: Geode Issue Type: Test Components: redis Reporter: Jens Deppe -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-7925) Add concurrency test to PubSubDUnitTest
[ https://issues.apache.org/jira/browse/GEODE-7925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe reassigned GEODE-7925: - Assignee: Jens Deppe > Add concurrency test to PubSubDUnitTest > --- > > Key: GEODE-7925 > URL: https://issues.apache.org/jira/browse/GEODE-7925 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7917) Problem forming SSL connection in multisite setup
[ https://issues.apache.org/jira/browse/GEODE-7917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivanac updated GEODE-7917: Description: We are installing two sites, with one locator in each site, and TLS enabled. Problem appears when locators on both sides are started at same time. In that case, on both locators, immediately after they are started, IllegalStateException is caught, and connections are never reestablished. javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake at java.base/sun.security.ssl.SSLSocketImpl.handleEOF(SSLSocketImpl.java:1320) at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1159) at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1062) at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402) at org.apache.geode.internal.net.SocketCreator.configureClientSSLSocket(SocketCreator.java:1112) at org.apache.geode.internal.net.SocketCreator.connect(SocketCreator.java:879) at org.apache.geode.internal.net.SocketCreator.connect(SocketCreator.java:841) at org.apache.geode.internal.net.SocketCreator.connect(SocketCreator.java:830) at org.apache.geode.distributed.internal.tcpserver.TcpClient.requestToServer(TcpClient.java:208) at org.apache.geode.cache.client.internal.locator.wan.LocatorDiscovery.exchangeRemoteLocators(LocatorDiscovery.java:195) at org.apache.geode.cache.client.internal.locator.wan.LocatorDiscovery$RemoteLocatorDiscovery.run(LocatorDiscovery.java:121) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base/java.lang.Thread.run(Thread.java:834) Suppressed: java.net.SocketException: Broken pipe (Write failed) at java.base/java.net.SocketOutputStream.socketWrite0(Native Method) at java.base/java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:110) at java.base/java.net.SocketOutputStream.write(SocketOutputStream.java:150) at java.base/sun.security.ssl.SSLSocketOutputRecord.encodeAlert(SSLSocketOutputRecord.java:81) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:351) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:263) at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:405) ... 10 more Caused by: java.io.EOFException: SSL peer shut down incorrectly at java.base/sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:167) at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:108) at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1151) ... 12 more was:We are installing two sites, with one locator in each site, and TLS enabled. Problem appears when locators on both sides are started at same time. In that case, on both locators, immediately after they are started, IllegalStateException is caught, and connections are never reestablished. > Problem forming SSL connection in multisite setup > - > > Key: GEODE-7917 > URL: https://issues.apache.org/jira/browse/GEODE-7917 > Project: Geode > Issue Type: Bug > Components: wan >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > We are installing two sites, with one locator in each site, and TLS enabled. > Problem appears when locators on both sides are started at same time. In that > case, on both locators, immediately after they are started, > IllegalStateException is caught, and connections are never reestablished. > > javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake > at > java.base/sun.security.ssl.SSLSocketImpl.handleEOF(SSLSocketImpl.java:1320) > at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1159) > at > java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1062) > at > java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402) > at > org.apache.geode.internal.net.SocketCreator.configureClientSSLSocket(SocketCreator.java:1112) > at > org.apache.geode.internal.net.SocketCreator.connect(SocketCreator.java:879) > at > org.apache.geode.internal.net.SocketCreator.connect(SocketCreator.java:841) > at > org.apache.geode.internal.net.SocketCreator.connect(SocketCreator.java:830) > at > org.apache.geode.distributed.internal.tcpserver.TcpClient.requestToServer(TcpClient.java:208) > at > org.apache.geode.cache.client.internal.locator.wan.LocatorDiscovery.exchangeRemoteLocators(LocatorDiscovery.java:195) > at > org.apache.geode.cache.client.internal.locator.wan.LocatorDiscovery$RemoteLocatorDiscovery.run(LocatorD
[jira] [Commented] (GEODE-7914) create missing unit test for Redis Module Expire Command
[ https://issues.apache.org/jira/browse/GEODE-7914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17071178#comment-17071178 ] ASF subversion and git services commented on GEODE-7914: Commit fb2c273c3e9307e8956c7127d208a50b4bbb1a43 in geode's branch refs/heads/develop from John Hutchison [ https://gitbox.apache.org/repos/asf?p=geode.git;h=fb2c273 ] GEODE-7914: create missing unit test for Redis Module Expire Command (#4852) Co-authored-by: John Hutchison Co-authored-by: Jens Deppe > create missing unit test for Redis Module Expire Command > > > Key: GEODE-7914 > URL: https://issues.apache.org/jira/browse/GEODE-7914 > Project: Geode > Issue Type: Test >Reporter: John Hutchison >Priority: Major > Time Spent: 1.5h > Remaining Estimate: 0h > > incorporating feedback related to test suite -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7864) Code improvement refactoring
[ https://issues.apache.org/jira/browse/GEODE-7864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17071191#comment-17071191 ] ASF subversion and git services commented on GEODE-7864: Commit 2cf9925047ab60bf33979b718222674d00c6b3f7 in geode's branch refs/heads/develop from Nabarun Nag [ https://gitbox.apache.org/repos/asf?p=geode.git;h=2cf9925 ] GEODE-7864: Print contents of arrays correctly. (#4879) > Code improvement refactoring > > > Key: GEODE-7864 > URL: https://issues.apache.org/jira/browse/GEODE-7864 > Project: Geode > Issue Type: Improvement >Reporter: Nabarun Nag >Priority: Major > Time Spent: 9h 40m > Remaining Estimate: 0h > > This is a placeholder ticket. > * this is used to do refactoring. > * this ticket number is used to number the commit message. > * this ticket will never be closed. > * it will be used to mark improvements like correcting spelling mistakes, > efficient java code, etc. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7919) Move MembershipOnlyJunit test to the geode-membership module
[ https://issues.apache.org/jira/browse/GEODE-7919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17071193#comment-17071193 ] ASF subversion and git services commented on GEODE-7919: Commit 4966e505b6fd6224967bbf1ac5487e8ddf1bdfc5 in geode's branch refs/heads/develop from Dan Smith [ https://gitbox.apache.org/repos/asf?p=geode.git;h=4966e50 ] GEODE-7919: Moving membership integration test to geode-membership (#4862) Moving MembershipOnlyTest to MembershipIntegrationTest in the geode-membership module and adding some more tests. > Move MembershipOnlyJunit test to the geode-membership module > > > Key: GEODE-7919 > URL: https://issues.apache.org/jira/browse/GEODE-7919 > Project: Geode > Issue Type: Improvement > Components: membership >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Time Spent: 1h 10m > Remaining Estimate: 0h > > Move the MembershipOnlyJunit test to the membership module and add more > integration tests that test running multiple membership managers connecting > to each other, using the membership api. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7919) Move MembershipOnlyJunit test to the geode-membership module
[ https://issues.apache.org/jira/browse/GEODE-7919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith resolved GEODE-7919. -- Fix Version/s: 1.12.0 Resolution: Fixed > Move MembershipOnlyJunit test to the geode-membership module > > > Key: GEODE-7919 > URL: https://issues.apache.org/jira/browse/GEODE-7919 > Project: Geode > Issue Type: Improvement > Components: membership >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Fix For: 1.12.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Move the MembershipOnlyJunit test to the membership module and add more > integration tests that test running multiple membership managers connecting > to each other, using the membership api. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7919) Move MembershipOnlyJunit test to the geode-membership module
[ https://issues.apache.org/jira/browse/GEODE-7919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith updated GEODE-7919: - Fix Version/s: (was: 1.12.0) 1.13.0 > Move MembershipOnlyJunit test to the geode-membership module > > > Key: GEODE-7919 > URL: https://issues.apache.org/jira/browse/GEODE-7919 > Project: Geode > Issue Type: Improvement > Components: membership >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Fix For: 1.13.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Move the MembershipOnlyJunit test to the membership module and add more > integration tests that test running multiple membership managers connecting > to each other, using the membership api. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7918) Improve error in geode-tcp-server under DNS hijacking (ISP) issues
[ https://issues.apache.org/jira/browse/GEODE-7918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Houghton resolved GEODE-7918. Fix Version/s: 1.13.0 Resolution: Fixed > Improve error in geode-tcp-server under DNS hijacking (ISP) issues > -- > > Key: GEODE-7918 > URL: https://issues.apache.org/jira/browse/GEODE-7918 > Project: Geode > Issue Type: Improvement > Components: tests >Reporter: Robert Houghton >Priority: Major > Fix For: 1.13.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Testing Geode from home, my DNS from ISP was resolving things to a search > engine causing test failures. Adds messaging to the tests that failed to give > clues to future victims. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7914) create missing unit test for Redis Module Expire Command
[ https://issues.apache.org/jira/browse/GEODE-7914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Hutchison resolved GEODE-7914. --- Resolution: Done > create missing unit test for Redis Module Expire Command > > > Key: GEODE-7914 > URL: https://issues.apache.org/jira/browse/GEODE-7914 > Project: Geode > Issue Type: Test >Reporter: John Hutchison >Priority: Major > Time Spent: 1.5h > Remaining Estimate: 0h > > incorporating feedback related to test suite -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-6536) client pr single hop will do multiple hops if things get busy
[
https://issues.apache.org/jira/browse/GEODE-6536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17071235#comment-17071235
]
ASF subversion and git services commented on GEODE-6536:
Commit b021b127867d1e01e09fac26de10d29f896ed7dc in geode's branch
refs/heads/develop from Mario Ivanac
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=b021b12 ]
Feature/geode 6536 2: Added retry in borrowConnection/single hop (#4833)
* GEODE-6536: Added retry in borrowConnection/single hop
* GEODE-6536: bug fix
* GEODE-6536: update after comments
* GEODE-6536: modify borrowConnection singleHop solution
* GEODE-6536: test update
* GEODE-6536: updated tests, and added parameter to desable timeout
* GEODE-6536: update of cachexml impacts
* GEODE-6536: remove cachexml restriction
* GEODE-6536: update default value and documentation
* GEODE-6536_2: change exception type
* GEODE-6536_2: seize new connection only in case onlyUseExistingCnx=false
> client pr single hop will do multiple hops if things get busy
> -
>
> Key: GEODE-6536
> URL: https://issues.apache.org/jira/browse/GEODE-6536
> Project: Geode
> Issue Type: Improvement
> Components: client/server
>Reporter: Darrel Schneider
>Assignee: Mario Ivanac
>Priority: Major
> Labels: needs-review, performance, pull-request-available
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> I was wondering why ConnectionManagerImpl.borrowConnection that targets a
> particular server will not wait for a connection to be available. This is the
> borrow used by pr single hop. It seems like if all the cnxs to that server
> are busy and we are at max that it should wait. But instead it does a single
> scan of the pool and if it does not find an idle connection it either throws
> AllConnectionsInUse or it creates one. The caller sets the onlyUseExistingCnx
> parameter based on if the pool is at max cnxs or not (seems like this should
> have been done in borrowConnection instead of the caller). If it throws
> AllConnectionsInUse the caller catches it and ignores it and then falls into
> doing a non-targeted borrow that will wait for a connection but to ANY
> server. So our single hop optimization goes away on a busy client. Since it
> can’t immediately get a connection to server A, it says just give me a
> connection to any server sends the op to that other server and that server
> ends up having to forward it to server A. You would only see this problem if
> you set a max on your client connection pool. The default of -1 just says to
> always create another connection. The only workaround I know of is to not
> limit how many connections your client can create but that could cause other
> problem (i.e. too many file descriptors).
> The questionable code is in the following classes:
> org.apache.geode.cache.client.internal.GetOp
> org.apache.geode.cache.client.internal.PutOp
> org.apache.geode.cache.client.internal.DestroyOp
> The all have something like this:
>
> {code:java}
> boolean onlyUseExistingCnx = ((poolImpl.getMaxConnections() != -1
> && poolImpl.getConnectionCount() >= poolImpl.getMaxConnections()) ? true :
> false);
> op.setAllowDuplicateMetadataRefresh(!onlyUseExistingCnx);
> return pool.executeOn(new ServerLocation(server.getHostName(),
> server.getPort()), op,
> true, onlyUseExistingCnx);
> {code}
> executeOn eventually calls ConnectionManagerImpl.borrowConnection
> It is unclear to me why they need allow duplicate metadata refresh if they
> permit borrowConnection to create a new connection to the specified server.
> They all catch and ignore
> AllConnectionsInUseException falling through and doing non-targetted
> pool.execute.
> The concern might have been that the pool would be full of connections to
> other servers preventing us from connecting to the server we need to
> communicate with. If we have existing connections to the server we could wait
> for one of those. If we don't and we are at max then we should consider
> closing a connection to some other server and create a connection to the
> server we know we need for this operation. As the server count goes up and
> the max connection count on the pool goes down I'm sure we are probably
> better off not even trying to do single hop since we might not even be able
> to have a connection to each server in the pool. But if we have a reasonable
> max connection count then it seems like we could make more of an effort to
> make sure a per server connection count is balanced and then wait for one of
> those connection to be available.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-6536) client pr single hop will do multiple hops if things get busy
[
https://issues.apache.org/jira/browse/GEODE-6536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17071236#comment-17071236
]
ASF subversion and git services commented on GEODE-6536:
Commit b021b127867d1e01e09fac26de10d29f896ed7dc in geode's branch
refs/heads/develop from Mario Ivanac
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=b021b12 ]
Feature/geode 6536 2: Added retry in borrowConnection/single hop (#4833)
* GEODE-6536: Added retry in borrowConnection/single hop
* GEODE-6536: bug fix
* GEODE-6536: update after comments
* GEODE-6536: modify borrowConnection singleHop solution
* GEODE-6536: test update
* GEODE-6536: updated tests, and added parameter to desable timeout
* GEODE-6536: update of cachexml impacts
* GEODE-6536: remove cachexml restriction
* GEODE-6536: update default value and documentation
* GEODE-6536_2: change exception type
* GEODE-6536_2: seize new connection only in case onlyUseExistingCnx=false
> client pr single hop will do multiple hops if things get busy
> -
>
> Key: GEODE-6536
> URL: https://issues.apache.org/jira/browse/GEODE-6536
> Project: Geode
> Issue Type: Improvement
> Components: client/server
>Reporter: Darrel Schneider
>Assignee: Mario Ivanac
>Priority: Major
> Labels: needs-review, performance, pull-request-available
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> I was wondering why ConnectionManagerImpl.borrowConnection that targets a
> particular server will not wait for a connection to be available. This is the
> borrow used by pr single hop. It seems like if all the cnxs to that server
> are busy and we are at max that it should wait. But instead it does a single
> scan of the pool and if it does not find an idle connection it either throws
> AllConnectionsInUse or it creates one. The caller sets the onlyUseExistingCnx
> parameter based on if the pool is at max cnxs or not (seems like this should
> have been done in borrowConnection instead of the caller). If it throws
> AllConnectionsInUse the caller catches it and ignores it and then falls into
> doing a non-targeted borrow that will wait for a connection but to ANY
> server. So our single hop optimization goes away on a busy client. Since it
> can’t immediately get a connection to server A, it says just give me a
> connection to any server sends the op to that other server and that server
> ends up having to forward it to server A. You would only see this problem if
> you set a max on your client connection pool. The default of -1 just says to
> always create another connection. The only workaround I know of is to not
> limit how many connections your client can create but that could cause other
> problem (i.e. too many file descriptors).
> The questionable code is in the following classes:
> org.apache.geode.cache.client.internal.GetOp
> org.apache.geode.cache.client.internal.PutOp
> org.apache.geode.cache.client.internal.DestroyOp
> The all have something like this:
>
> {code:java}
> boolean onlyUseExistingCnx = ((poolImpl.getMaxConnections() != -1
> && poolImpl.getConnectionCount() >= poolImpl.getMaxConnections()) ? true :
> false);
> op.setAllowDuplicateMetadataRefresh(!onlyUseExistingCnx);
> return pool.executeOn(new ServerLocation(server.getHostName(),
> server.getPort()), op,
> true, onlyUseExistingCnx);
> {code}
> executeOn eventually calls ConnectionManagerImpl.borrowConnection
> It is unclear to me why they need allow duplicate metadata refresh if they
> permit borrowConnection to create a new connection to the specified server.
> They all catch and ignore
> AllConnectionsInUseException falling through and doing non-targetted
> pool.execute.
> The concern might have been that the pool would be full of connections to
> other servers preventing us from connecting to the server we need to
> communicate with. If we have existing connections to the server we could wait
> for one of those. If we don't and we are at max then we should consider
> closing a connection to some other server and create a connection to the
> server we know we need for this operation. As the server count goes up and
> the max connection count on the pool goes down I'm sure we are probably
> better off not even trying to do single hop since we might not even be able
> to have a connection to each server in the pool. But if we have a reasonable
> max connection count then it seems like we could make more of an effort to
> make sure a per server connection count is balanced and then wait for one of
> those connection to be available.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-6536) client pr single hop will do multiple hops if things get busy
[
https://issues.apache.org/jira/browse/GEODE-6536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17071234#comment-17071234
]
ASF subversion and git services commented on GEODE-6536:
Commit b021b127867d1e01e09fac26de10d29f896ed7dc in geode's branch
refs/heads/develop from Mario Ivanac
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=b021b12 ]
Feature/geode 6536 2: Added retry in borrowConnection/single hop (#4833)
* GEODE-6536: Added retry in borrowConnection/single hop
* GEODE-6536: bug fix
* GEODE-6536: update after comments
* GEODE-6536: modify borrowConnection singleHop solution
* GEODE-6536: test update
* GEODE-6536: updated tests, and added parameter to desable timeout
* GEODE-6536: update of cachexml impacts
* GEODE-6536: remove cachexml restriction
* GEODE-6536: update default value and documentation
* GEODE-6536_2: change exception type
* GEODE-6536_2: seize new connection only in case onlyUseExistingCnx=false
> client pr single hop will do multiple hops if things get busy
> -
>
> Key: GEODE-6536
> URL: https://issues.apache.org/jira/browse/GEODE-6536
> Project: Geode
> Issue Type: Improvement
> Components: client/server
>Reporter: Darrel Schneider
>Assignee: Mario Ivanac
>Priority: Major
> Labels: needs-review, performance, pull-request-available
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> I was wondering why ConnectionManagerImpl.borrowConnection that targets a
> particular server will not wait for a connection to be available. This is the
> borrow used by pr single hop. It seems like if all the cnxs to that server
> are busy and we are at max that it should wait. But instead it does a single
> scan of the pool and if it does not find an idle connection it either throws
> AllConnectionsInUse or it creates one. The caller sets the onlyUseExistingCnx
> parameter based on if the pool is at max cnxs or not (seems like this should
> have been done in borrowConnection instead of the caller). If it throws
> AllConnectionsInUse the caller catches it and ignores it and then falls into
> doing a non-targeted borrow that will wait for a connection but to ANY
> server. So our single hop optimization goes away on a busy client. Since it
> can’t immediately get a connection to server A, it says just give me a
> connection to any server sends the op to that other server and that server
> ends up having to forward it to server A. You would only see this problem if
> you set a max on your client connection pool. The default of -1 just says to
> always create another connection. The only workaround I know of is to not
> limit how many connections your client can create but that could cause other
> problem (i.e. too many file descriptors).
> The questionable code is in the following classes:
> org.apache.geode.cache.client.internal.GetOp
> org.apache.geode.cache.client.internal.PutOp
> org.apache.geode.cache.client.internal.DestroyOp
> The all have something like this:
>
> {code:java}
> boolean onlyUseExistingCnx = ((poolImpl.getMaxConnections() != -1
> && poolImpl.getConnectionCount() >= poolImpl.getMaxConnections()) ? true :
> false);
> op.setAllowDuplicateMetadataRefresh(!onlyUseExistingCnx);
> return pool.executeOn(new ServerLocation(server.getHostName(),
> server.getPort()), op,
> true, onlyUseExistingCnx);
> {code}
> executeOn eventually calls ConnectionManagerImpl.borrowConnection
> It is unclear to me why they need allow duplicate metadata refresh if they
> permit borrowConnection to create a new connection to the specified server.
> They all catch and ignore
> AllConnectionsInUseException falling through and doing non-targetted
> pool.execute.
> The concern might have been that the pool would be full of connections to
> other servers preventing us from connecting to the server we need to
> communicate with. If we have existing connections to the server we could wait
> for one of those. If we don't and we are at max then we should consider
> closing a connection to some other server and create a connection to the
> server we know we need for this operation. As the server count goes up and
> the max connection count on the pool goes down I'm sure we are probably
> better off not even trying to do single hop since we might not even be able
> to have a connection to each server in the pool. But if we have a reasonable
> max connection count then it seems like we could make more of an effort to
> make sure a per server connection count is balanced and then wait for one of
> those connection to be available.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-6536) client pr single hop will do multiple hops if things get busy
[
https://issues.apache.org/jira/browse/GEODE-6536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17071231#comment-17071231
]
ASF subversion and git services commented on GEODE-6536:
Commit b021b127867d1e01e09fac26de10d29f896ed7dc in geode's branch
refs/heads/develop from Mario Ivanac
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=b021b12 ]
Feature/geode 6536 2: Added retry in borrowConnection/single hop (#4833)
* GEODE-6536: Added retry in borrowConnection/single hop
* GEODE-6536: bug fix
* GEODE-6536: update after comments
* GEODE-6536: modify borrowConnection singleHop solution
* GEODE-6536: test update
* GEODE-6536: updated tests, and added parameter to desable timeout
* GEODE-6536: update of cachexml impacts
* GEODE-6536: remove cachexml restriction
* GEODE-6536: update default value and documentation
* GEODE-6536_2: change exception type
* GEODE-6536_2: seize new connection only in case onlyUseExistingCnx=false
> client pr single hop will do multiple hops if things get busy
> -
>
> Key: GEODE-6536
> URL: https://issues.apache.org/jira/browse/GEODE-6536
> Project: Geode
> Issue Type: Improvement
> Components: client/server
>Reporter: Darrel Schneider
>Assignee: Mario Ivanac
>Priority: Major
> Labels: needs-review, performance, pull-request-available
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> I was wondering why ConnectionManagerImpl.borrowConnection that targets a
> particular server will not wait for a connection to be available. This is the
> borrow used by pr single hop. It seems like if all the cnxs to that server
> are busy and we are at max that it should wait. But instead it does a single
> scan of the pool and if it does not find an idle connection it either throws
> AllConnectionsInUse or it creates one. The caller sets the onlyUseExistingCnx
> parameter based on if the pool is at max cnxs or not (seems like this should
> have been done in borrowConnection instead of the caller). If it throws
> AllConnectionsInUse the caller catches it and ignores it and then falls into
> doing a non-targeted borrow that will wait for a connection but to ANY
> server. So our single hop optimization goes away on a busy client. Since it
> can’t immediately get a connection to server A, it says just give me a
> connection to any server sends the op to that other server and that server
> ends up having to forward it to server A. You would only see this problem if
> you set a max on your client connection pool. The default of -1 just says to
> always create another connection. The only workaround I know of is to not
> limit how many connections your client can create but that could cause other
> problem (i.e. too many file descriptors).
> The questionable code is in the following classes:
> org.apache.geode.cache.client.internal.GetOp
> org.apache.geode.cache.client.internal.PutOp
> org.apache.geode.cache.client.internal.DestroyOp
> The all have something like this:
>
> {code:java}
> boolean onlyUseExistingCnx = ((poolImpl.getMaxConnections() != -1
> && poolImpl.getConnectionCount() >= poolImpl.getMaxConnections()) ? true :
> false);
> op.setAllowDuplicateMetadataRefresh(!onlyUseExistingCnx);
> return pool.executeOn(new ServerLocation(server.getHostName(),
> server.getPort()), op,
> true, onlyUseExistingCnx);
> {code}
> executeOn eventually calls ConnectionManagerImpl.borrowConnection
> It is unclear to me why they need allow duplicate metadata refresh if they
> permit borrowConnection to create a new connection to the specified server.
> They all catch and ignore
> AllConnectionsInUseException falling through and doing non-targetted
> pool.execute.
> The concern might have been that the pool would be full of connections to
> other servers preventing us from connecting to the server we need to
> communicate with. If we have existing connections to the server we could wait
> for one of those. If we don't and we are at max then we should consider
> closing a connection to some other server and create a connection to the
> server we know we need for this operation. As the server count goes up and
> the max connection count on the pool goes down I'm sure we are probably
> better off not even trying to do single hop since we might not even be able
> to have a connection to each server in the pool. But if we have a reasonable
> max connection count then it seems like we could make more of an effort to
> make sure a per server connection count is balanced and then wait for one of
> those connection to be available.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-6536) client pr single hop will do multiple hops if things get busy
[
https://issues.apache.org/jira/browse/GEODE-6536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17071232#comment-17071232
]
ASF subversion and git services commented on GEODE-6536:
Commit b021b127867d1e01e09fac26de10d29f896ed7dc in geode's branch
refs/heads/develop from Mario Ivanac
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=b021b12 ]
Feature/geode 6536 2: Added retry in borrowConnection/single hop (#4833)
* GEODE-6536: Added retry in borrowConnection/single hop
* GEODE-6536: bug fix
* GEODE-6536: update after comments
* GEODE-6536: modify borrowConnection singleHop solution
* GEODE-6536: test update
* GEODE-6536: updated tests, and added parameter to desable timeout
* GEODE-6536: update of cachexml impacts
* GEODE-6536: remove cachexml restriction
* GEODE-6536: update default value and documentation
* GEODE-6536_2: change exception type
* GEODE-6536_2: seize new connection only in case onlyUseExistingCnx=false
> client pr single hop will do multiple hops if things get busy
> -
>
> Key: GEODE-6536
> URL: https://issues.apache.org/jira/browse/GEODE-6536
> Project: Geode
> Issue Type: Improvement
> Components: client/server
>Reporter: Darrel Schneider
>Assignee: Mario Ivanac
>Priority: Major
> Labels: needs-review, performance, pull-request-available
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> I was wondering why ConnectionManagerImpl.borrowConnection that targets a
> particular server will not wait for a connection to be available. This is the
> borrow used by pr single hop. It seems like if all the cnxs to that server
> are busy and we are at max that it should wait. But instead it does a single
> scan of the pool and if it does not find an idle connection it either throws
> AllConnectionsInUse or it creates one. The caller sets the onlyUseExistingCnx
> parameter based on if the pool is at max cnxs or not (seems like this should
> have been done in borrowConnection instead of the caller). If it throws
> AllConnectionsInUse the caller catches it and ignores it and then falls into
> doing a non-targeted borrow that will wait for a connection but to ANY
> server. So our single hop optimization goes away on a busy client. Since it
> can’t immediately get a connection to server A, it says just give me a
> connection to any server sends the op to that other server and that server
> ends up having to forward it to server A. You would only see this problem if
> you set a max on your client connection pool. The default of -1 just says to
> always create another connection. The only workaround I know of is to not
> limit how many connections your client can create but that could cause other
> problem (i.e. too many file descriptors).
> The questionable code is in the following classes:
> org.apache.geode.cache.client.internal.GetOp
> org.apache.geode.cache.client.internal.PutOp
> org.apache.geode.cache.client.internal.DestroyOp
> The all have something like this:
>
> {code:java}
> boolean onlyUseExistingCnx = ((poolImpl.getMaxConnections() != -1
> && poolImpl.getConnectionCount() >= poolImpl.getMaxConnections()) ? true :
> false);
> op.setAllowDuplicateMetadataRefresh(!onlyUseExistingCnx);
> return pool.executeOn(new ServerLocation(server.getHostName(),
> server.getPort()), op,
> true, onlyUseExistingCnx);
> {code}
> executeOn eventually calls ConnectionManagerImpl.borrowConnection
> It is unclear to me why they need allow duplicate metadata refresh if they
> permit borrowConnection to create a new connection to the specified server.
> They all catch and ignore
> AllConnectionsInUseException falling through and doing non-targetted
> pool.execute.
> The concern might have been that the pool would be full of connections to
> other servers preventing us from connecting to the server we need to
> communicate with. If we have existing connections to the server we could wait
> for one of those. If we don't and we are at max then we should consider
> closing a connection to some other server and create a connection to the
> server we know we need for this operation. As the server count goes up and
> the max connection count on the pool goes down I'm sure we are probably
> better off not even trying to do single hop since we might not even be able
> to have a connection to each server in the pool. But if we have a reasonable
> max connection count then it seems like we could make more of an effort to
> make sure a per server connection count is balanced and then wait for one of
> those connection to be available.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-6536) client pr single hop will do multiple hops if things get busy
[
https://issues.apache.org/jira/browse/GEODE-6536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17071227#comment-17071227
]
ASF subversion and git services commented on GEODE-6536:
Commit b021b127867d1e01e09fac26de10d29f896ed7dc in geode's branch
refs/heads/develop from Mario Ivanac
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=b021b12 ]
Feature/geode 6536 2: Added retry in borrowConnection/single hop (#4833)
* GEODE-6536: Added retry in borrowConnection/single hop
* GEODE-6536: bug fix
* GEODE-6536: update after comments
* GEODE-6536: modify borrowConnection singleHop solution
* GEODE-6536: test update
* GEODE-6536: updated tests, and added parameter to desable timeout
* GEODE-6536: update of cachexml impacts
* GEODE-6536: remove cachexml restriction
* GEODE-6536: update default value and documentation
* GEODE-6536_2: change exception type
* GEODE-6536_2: seize new connection only in case onlyUseExistingCnx=false
> client pr single hop will do multiple hops if things get busy
> -
>
> Key: GEODE-6536
> URL: https://issues.apache.org/jira/browse/GEODE-6536
> Project: Geode
> Issue Type: Improvement
> Components: client/server
>Reporter: Darrel Schneider
>Assignee: Mario Ivanac
>Priority: Major
> Labels: needs-review, performance, pull-request-available
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> I was wondering why ConnectionManagerImpl.borrowConnection that targets a
> particular server will not wait for a connection to be available. This is the
> borrow used by pr single hop. It seems like if all the cnxs to that server
> are busy and we are at max that it should wait. But instead it does a single
> scan of the pool and if it does not find an idle connection it either throws
> AllConnectionsInUse or it creates one. The caller sets the onlyUseExistingCnx
> parameter based on if the pool is at max cnxs or not (seems like this should
> have been done in borrowConnection instead of the caller). If it throws
> AllConnectionsInUse the caller catches it and ignores it and then falls into
> doing a non-targeted borrow that will wait for a connection but to ANY
> server. So our single hop optimization goes away on a busy client. Since it
> can’t immediately get a connection to server A, it says just give me a
> connection to any server sends the op to that other server and that server
> ends up having to forward it to server A. You would only see this problem if
> you set a max on your client connection pool. The default of -1 just says to
> always create another connection. The only workaround I know of is to not
> limit how many connections your client can create but that could cause other
> problem (i.e. too many file descriptors).
> The questionable code is in the following classes:
> org.apache.geode.cache.client.internal.GetOp
> org.apache.geode.cache.client.internal.PutOp
> org.apache.geode.cache.client.internal.DestroyOp
> The all have something like this:
>
> {code:java}
> boolean onlyUseExistingCnx = ((poolImpl.getMaxConnections() != -1
> && poolImpl.getConnectionCount() >= poolImpl.getMaxConnections()) ? true :
> false);
> op.setAllowDuplicateMetadataRefresh(!onlyUseExistingCnx);
> return pool.executeOn(new ServerLocation(server.getHostName(),
> server.getPort()), op,
> true, onlyUseExistingCnx);
> {code}
> executeOn eventually calls ConnectionManagerImpl.borrowConnection
> It is unclear to me why they need allow duplicate metadata refresh if they
> permit borrowConnection to create a new connection to the specified server.
> They all catch and ignore
> AllConnectionsInUseException falling through and doing non-targetted
> pool.execute.
> The concern might have been that the pool would be full of connections to
> other servers preventing us from connecting to the server we need to
> communicate with. If we have existing connections to the server we could wait
> for one of those. If we don't and we are at max then we should consider
> closing a connection to some other server and create a connection to the
> server we know we need for this operation. As the server count goes up and
> the max connection count on the pool goes down I'm sure we are probably
> better off not even trying to do single hop since we might not even be able
> to have a connection to each server in the pool. But if we have a reasonable
> max connection count then it seems like we could make more of an effort to
> make sure a per server connection count is balanced and then wait for one of
> those connection to be available.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-6536) client pr single hop will do multiple hops if things get busy
[
https://issues.apache.org/jira/browse/GEODE-6536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17071233#comment-17071233
]
ASF subversion and git services commented on GEODE-6536:
Commit b021b127867d1e01e09fac26de10d29f896ed7dc in geode's branch
refs/heads/develop from Mario Ivanac
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=b021b12 ]
Feature/geode 6536 2: Added retry in borrowConnection/single hop (#4833)
* GEODE-6536: Added retry in borrowConnection/single hop
* GEODE-6536: bug fix
* GEODE-6536: update after comments
* GEODE-6536: modify borrowConnection singleHop solution
* GEODE-6536: test update
* GEODE-6536: updated tests, and added parameter to desable timeout
* GEODE-6536: update of cachexml impacts
* GEODE-6536: remove cachexml restriction
* GEODE-6536: update default value and documentation
* GEODE-6536_2: change exception type
* GEODE-6536_2: seize new connection only in case onlyUseExistingCnx=false
> client pr single hop will do multiple hops if things get busy
> -
>
> Key: GEODE-6536
> URL: https://issues.apache.org/jira/browse/GEODE-6536
> Project: Geode
> Issue Type: Improvement
> Components: client/server
>Reporter: Darrel Schneider
>Assignee: Mario Ivanac
>Priority: Major
> Labels: needs-review, performance, pull-request-available
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> I was wondering why ConnectionManagerImpl.borrowConnection that targets a
> particular server will not wait for a connection to be available. This is the
> borrow used by pr single hop. It seems like if all the cnxs to that server
> are busy and we are at max that it should wait. But instead it does a single
> scan of the pool and if it does not find an idle connection it either throws
> AllConnectionsInUse or it creates one. The caller sets the onlyUseExistingCnx
> parameter based on if the pool is at max cnxs or not (seems like this should
> have been done in borrowConnection instead of the caller). If it throws
> AllConnectionsInUse the caller catches it and ignores it and then falls into
> doing a non-targeted borrow that will wait for a connection but to ANY
> server. So our single hop optimization goes away on a busy client. Since it
> can’t immediately get a connection to server A, it says just give me a
> connection to any server sends the op to that other server and that server
> ends up having to forward it to server A. You would only see this problem if
> you set a max on your client connection pool. The default of -1 just says to
> always create another connection. The only workaround I know of is to not
> limit how many connections your client can create but that could cause other
> problem (i.e. too many file descriptors).
> The questionable code is in the following classes:
> org.apache.geode.cache.client.internal.GetOp
> org.apache.geode.cache.client.internal.PutOp
> org.apache.geode.cache.client.internal.DestroyOp
> The all have something like this:
>
> {code:java}
> boolean onlyUseExistingCnx = ((poolImpl.getMaxConnections() != -1
> && poolImpl.getConnectionCount() >= poolImpl.getMaxConnections()) ? true :
> false);
> op.setAllowDuplicateMetadataRefresh(!onlyUseExistingCnx);
> return pool.executeOn(new ServerLocation(server.getHostName(),
> server.getPort()), op,
> true, onlyUseExistingCnx);
> {code}
> executeOn eventually calls ConnectionManagerImpl.borrowConnection
> It is unclear to me why they need allow duplicate metadata refresh if they
> permit borrowConnection to create a new connection to the specified server.
> They all catch and ignore
> AllConnectionsInUseException falling through and doing non-targetted
> pool.execute.
> The concern might have been that the pool would be full of connections to
> other servers preventing us from connecting to the server we need to
> communicate with. If we have existing connections to the server we could wait
> for one of those. If we don't and we are at max then we should consider
> closing a connection to some other server and create a connection to the
> server we know we need for this operation. As the server count goes up and
> the max connection count on the pool goes down I'm sure we are probably
> better off not even trying to do single hop since we might not even be able
> to have a connection to each server in the pool. But if we have a reasonable
> max connection count then it seems like we could make more of an effort to
> make sure a per server connection count is balanced and then wait for one of
> those connection to be available.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-6536) client pr single hop will do multiple hops if things get busy
[
https://issues.apache.org/jira/browse/GEODE-6536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17071228#comment-17071228
]
ASF subversion and git services commented on GEODE-6536:
Commit b021b127867d1e01e09fac26de10d29f896ed7dc in geode's branch
refs/heads/develop from Mario Ivanac
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=b021b12 ]
Feature/geode 6536 2: Added retry in borrowConnection/single hop (#4833)
* GEODE-6536: Added retry in borrowConnection/single hop
* GEODE-6536: bug fix
* GEODE-6536: update after comments
* GEODE-6536: modify borrowConnection singleHop solution
* GEODE-6536: test update
* GEODE-6536: updated tests, and added parameter to desable timeout
* GEODE-6536: update of cachexml impacts
* GEODE-6536: remove cachexml restriction
* GEODE-6536: update default value and documentation
* GEODE-6536_2: change exception type
* GEODE-6536_2: seize new connection only in case onlyUseExistingCnx=false
> client pr single hop will do multiple hops if things get busy
> -
>
> Key: GEODE-6536
> URL: https://issues.apache.org/jira/browse/GEODE-6536
> Project: Geode
> Issue Type: Improvement
> Components: client/server
>Reporter: Darrel Schneider
>Assignee: Mario Ivanac
>Priority: Major
> Labels: needs-review, performance, pull-request-available
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> I was wondering why ConnectionManagerImpl.borrowConnection that targets a
> particular server will not wait for a connection to be available. This is the
> borrow used by pr single hop. It seems like if all the cnxs to that server
> are busy and we are at max that it should wait. But instead it does a single
> scan of the pool and if it does not find an idle connection it either throws
> AllConnectionsInUse or it creates one. The caller sets the onlyUseExistingCnx
> parameter based on if the pool is at max cnxs or not (seems like this should
> have been done in borrowConnection instead of the caller). If it throws
> AllConnectionsInUse the caller catches it and ignores it and then falls into
> doing a non-targeted borrow that will wait for a connection but to ANY
> server. So our single hop optimization goes away on a busy client. Since it
> can’t immediately get a connection to server A, it says just give me a
> connection to any server sends the op to that other server and that server
> ends up having to forward it to server A. You would only see this problem if
> you set a max on your client connection pool. The default of -1 just says to
> always create another connection. The only workaround I know of is to not
> limit how many connections your client can create but that could cause other
> problem (i.e. too many file descriptors).
> The questionable code is in the following classes:
> org.apache.geode.cache.client.internal.GetOp
> org.apache.geode.cache.client.internal.PutOp
> org.apache.geode.cache.client.internal.DestroyOp
> The all have something like this:
>
> {code:java}
> boolean onlyUseExistingCnx = ((poolImpl.getMaxConnections() != -1
> && poolImpl.getConnectionCount() >= poolImpl.getMaxConnections()) ? true :
> false);
> op.setAllowDuplicateMetadataRefresh(!onlyUseExistingCnx);
> return pool.executeOn(new ServerLocation(server.getHostName(),
> server.getPort()), op,
> true, onlyUseExistingCnx);
> {code}
> executeOn eventually calls ConnectionManagerImpl.borrowConnection
> It is unclear to me why they need allow duplicate metadata refresh if they
> permit borrowConnection to create a new connection to the specified server.
> They all catch and ignore
> AllConnectionsInUseException falling through and doing non-targetted
> pool.execute.
> The concern might have been that the pool would be full of connections to
> other servers preventing us from connecting to the server we need to
> communicate with. If we have existing connections to the server we could wait
> for one of those. If we don't and we are at max then we should consider
> closing a connection to some other server and create a connection to the
> server we know we need for this operation. As the server count goes up and
> the max connection count on the pool goes down I'm sure we are probably
> better off not even trying to do single hop since we might not even be able
> to have a connection to each server in the pool. But if we have a reasonable
> max connection count then it seems like we could make more of an effort to
> make sure a per server connection count is balanced and then wait for one of
> those connection to be available.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-6536) client pr single hop will do multiple hops if things get busy
[
https://issues.apache.org/jira/browse/GEODE-6536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17071230#comment-17071230
]
ASF subversion and git services commented on GEODE-6536:
Commit b021b127867d1e01e09fac26de10d29f896ed7dc in geode's branch
refs/heads/develop from Mario Ivanac
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=b021b12 ]
Feature/geode 6536 2: Added retry in borrowConnection/single hop (#4833)
* GEODE-6536: Added retry in borrowConnection/single hop
* GEODE-6536: bug fix
* GEODE-6536: update after comments
* GEODE-6536: modify borrowConnection singleHop solution
* GEODE-6536: test update
* GEODE-6536: updated tests, and added parameter to desable timeout
* GEODE-6536: update of cachexml impacts
* GEODE-6536: remove cachexml restriction
* GEODE-6536: update default value and documentation
* GEODE-6536_2: change exception type
* GEODE-6536_2: seize new connection only in case onlyUseExistingCnx=false
> client pr single hop will do multiple hops if things get busy
> -
>
> Key: GEODE-6536
> URL: https://issues.apache.org/jira/browse/GEODE-6536
> Project: Geode
> Issue Type: Improvement
> Components: client/server
>Reporter: Darrel Schneider
>Assignee: Mario Ivanac
>Priority: Major
> Labels: needs-review, performance, pull-request-available
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> I was wondering why ConnectionManagerImpl.borrowConnection that targets a
> particular server will not wait for a connection to be available. This is the
> borrow used by pr single hop. It seems like if all the cnxs to that server
> are busy and we are at max that it should wait. But instead it does a single
> scan of the pool and if it does not find an idle connection it either throws
> AllConnectionsInUse or it creates one. The caller sets the onlyUseExistingCnx
> parameter based on if the pool is at max cnxs or not (seems like this should
> have been done in borrowConnection instead of the caller). If it throws
> AllConnectionsInUse the caller catches it and ignores it and then falls into
> doing a non-targeted borrow that will wait for a connection but to ANY
> server. So our single hop optimization goes away on a busy client. Since it
> can’t immediately get a connection to server A, it says just give me a
> connection to any server sends the op to that other server and that server
> ends up having to forward it to server A. You would only see this problem if
> you set a max on your client connection pool. The default of -1 just says to
> always create another connection. The only workaround I know of is to not
> limit how many connections your client can create but that could cause other
> problem (i.e. too many file descriptors).
> The questionable code is in the following classes:
> org.apache.geode.cache.client.internal.GetOp
> org.apache.geode.cache.client.internal.PutOp
> org.apache.geode.cache.client.internal.DestroyOp
> The all have something like this:
>
> {code:java}
> boolean onlyUseExistingCnx = ((poolImpl.getMaxConnections() != -1
> && poolImpl.getConnectionCount() >= poolImpl.getMaxConnections()) ? true :
> false);
> op.setAllowDuplicateMetadataRefresh(!onlyUseExistingCnx);
> return pool.executeOn(new ServerLocation(server.getHostName(),
> server.getPort()), op,
> true, onlyUseExistingCnx);
> {code}
> executeOn eventually calls ConnectionManagerImpl.borrowConnection
> It is unclear to me why they need allow duplicate metadata refresh if they
> permit borrowConnection to create a new connection to the specified server.
> They all catch and ignore
> AllConnectionsInUseException falling through and doing non-targetted
> pool.execute.
> The concern might have been that the pool would be full of connections to
> other servers preventing us from connecting to the server we need to
> communicate with. If we have existing connections to the server we could wait
> for one of those. If we don't and we are at max then we should consider
> closing a connection to some other server and create a connection to the
> server we know we need for this operation. As the server count goes up and
> the max connection count on the pool goes down I'm sure we are probably
> better off not even trying to do single hop since we might not even be able
> to have a connection to each server in the pool. But if we have a reasonable
> max connection count then it seems like we could make more of an effort to
> make sure a per server connection count is balanced and then wait for one of
> those connection to be available.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-6536) client pr single hop will do multiple hops if things get busy
[
https://issues.apache.org/jira/browse/GEODE-6536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17071237#comment-17071237
]
ASF subversion and git services commented on GEODE-6536:
Commit b021b127867d1e01e09fac26de10d29f896ed7dc in geode's branch
refs/heads/develop from Mario Ivanac
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=b021b12 ]
Feature/geode 6536 2: Added retry in borrowConnection/single hop (#4833)
* GEODE-6536: Added retry in borrowConnection/single hop
* GEODE-6536: bug fix
* GEODE-6536: update after comments
* GEODE-6536: modify borrowConnection singleHop solution
* GEODE-6536: test update
* GEODE-6536: updated tests, and added parameter to desable timeout
* GEODE-6536: update of cachexml impacts
* GEODE-6536: remove cachexml restriction
* GEODE-6536: update default value and documentation
* GEODE-6536_2: change exception type
* GEODE-6536_2: seize new connection only in case onlyUseExistingCnx=false
> client pr single hop will do multiple hops if things get busy
> -
>
> Key: GEODE-6536
> URL: https://issues.apache.org/jira/browse/GEODE-6536
> Project: Geode
> Issue Type: Improvement
> Components: client/server
>Reporter: Darrel Schneider
>Assignee: Mario Ivanac
>Priority: Major
> Labels: needs-review, performance, pull-request-available
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> I was wondering why ConnectionManagerImpl.borrowConnection that targets a
> particular server will not wait for a connection to be available. This is the
> borrow used by pr single hop. It seems like if all the cnxs to that server
> are busy and we are at max that it should wait. But instead it does a single
> scan of the pool and if it does not find an idle connection it either throws
> AllConnectionsInUse or it creates one. The caller sets the onlyUseExistingCnx
> parameter based on if the pool is at max cnxs or not (seems like this should
> have been done in borrowConnection instead of the caller). If it throws
> AllConnectionsInUse the caller catches it and ignores it and then falls into
> doing a non-targeted borrow that will wait for a connection but to ANY
> server. So our single hop optimization goes away on a busy client. Since it
> can’t immediately get a connection to server A, it says just give me a
> connection to any server sends the op to that other server and that server
> ends up having to forward it to server A. You would only see this problem if
> you set a max on your client connection pool. The default of -1 just says to
> always create another connection. The only workaround I know of is to not
> limit how many connections your client can create but that could cause other
> problem (i.e. too many file descriptors).
> The questionable code is in the following classes:
> org.apache.geode.cache.client.internal.GetOp
> org.apache.geode.cache.client.internal.PutOp
> org.apache.geode.cache.client.internal.DestroyOp
> The all have something like this:
>
> {code:java}
> boolean onlyUseExistingCnx = ((poolImpl.getMaxConnections() != -1
> && poolImpl.getConnectionCount() >= poolImpl.getMaxConnections()) ? true :
> false);
> op.setAllowDuplicateMetadataRefresh(!onlyUseExistingCnx);
> return pool.executeOn(new ServerLocation(server.getHostName(),
> server.getPort()), op,
> true, onlyUseExistingCnx);
> {code}
> executeOn eventually calls ConnectionManagerImpl.borrowConnection
> It is unclear to me why they need allow duplicate metadata refresh if they
> permit borrowConnection to create a new connection to the specified server.
> They all catch and ignore
> AllConnectionsInUseException falling through and doing non-targetted
> pool.execute.
> The concern might have been that the pool would be full of connections to
> other servers preventing us from connecting to the server we need to
> communicate with. If we have existing connections to the server we could wait
> for one of those. If we don't and we are at max then we should consider
> closing a connection to some other server and create a connection to the
> server we know we need for this operation. As the server count goes up and
> the max connection count on the pool goes down I'm sure we are probably
> better off not even trying to do single hop since we might not even be able
> to have a connection to each server in the pool. But if we have a reasonable
> max connection count then it seems like we could make more of an effort to
> make sure a per server connection count is balanced and then wait for one of
> those connection to be available.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-6536) client pr single hop will do multiple hops if things get busy
[
https://issues.apache.org/jira/browse/GEODE-6536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17071229#comment-17071229
]
ASF subversion and git services commented on GEODE-6536:
Commit b021b127867d1e01e09fac26de10d29f896ed7dc in geode's branch
refs/heads/develop from Mario Ivanac
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=b021b12 ]
Feature/geode 6536 2: Added retry in borrowConnection/single hop (#4833)
* GEODE-6536: Added retry in borrowConnection/single hop
* GEODE-6536: bug fix
* GEODE-6536: update after comments
* GEODE-6536: modify borrowConnection singleHop solution
* GEODE-6536: test update
* GEODE-6536: updated tests, and added parameter to desable timeout
* GEODE-6536: update of cachexml impacts
* GEODE-6536: remove cachexml restriction
* GEODE-6536: update default value and documentation
* GEODE-6536_2: change exception type
* GEODE-6536_2: seize new connection only in case onlyUseExistingCnx=false
> client pr single hop will do multiple hops if things get busy
> -
>
> Key: GEODE-6536
> URL: https://issues.apache.org/jira/browse/GEODE-6536
> Project: Geode
> Issue Type: Improvement
> Components: client/server
>Reporter: Darrel Schneider
>Assignee: Mario Ivanac
>Priority: Major
> Labels: needs-review, performance, pull-request-available
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> I was wondering why ConnectionManagerImpl.borrowConnection that targets a
> particular server will not wait for a connection to be available. This is the
> borrow used by pr single hop. It seems like if all the cnxs to that server
> are busy and we are at max that it should wait. But instead it does a single
> scan of the pool and if it does not find an idle connection it either throws
> AllConnectionsInUse or it creates one. The caller sets the onlyUseExistingCnx
> parameter based on if the pool is at max cnxs or not (seems like this should
> have been done in borrowConnection instead of the caller). If it throws
> AllConnectionsInUse the caller catches it and ignores it and then falls into
> doing a non-targeted borrow that will wait for a connection but to ANY
> server. So our single hop optimization goes away on a busy client. Since it
> can’t immediately get a connection to server A, it says just give me a
> connection to any server sends the op to that other server and that server
> ends up having to forward it to server A. You would only see this problem if
> you set a max on your client connection pool. The default of -1 just says to
> always create another connection. The only workaround I know of is to not
> limit how many connections your client can create but that could cause other
> problem (i.e. too many file descriptors).
> The questionable code is in the following classes:
> org.apache.geode.cache.client.internal.GetOp
> org.apache.geode.cache.client.internal.PutOp
> org.apache.geode.cache.client.internal.DestroyOp
> The all have something like this:
>
> {code:java}
> boolean onlyUseExistingCnx = ((poolImpl.getMaxConnections() != -1
> && poolImpl.getConnectionCount() >= poolImpl.getMaxConnections()) ? true :
> false);
> op.setAllowDuplicateMetadataRefresh(!onlyUseExistingCnx);
> return pool.executeOn(new ServerLocation(server.getHostName(),
> server.getPort()), op,
> true, onlyUseExistingCnx);
> {code}
> executeOn eventually calls ConnectionManagerImpl.borrowConnection
> It is unclear to me why they need allow duplicate metadata refresh if they
> permit borrowConnection to create a new connection to the specified server.
> They all catch and ignore
> AllConnectionsInUseException falling through and doing non-targetted
> pool.execute.
> The concern might have been that the pool would be full of connections to
> other servers preventing us from connecting to the server we need to
> communicate with. If we have existing connections to the server we could wait
> for one of those. If we don't and we are at max then we should consider
> closing a connection to some other server and create a connection to the
> server we know we need for this operation. As the server count goes up and
> the max connection count on the pool goes down I'm sure we are probably
> better off not even trying to do single hop since we might not even be able
> to have a connection to each server in the pool. But if we have a reasonable
> max connection count then it seems like we could make more of an effort to
> make sure a per server connection count is balanced and then wait for one of
> those connection to be available.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-7926) GMSMemberData is doing unnecessary reverse-DNS lookups
Bruce J Schuchardt created GEODE-7926: - Summary: GMSMemberData is doing unnecessary reverse-DNS lookups Key: GEODE-7926 URL: https://issues.apache.org/jira/browse/GEODE-7926 Project: Geode Issue Type: Bug Components: membership, messaging Reporter: Bruce J Schuchardt When we send a message via JGroups we write a serialized GMSMemberData in the header of the message. When this is deserialized we are currently using InetAddress.getHostName() to establish a hostname for the new instance. This is costly and unnecessary. We should just use getHostAddress() if we need a hostname in the address data. Geode's InternalDistributedMember doesn't rely on GMSMemberData to establish hostnames for geode-core and other downstream modules. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-7926) GMSMemberData is doing unnecessary reverse-DNS lookups
[ https://issues.apache.org/jira/browse/GEODE-7926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruce J Schuchardt reassigned GEODE-7926: - Assignee: Bruce J Schuchardt > GMSMemberData is doing unnecessary reverse-DNS lookups > -- > > Key: GEODE-7926 > URL: https://issues.apache.org/jira/browse/GEODE-7926 > Project: Geode > Issue Type: Bug > Components: membership, messaging >Reporter: Bruce J Schuchardt >Assignee: Bruce J Schuchardt >Priority: Major > > When we send a message via JGroups we write a serialized GMSMemberData in the > header of the message. When this is deserialized we are currently using > InetAddress.getHostName() to establish a hostname for the new instance. This > is costly and unnecessary. We should just use getHostAddress() if we need a > hostname in the address data. Geode's InternalDistributedMember doesn't rely > on GMSMemberData to establish hostnames for geode-core and other downstream > modules. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7927) create tests to ensure feature-parity with Redis PEXPIRE command
John Hutchison created GEODE-7927: - Summary: create tests to ensure feature-parity with Redis PEXPIRE command Key: GEODE-7927 URL: https://issues.apache.org/jira/browse/GEODE-7927 Project: Geode Issue Type: Test Reporter: John Hutchison -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-7920) Geode UDP INT thread found processing cache operations
[
https://issues.apache.org/jira/browse/GEODE-7920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce J Schuchardt reassigned GEODE-7920:
-
Assignee: Bruce J Schuchardt
> Geode UDP INT thread found processing cache operations
> --
>
> Key: GEODE-7920
> URL: https://issues.apache.org/jira/browse/GEODE-7920
> Project: Geode
> Issue Type: Improvement
> Components: membership, messaging
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
>
> While looking into another problem in a test run with disable-tcp=true I
> found this JGroups thread processing a cache operation in-line. These
> threads should never process cache ops. They exist just to read messages and
> hand them off to an Executor.
> Fixing this should improve UDP messaging performance somewhat.
> {noformat}
> "Geode UDP INT-2,rs-Awesome-781-1145-1a0i32xlarge-hydra-client-4-27004" #54
> daemon prio=5 os_prio=0 tid=0x7f202c05b800 nid=0x778d runnable
> [0x7f20b0bb6000]
>java.lang.Thread.State: RUNNABLE
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
> at java.net.SocketInputStream.read(SocketInputStream.java:171)
> at java.net.SocketInputStream.read(SocketInputStream.java:141)
> at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:265)
> - locked <0xc292f560> (a java.io.BufferedInputStream)
> at java.io.DataInputStream.readByte(DataInputStream.java:265)
> at
> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:240)
> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:163)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:235)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:180)
> at com.sun.proxy.$Proxy53.increment(Unknown Source)
> at
> hydra.blackboard.AnySharedCountersImpl.increment(AnySharedCountersImpl.java:159)
> at
> util.AbstractListener.incrementAfterDestroyCounters(AbstractListener.java:450)
> at event.ETListener.afterDestroy(ETListener.java:88)
> at
> org.apache.geode.internal.cache.EnumListenerEvent$AFTER_DESTROY.dispatchEvent(EnumListenerEvent.java:178)
> at
> org.apache.geode.internal.cache.LocalRegion.dispatchEvent(LocalRegion.java:8242)
> at
> org.apache.geode.internal.cache.LocalRegion.dispatchListenerEvent(LocalRegion.java:6952)
> at
> org.apache.geode.internal.cache.LocalRegion.invokeDestroyCallbacks(LocalRegion.java:6760)
> at
> org.apache.geode.internal.cache.EntryEventImpl.invokeCallbacks(EntryEventImpl.java:2443)
> at
> org.apache.geode.internal.cache.entries.AbstractRegionEntry.dispatchListenerEvents(AbstractRegionEntry.java:164)
> at
> org.apache.geode.internal.cache.LocalRegion.basicDestroyPart2(LocalRegion.java:6701)
> at
> org.apache.geode.internal.cache.map.RegionMapDestroy.removeEntryOrLeaveTombstone(RegionMapDestroy.java:509)
> at
> org.apache.geode.internal.cache.map.RegionMapDestroy.retryRemoveWithTombstone(RegionMapDestroy.java:373)
> - locked <0xfe71d6e0> (a
> org.apache.geode.internal.cache.entries.VersionedStatsRegionEntryOffHeapStringKey2)
> at
> org.apache.geode.internal.cache.map.RegionMapDestroy.checkTombstoneAndConcurrency(RegionMapDestroy.java:202)
> at
> org.apache.geode.internal.cache.map.RegionMapDestroy.destroy(RegionMapDestroy.java:147)
> at
> org.apache.geode.internal.cache.AbstractRegionMap.destroy(AbstractRegionMap.java:980)
> at
> org.apache.geode.internal.cache.LocalRegion.mapDestroy(LocalRegion.java:6490)
> at
> org.apache.geode.internal.cache.LocalRegion.mapDestroy(LocalRegion.java:6464)
> at
> org.apache.geode.internal.cache.LocalRegionDataView.destroyExistingEntry(LocalRegionDataView.java:58)
> at
> org.apache.geode.internal.cache.LocalRegion.basicDestroy(LocalRegion.java:6415)
> at
> org.apache.geode.internal.cache.DistributedRegion.basicDestroy(DistributedRegion.java:1720)
> at
> org.apache.geode.internal.cache.DestroyOperation$DestroyMessage.operateOnRegion(DestroyOperation.java:88)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation$CacheOperationMessage.basicProcess(DistributedCacheOperation.java:1208)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation$CacheOperationMessage.process(DistributedCacheOperation.java:1110)
> at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
> at
> org.apache.geod
[jira] [Created] (GEODE-7928) Prefix all C bindings with the moral equivalent of a namespace
Matthew Reddington created GEODE-7928:
-
Summary: Prefix all C bindings with the moral equivalent of a
namespace
Key: GEODE-7928
URL: https://issues.apache.org/jira/browse/GEODE-7928
Project: Geode
Issue Type: Improvement
Components: native client
Reporter: Matthew Reddington
h3. Why
These need to be clearly demarcated from user code. We will use a common
prefix, e.g. MyCBindingMethod becomes geode_MyCBindingMethod.
*As a .net core extension developer*
*I want to be able to clearly distinguish a .net call from a p/Invoke into a
library*
*So that I don't get confused*
h3. Acceptance Criteria
dumping exports via {{link /dump /exports}} or {{otool -L}} and grepping for
the geode___ prefix gives the full list of C bindings used by our .net core
code.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Reopened] (GEODE-5564) Flaky tes ConcurrentIndexInitOnOverflowRegionDUnitTest > testIndexUpdateWithRegionClea
[
https://issues.apache.org/jira/browse/GEODE-5564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery reopened GEODE-5564:
---
New failure in CI.
> Flaky tes ConcurrentIndexInitOnOverflowRegionDUnitTest >
> testIndexUpdateWithRegionClea
> --
>
> Key: GEODE-5564
> URL: https://issues.apache.org/jira/browse/GEODE-5564
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.8.0
>Reporter: Jacob Barrett
>Priority: Major
> Labels: flaky
>
> {noformat}
> org.apache.geode.cache.query.internal.index.ConcurrentIndexInitOnOverflowRegionDUnitTest
> > testIndexUpdateWithRegionClear FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.query.internal.index.ConcurrentIndexInitOnOverflowRegionDUnitTest$12.run
> in VM 0 running on Host 92f89c21d1b0 with 4 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:443)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:412)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:355)
> at
> org.apache.geode.cache.query.internal.index.ConcurrentIndexInitOnOverflowRegionDUnitTest.testIndexUpdateWithRegionClear(ConcurrentIndexInitOnOverflowRegionDUnitTest.java:411)
> Caused by:
> java.lang.AssertionError: After clear region size is supposed to be
> zero as all index updates are blocked. Current region size is: 13
> at org.junit.Assert.fail(Assert.java:88)
> at
> org.apache.geode.cache.query.internal.index.ConcurrentIndexInitOnOverflowRegionDUnitTest$12.run2(ConcurrentIndexInitOnOverflowRegionDUnitTest.java:430)
> {noformat}
> Failing:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/pr-develop/jobs/DistributedTest/builds/556
> Passing:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/pr-develop/jobs/DistributedTest/builds/547
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-5564) Flaky tes ConcurrentIndexInitOnOverflowRegionDUnitTest > testIndexUpdateWithRegionClea
[
https://issues.apache.org/jira/browse/GEODE-5564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17071301#comment-17071301
]
Dale Emery commented on GEODE-5564:
---
New failure in CI:
[https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/1694]
Test results:
[http://files.apachegeode-ci.info/builds/apache-develop-main/1.13.0-SNAPSHOT.0132/test-results/distributedTest/1585601043/]
Stack trace:
{noformat}
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.cache.query.internal.index.ConcurrentIndexInitOnOverflowRegionDUnitTest$12.run
in VM 0 running on Host b2f5328d0258 with 4 VMs
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
at
org.apache.geode.cache.query.internal.index.ConcurrentIndexInitOnOverflowRegionDUnitTest.testIndexUpdateWithRegionClear(ConcurrentIndexInitOnOverflowRegionDUnitTest.java:411)
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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
at
org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
at
org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
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.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at
org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
at
org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
at
org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:118)
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.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at
org.gradle.internal.rem
[jira] [Resolved] (GEODE-7928) Prefix all C bindings with the moral equivalent of a namespace
[
https://issues.apache.org/jira/browse/GEODE-7928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthew Reddington resolved GEODE-7928.
---
Resolution: Invalid
This is a prototype branch and doesn't reflect work merging into mainline.
> Prefix all C bindings with the moral equivalent of a namespace
> --
>
> Key: GEODE-7928
> URL: https://issues.apache.org/jira/browse/GEODE-7928
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Matthew Reddington
>Priority: Major
>
> h3. Why
> These need to be clearly demarcated from user code. We will use a common
> prefix, e.g. MyCBindingMethod becomes geode_MyCBindingMethod.
> *As a .net core extension developer*
> *I want to be able to clearly distinguish a .net call from a p/Invoke into a
> library*
> *So that I don't get confused*
> h3. Acceptance Criteria
> dumping exports via {{link /dump /exports}} or {{otool -L}} and grepping for
> the geode___ prefix gives the full list of C bindings used by our .net core
> code.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7864) Code improvement refactoring
[ https://issues.apache.org/jira/browse/GEODE-7864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17071311#comment-17071311 ] ASF subversion and git services commented on GEODE-7864: Commit 6df49deafc912f0a302f75da3d11d313faa31527 in geode's branch refs/heads/develop from Nabarun Nag [ https://gitbox.apache.org/repos/asf?p=geode.git;h=6df49de ] GEODE-7864: Prevent overflow during multiplication. (#4876) > Code improvement refactoring > > > Key: GEODE-7864 > URL: https://issues.apache.org/jira/browse/GEODE-7864 > Project: Geode > Issue Type: Improvement >Reporter: Nabarun Nag >Priority: Major > Time Spent: 9h 50m > Remaining Estimate: 0h > > This is a placeholder ticket. > * this is used to do refactoring. > * this ticket number is used to number the commit message. > * this ticket will never be closed. > * it will be used to mark improvements like correcting spelling mistakes, > efficient java code, etc. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-7711) gfsh command over http failed when command has url encoded patterns in it.
[ https://issues.apache.org/jira/browse/GEODE-7711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt closed GEODE-7711. --- Assignee: Ernest Burghardt > gfsh command over http failed when command has url encoded patterns in it. > -- > > Key: GEODE-7711 > URL: https://issues.apache.org/jira/browse/GEODE-7711 > Project: Geode > Issue Type: Bug > Components: gfsh >Affects Versions: 1.11.0 >Reporter: Jinmei Liao >Assignee: Ernest Burghardt >Priority: Major > Fix For: 1.12.0 > > Time Spent: 40m > Remaining Estimate: 0h > > when using gfsh connect over http, the following command would fail: > create async-event-queue --id=myAEQ --listener=myApp.myListener > --listener-param=db_url#host,username#db_user,password#abdfg012%dgadf > The issue is related to % in the password. Removing % from password solved > the issue. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-7466) HARegionQueueTest queuePutElidesSequenceIdLowerThanOrEqualToLastSeenSequenceId can throw a NullPointerException if the CacheClientNotifier instance is set
[
https://issues.apache.org/jira/browse/GEODE-7466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ernest Burghardt closed GEODE-7466.
---
Assignee: Ernest Burghardt
> HARegionQueueTest
> queuePutElidesSequenceIdLowerThanOrEqualToLastSeenSequenceId can throw a
> NullPointerException if the CacheClientNotifier instance is set
> --
>
> Key: GEODE-7466
> URL: https://issues.apache.org/jira/browse/GEODE-7466
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Barrett Oglesby
>Assignee: Ernest Burghardt
>Priority: Major
> Fix For: 1.12.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Testing has shown this NPE can occur:
> {noformat}
> java.lang.NullPointerException
> at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:936)
> at
> org.apache.geode.internal.cache.tier.sockets.CacheClientNotifier.getClientProxy(CacheClientNotifier.java:1197)
> at
> org.apache.geode.internal.cache.ha.HARegionQueue$DispatchedAndCurrentEvents.putObject(HARegionQueue.java:3023)
> at
> org.apache.geode.internal.cache.ha.HARegionQueue.basicPut(HARegionQueue.java:679)
> at
> org.apache.geode.internal.cache.ha.HARegionQueue.put(HARegionQueue.java:631)
> at
> org.apache.geode.internal.cache.ha.HARegionQueueTest.queuePutElidesSequenceIdLowerThanOrEqualToLastSeenSequenceId(HARegionQueueTest.java:119)
> {noformat}
> HARegionQueue.java:3023 is here:
> {noformat}
> CacheClientNotifier ccn =
> CacheClientNotifier.getInstance();
> if (ccn != null) {
> HARegionQueue.java:3023 ->
> ccn.getClientProxy(owningQueue.clientProxyID).getStatistics().incMessagesFailedQueued();
> }
> {noformat}
> The HARegionQueueTest does not create a CacheClientNotifier, so it seems like
> its created in another test and that test affects this one.
> If a CacheClientNotifier is created in this test, then the same NPE is thrown
> because owningQueue.clientProxyID is null.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (GEODE-7553) Review membership interfaces/classes and add javadocs where needed
[ https://issues.apache.org/jira/browse/GEODE-7553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt closed GEODE-7553. --- Assignee: Ernest Burghardt > Review membership interfaces/classes and add javadocs where needed > -- > > Key: GEODE-7553 > URL: https://issues.apache.org/jira/browse/GEODE-7553 > Project: Geode > Issue Type: Improvement > Components: membership >Reporter: Bruce J Schuchardt >Assignee: Ernest Burghardt >Priority: Major > Fix For: 1.12.0 > > Time Spent: 20m > Remaining Estimate: 0h > > I noticed that Distribution and Membership have no javadocs. We need to > review all membership interfaces, builders, factories, etc and add > appropriate javadocs. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-7740) Refactor and combine create_instances.sh for all Geode projects
[ https://issues.apache.org/jira/browse/GEODE-7740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt closed GEODE-7740. --- Assignee: Ernest Burghardt > Refactor and combine create_instances.sh for all Geode projects > --- > > Key: GEODE-7740 > URL: https://issues.apache.org/jira/browse/GEODE-7740 > Project: Geode > Issue Type: Improvement > Components: build, ci >Reporter: Robert Houghton >Assignee: Ernest Burghardt >Priority: Major > Fix For: 1.12.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Geode and geode-native-client both maintain their own GCE instance creation > scripts for Concourse CI. Combining them will lead to fewer issues as the GCE > APIs move forward, and lighten the load on maintainers. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-6927) possible NPE in ConnectionTable.getThreadOwnedConnection if concurrent close
[
https://issues.apache.org/jira/browse/GEODE-6927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ernest Burghardt closed GEODE-6927.
---
Assignee: Ernest Burghardt (was: Mario Kevo)
> possible NPE in ConnectionTable.getThreadOwnedConnection if concurrent close
>
>
> Key: GEODE-6927
> URL: https://issues.apache.org/jira/browse/GEODE-6927
> Project: Geode
> Issue Type: Bug
> Components: messaging
>Reporter: Darrel Schneider
>Assignee: Ernest Burghardt
>Priority: Minor
> Labels: easy-fix, needs-review, pull-request-available
> Fix For: 1.12.0
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> ConnectionTable.getThreadOwnedConnection has a couple of usages of
> "this.threadConnectionMap" that could result in an NPE if the ConnectionTable
> is concurrently closed.
> The unsafe code:
> {code:java}
> if (this.threadConnectionMap == null) {
> // This instance is being destroyed; fail the operation
> closeCon(
> "Connection table being destroyed",
> result);
> return null;
> }
> ArrayList al = (ArrayList) this.threadConnectionMap.get(id);
> if (al == null) {
> // First connection for this DistributedMember. Make sure list for this
> // stub is created if it isn't already there.
> al = new ArrayList();
> // Since it's a concurrent map, we just try to put it and then
> // return whichever we got.
> Object o = this.threadConnectionMap.putIfAbsent(id, al);
> if (o != null) {
> al = (ArrayList) o;
> }
> }
> {code}
> If a close happens after the initial null check but before either the get or
> putIfAbsent call then a NPE will be thrown.
> All the other code that uses "threadConnectionMap" is careful to save it into
> a local var, and then use the local var. That is all that is needed here to
> make this code thread safe.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (GEODE-7419) Complete info about geode-native integration tests
[ https://issues.apache.org/jira/browse/GEODE-7419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt closed GEODE-7419. --- Assignee: Ernest Burghardt (was: Alberto Bustamante Reyes) > Complete info about geode-native integration tests > -- > > Key: GEODE-7419 > URL: https://issues.apache.org/jira/browse/GEODE-7419 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Alberto Bustamante Reyes >Assignee: Ernest Burghardt >Priority: Minor > Labels: pull-request-available > Fix For: 1.12.0 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > Complete info about the two sets of geode-native integration tests, and the > preference of implementing new tests using GoogleTest. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-7709) Wrong name of property in documentation
[ https://issues.apache.org/jira/browse/GEODE-7709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt closed GEODE-7709. --- Assignee: Ernest Burghardt (was: Mario Kevo) > Wrong name of property in documentation > --- > > Key: GEODE-7709 > URL: https://issues.apache.org/jira/browse/GEODE-7709 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Mario Kevo >Assignee: Ernest Burghardt >Priority: Major > Fix For: 1.12.0 > > Time Spent: 20m > Remaining Estimate: 0h > > There is a wrong name of some properties in documentation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-7345) Break dependency on Tcp socket related classes
[ https://issues.apache.org/jira/browse/GEODE-7345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt closed GEODE-7345. --- Assignee: Ernest Burghardt (was: Bill Burcham) > Break dependency on Tcp socket related classes > -- > > Key: GEODE-7345 > URL: https://issues.apache.org/jira/browse/GEODE-7345 > Project: Geode > Issue Type: Sub-task > Components: membership >Reporter: Ernest Burghardt >Assignee: Ernest Burghardt >Priority: Major > Fix For: 1.12.0 > > Time Spent: 3h > Remaining Estimate: 0h > > CommunicationMode > SocketCreator > SSLConfigurationFactory > SecurableCommunicationChannel > SocketCreatorFactory. > SSLConfigurationFactor -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-7581) Benchmark CI: run SSL tests with JDK11
[ https://issues.apache.org/jira/browse/GEODE-7581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt closed GEODE-7581. --- Assignee: Ernest Burghardt (was: Helena Bales) > Benchmark CI: run SSL tests with JDK11 > -- > > Key: GEODE-7581 > URL: https://issues.apache.org/jira/browse/GEODE-7581 > Project: Geode > Issue Type: Improvement > Components: benchmarks >Reporter: Helena Bales >Assignee: Ernest Burghardt >Priority: Major > Fix For: 1.12.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Run the SSL benchmarks in CI with JDK 11 to improve their stability. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-7487) Running CQs should always use the latest installed Method Invocation Authorizer
[
https://issues.apache.org/jira/browse/GEODE-7487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ernest Burghardt closed GEODE-7487.
---
Assignee: Ernest Burghardt (was: Juan Ramos)
> Running CQs should always use the latest installed Method Invocation
> Authorizer
> ---
>
> Key: GEODE-7487
> URL: https://issues.apache.org/jira/browse/GEODE-7487
> Project: Geode
> Issue Type: Improvement
> Components: client queues, querying
>Reporter: Juan Ramos
>Assignee: Ernest Burghardt
>Priority: Major
> Labels: GeodeCommons
> Fix For: 1.12.0
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> When a {{MethodInvocationAuthorizer}} is changed in runtime, all running CQs
> should be updated to use it in order to avoid security issues. The previously
> cached results need to be invalidated/cleared as cached keys may not be valid
> anymore.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (GEODE-7647) Remove unused code from GMSJoinLeave.findCoordinator
[ https://issues.apache.org/jira/browse/GEODE-7647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt closed GEODE-7647. --- Assignee: Ernest Burghardt (was: Dan Smith) > Remove unused code from GMSJoinLeave.findCoordinator > > > Key: GEODE-7647 > URL: https://issues.apache.org/jira/browse/GEODE-7647 > Project: Geode > Issue Type: Improvement > Components: membership >Reporter: Dan Smith >Assignee: Ernest Burghardt >Priority: Major > Fix For: 1.12.0 > > Time Spent: 20m > Remaining Estimate: 0h > > There is some dead code in this method that computes a couple of local > variables that are never used - coord and coordIsNoob > https://github.com/apache/geode/blob/2178ba8fefcda23d4b2d3b6ecc68b58dd8839f7f/geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/membership/GMSJoinLeave.java#L1223 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-7212) User Guide - Authorization - update security permissions
[ https://issues.apache.org/jira/browse/GEODE-7212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt closed GEODE-7212. --- Assignee: Ernest Burghardt (was: Karen Smoler Miller) > User Guide - Authorization - update security permissions > > > Key: GEODE-7212 > URL: https://issues.apache.org/jira/browse/GEODE-7212 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Dave Barnes >Assignee: Ernest Burghardt >Priority: Major > Fix For: 1.12.0 > > Time Spent: 40m > Remaining Estimate: 0h > > "Fine-grained security" changes were implemented in v1.3, but docs & Wiki > were only recently updated. Pick up these changes in the user guide. See > [https://cwiki.apache.org/confluence/display/GEODE/Finer+grained+security]. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-7563) Replace uses of ConcurrentHashSet with ConcurrentHashMap.newKeySet()
[ https://issues.apache.org/jira/browse/GEODE-7563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt closed GEODE-7563. --- Assignee: Ernest Burghardt > Replace uses of ConcurrentHashSet with ConcurrentHashMap.newKeySet() > > > Key: GEODE-7563 > URL: https://issues.apache.org/jira/browse/GEODE-7563 > Project: Geode > Issue Type: Bug >Reporter: Dan Smith >Assignee: Ernest Burghardt >Priority: Major > Labels: low-hanging-fruit, newbie, starter > Fix For: 1.12.0 > > Time Spent: 1h > Remaining Estimate: 0h > > As of Java 1.8, we can create a concurrent hash set directly from the JDK. > https://stackoverflow.com/a/6992643 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-7796) CI: org.apache.geode.distributed.LocatorDUnitTest testCrashLocatorMultipleTimes hung
[ https://issues.apache.org/jira/browse/GEODE-7796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt closed GEODE-7796. --- Assignee: Ernest Burghardt > CI: org.apache.geode.distributed.LocatorDUnitTest > testCrashLocatorMultipleTimes hung > > > Key: GEODE-7796 > URL: https://issues.apache.org/jira/browse/GEODE-7796 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Jinmei Liao >Assignee: Ernest Burghardt >Priority: Major > Fix For: 1.12.0 > > Time Spent: 20m > Remaining Estimate: 0h > > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/1563 > in the artifacts callbacks/dunit-hang.txt, > Started @ 2020-02-11 00:30:32.499 + > 2020-02-11 01:07:59.054 + org.apache.geode.distributed.LocatorDUnitTest > testCrashLocatorMultipleTimes > Ended @ 2020-02-11 02:05:31.891 + > and the stacktraces shows thread gets blocked for a long time. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-7533) System Properties catalina.home and catalina.base are cleared during webapp reloads when using HTTP Session Management Module
[
https://issues.apache.org/jira/browse/GEODE-7533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ernest Burghardt closed GEODE-7533.
---
Assignee: Ernest Burghardt
> System Properties catalina.home and catalina.base are cleared during webapp
> reloads when using HTTP Session Management Module
> -
>
> Key: GEODE-7533
> URL: https://issues.apache.org/jira/browse/GEODE-7533
> Project: Geode
> Issue Type: Bug
> Components: http session
>Reporter: Charles Smith
>Assignee: Ernest Burghardt
>Priority: Major
> Fix For: 1.12.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> I noticed when using the HTTP Session Management Module for AppServers that
> my tomcat environment would act oddly when my webapp was reloaded. I tracked
> this down to the fact that catalina.home and catalina.base system properties
> were missing when the webapp reloaded.
>
> A quick search of the Geode code base found a couple of unexplainable lines
> in:
> {{geode-http-service/src/main/java/org/apache/geode/internal/cache/InternalHttpService.java}}
> in the close() method there are 2 calls to System.clearProperty() which
> essentially clear catalina.home and catalina.base.
>
> I am guessing that these lines exist from a previous state of this
> InternalHttpService when it was perhaps using an embedded Tomcat instance.
> Now the class appears to be implemented using Jetty and there are no other
> references to the catalina properties than the lines that clear them.
>
> This is likely also causing issues with the HTTP Session Management Module
> for Tomcat. I was a least able to workaround this issue by disabling the
> embedded HTTP server in the filter properties that configured the HTTP
> Session Management Module.
>
> Probably these 2 lines should just be removed from the InternalHttpService
> class...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (GEODE-7439) CI failure: DeltaSessionStatisticsIntegrationTest > sessionsExpiredStatisticsShouldBeIncrementedWhenSessionExpires
[
https://issues.apache.org/jira/browse/GEODE-7439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ernest Burghardt closed GEODE-7439.
---
Assignee: Ernest Burghardt (was: Juan Ramos)
> CI failure: DeltaSessionStatisticsIntegrationTest >
> sessionsExpiredStatisticsShouldBeIncrementedWhenSessionExpires
> --
>
> Key: GEODE-7439
> URL: https://issues.apache.org/jira/browse/GEODE-7439
> Project: Geode
> Issue Type: Bug
> Components: statistics
>Affects Versions: 1.11.0
>Reporter: Anilkumar Gingade
>Assignee: Ernest Burghardt
>Priority: Major
> Labels: GeodeCommons
> Fix For: 1.12.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {noformat}
> org.apache.geode.modules.session.catalina.internal.DeltaSessionStatisticsIntegrationTest
> > sessionsExpiredStatisticsShouldBeIncrementedWhenSessionExpires(PARTITION)
> [1] FAILED
> org.junit.ComparisonFailure: expected:<[1]L> but was:<[0]L>
> at
> jdk.internal.reflect.GeneratedConstructorAccessor27.newInstance(Unknown
> Source)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.modules.session.catalina.internal.DeltaSessionStatisticsIntegrationTest.sessionsExpiredStatisticsShouldBeIncrementedWhenSessionExpires(DeltaSessionStatisticsIntegrationTest.java:87)
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.12.0-SNAPSHOT.0009/test-results/integrationTest/1573507995/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.12.0-SNAPSHOT.0009/test-artifacts/1573507995/integrationtestfiles-OpenJDK11-1.12.0-SNAPSHOT.0009.tgz
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (GEODE-7338) create-images pipeline triggers on wrong base container image
[ https://issues.apache.org/jira/browse/GEODE-7338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt closed GEODE-7338. --- Assignee: Ernest Burghardt > create-images pipeline triggers on wrong base container image > - > > Key: GEODE-7338 > URL: https://issues.apache.org/jira/browse/GEODE-7338 > Project: Geode > Issue Type: Bug > Components: ci >Reporter: Robert Houghton >Assignee: Ernest Burghardt >Priority: Major > Fix For: 1.12.0 > > Time Spent: 20m > Remaining Estimate: 0h > > build-concourse-docker-image triggers on base-image `openjdk:8`, but the > `FROM` statement in the `Dockerfile` is `buildpack-deps:bionic-scm` -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-7599) Use GCI Concourse resource to track compute image versions
[ https://issues.apache.org/jira/browse/GEODE-7599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt closed GEODE-7599. --- Assignee: Ernest Burghardt > Use GCI Concourse resource to track compute image versions > -- > > Key: GEODE-7599 > URL: https://issues.apache.org/jira/browse/GEODE-7599 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Robert Houghton >Assignee: Ernest Burghardt >Priority: Major > Fix For: 1.12.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Use the Google Compute Image resource in concourse as an input to jobs that > use the heavy-lifter pattern. This will make it easier to track job failures > due to an image rebuild. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-7628) Block jmx mbean creation when no security manager is configured
[ https://issues.apache.org/jira/browse/GEODE-7628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt closed GEODE-7628. --- Assignee: Ernest Burghardt > Block jmx mbean creation when no security manager is configured > --- > > Key: GEODE-7628 > URL: https://issues.apache.org/jira/browse/GEODE-7628 > Project: Geode > Issue Type: Improvement > Components: jmx >Affects Versions: 1.10.0 >Reporter: Jinmei Liao >Assignee: Ernest Burghardt >Priority: Major > Fix For: 1.12.0 > > Time Spent: 10m > Remaining Estimate: 0h > > When no security manager is configured, we should not allow any client to be > able to create mbeans. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-7652) Improve API for creating a MembershipLocator
[ https://issues.apache.org/jira/browse/GEODE-7652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt closed GEODE-7652. --- Assignee: Ernest Burghardt (was: Bill Burcham) > Improve API for creating a MembershipLocator > > > Key: GEODE-7652 > URL: https://issues.apache.org/jira/browse/GEODE-7652 > Project: Geode > Issue Type: Improvement > Components: membership >Reporter: Dan Smith >Assignee: Ernest Burghardt >Priority: Major > Fix For: 1.12.0 > > Time Spent: 3h 20m > Remaining Estimate: 0h > > The relationship between MembershipLocator and Membership is still a little > strange - you must call MembershipLocator.setMembership at a specific point > during the Membership startup sequence. > Instead, we should pass the MembershipLocator into the MembershipBuilder and > remove the MembershipLocator.setMembership method. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-7425) Ability: can delete index in RESTAPI for Management
[ https://issues.apache.org/jira/browse/GEODE-7425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt closed GEODE-7425. --- Assignee: Ernest Burghardt > Ability: can delete index in RESTAPI for Management > --- > > Key: GEODE-7425 > URL: https://issues.apache.org/jira/browse/GEODE-7425 > Project: Geode > Issue Type: New Feature > Components: management, rest (admin) >Reporter: Gang Yan >Assignee: Ernest Burghardt >Priority: Major > Fix For: 1.12.0 > > Time Spent: 3h > Remaining Estimate: 0h > > # WHAT > 1. endpoint: [DELETE] `management/v1/indexes` > 1. parameter: "name", "region", "group" > 1. expected result: delete index as specified parameters -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-7387) CI failure: SingleHopGetAllPutAllDUnitTest > testRemoveAllInClient failed with AssertionError
[
https://issues.apache.org/jira/browse/GEODE-7387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ernest Burghardt closed GEODE-7387.
---
Assignee: Ernest Burghardt (was: Mark Hanson)
> CI failure: SingleHopGetAllPutAllDUnitTest > testRemoveAllInClient failed
> with AssertionError
> -
>
> Key: GEODE-7387
> URL: https://issues.apache.org/jira/browse/GEODE-7387
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Barrett Oglesby
>Assignee: Ernest Burghardt
>Priority: Major
> Labels: Flaky, flaky
> Fix For: 1.12.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> DistributedTestOpenJDK8 build 1252:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/1252
> The client starts the testRemoveAllInClient task:
> {noformat}
> [vm3] [info 2019/10/30 12:17:46.836 GMT
> tid=0x20] Received method: org.apache.geode.test.dunit.NamedRunnable.run with
> 0 args on object: runnable(testRemoveAllInClient)
> {noformat}
> It does a putAll (which creates the buckets on the servers):
> {noformat}
> [vm1] [info 2019/10/30 12:17:46.959 GMT Thread 2> tid=0x81] Initializing region _B__TestPartitionedRegion_6
> [vm2] [info 2019/10/30 12:17:47.030 GMT
> tid=0x5a] Initializing region _B__TestPartitionedRegion_6
> [vm0] [info 2019/10/30 12:17:47.083 GMT
> tid=0x53] Initializing region _B__TestPartitionedRegion_6
> [vm0] [info 2019/10/30 12:17:47.150 GMT
> tid=0x89] Initializing region _B__TestPartitionedRegion_4
> [vm2] [info 2019/10/30 12:17:47.178 GMT
> tid=0x5a] Initializing region _B__TestPartitionedRegion_4
> ...
> {noformat}
> The putAll timeouts out once (read-timeout is set to 2000 ms):
> {noformat}
> [vm3] [warn 2019/10/30 12:17:48.942 GMT
> tid=0x20] Pool unexpected socket timed out on client connection=Pooled
> Connection to 23c02ffd4a40:25248: Connection[23c02ffd4a40:25248]@264362003)
> {noformat}
> It must succeed after retry (retry-attempts is set to 2) because the
> verifyMetadata method is executed, and the assertion fails:
> {noformat}
> [vm3] [info 2019/10/30 12:17:49.429 GMT
> tid=0x20] Got result: EXCEPTION_OCCURRED
> [vm3] java.lang.AssertionError:
> [vm3] Expecting actual not to be null
> [vm3] at
> org.apache.geode.internal.cache.execute.SingleHopGetAllPutAllDUnitTest.lambda$verifyMetadata$1(SingleHopGetAllPutAllDUnitTest.java:247)
> [vm3] at
> org.awaitility.core.CallableCondition$ConditionEvaluationWrapper.eval(CallableCondition.java:100)
> [vm3] at
> org.awaitility.core.ConditionAwaiter$ConditionPoller.call(ConditionAwaiter.java:192)
> [vm3] at
> org.awaitility.core.ConditionAwaiter$ConditionPoller.call(ConditionAwaiter.java:179)
> [vm3] at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [vm3] at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [vm3] at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [vm3] at java.lang.Thread.run(Thread.java:748)
> [vm3] from org.apache.geode.test.dunit.NamedRunnable.run with 0 args on
> object: runnable(testRemoveAllInClient) (took 2592 ms)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (GEODE-7590) Windows Heavy-Lifters fail to connect after gcloud base image update
[
https://issues.apache.org/jira/browse/GEODE-7590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ernest Burghardt closed GEODE-7590.
---
Assignee: Ernest Burghardt
> Windows Heavy-Lifters fail to connect after gcloud base image update
>
>
> Key: GEODE-7590
> URL: https://issues.apache.org/jira/browse/GEODE-7590
> Project: Geode
> Issue Type: Bug
> Components: ci
>Reporter: Robert Houghton
>Assignee: Ernest Burghardt
>Priority: Major
> Fix For: 1.12.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Google Compute Image family {{windows-2016}} updated to
> {{windows-server-2016-dc-v20191210}} , and the heavy-lifter built by Packer
> was unreachable afterward. CI rebuilds have been paused, and the "broken"
> image has been deleted from the apachegeode-ci google project.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (GEODE-7561) Geode does not allow creating GW senders with a single dispatcher thread
[
https://issues.apache.org/jira/browse/GEODE-7561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ernest Burghardt closed GEODE-7561.
---
Assignee: Ernest Burghardt (was: Mario Kevo)
> Geode does not allow creating GW senders with a single dispatcher thread
>
>
> Key: GEODE-7561
> URL: https://issues.apache.org/jira/browse/GEODE-7561
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Mario Kevo
>Assignee: Ernest Burghardt
>Priority: Major
> Labels: needs-review, pull-request-available
> Fix For: 1.12.0
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> {color:#172b4d}When creating GW sender Geode does not honor
> _--dispatcher-threads_ when it is equal to 1.{color}
> {color:#172b4d}Effectively this means one cannot create GW sender with a
> single dispatcher thread. If you ask for 1 you will get 5(default
> value).{color}
> {color:#172b4d} {color}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (GEODE-7656) OOME in CoreOnlyUsesMembershipAPIArchUnitTest > cacheClassesDoNotUseMembershipInternals
[ https://issues.apache.org/jira/browse/GEODE-7656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt closed GEODE-7656. --- Assignee: Ernest Burghardt (was: Bruce J Schuchardt) > OOME in CoreOnlyUsesMembershipAPIArchUnitTest > > cacheClassesDoNotUseMembershipInternals > --- > > Key: GEODE-7656 > URL: https://issues.apache.org/jira/browse/GEODE-7656 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Dale Emery >Assignee: Ernest Burghardt >Priority: Major > Fix For: 1.12.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Out of memory exception in CI: > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/IntegrationTestOpenJDK8/builds/1421] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-7574) Fix javadoc warnings
[ https://issues.apache.org/jira/browse/GEODE-7574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt closed GEODE-7574. --- Assignee: Ernest Burghardt (was: Joris Melchior) > Fix javadoc warnings > > > Key: GEODE-7574 > URL: https://issues.apache.org/jira/browse/GEODE-7574 > Project: Geode > Issue Type: Task > Components: management >Reporter: Joris Melchior >Assignee: Ernest Burghardt >Priority: Major > Fix For: 1.12.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Task :geode-management:javadoc > /Users/jbarrett/Develop/geode/geode-management/src/main/java/org/apache/geode/management/configuration/AutoSerializer.java:34: > warning - Tag @link: reference not found: > org.apache.geode.pdx.ReflectionBasedAutoSerializer > /Users/jbarrett/Develop/geode/geode-management/src/main/java/org/apache/geode/management/configuration/ClassName.java:36: > warning - Tag @link: reference not found: org.apache.geode.cache.Declarable > /Users/jbarrett/Develop/geode/geode-management/src/main/java/org/apache/geode/management/configuration/ClassName.java:68: > warning - Tag @link: reference not found: > org.apache.geode.cache.Declarable#initialize > /Users/jbarrett/Develop/geode/geode-management/src/main/java/org/apache/geode/management/configuration/ClassName.java:93: > warning - Tag @link: reference not found: > org.apache.geode.cache.Declarable#initialize > /Users/jbarrett/Develop/geode/geode-management/src/main/java/org/apache/geode/management/configuration/Pdx.java:78: > warning - Tag @link: reference not found: org.apache.geode.pdx.PdxInstance > /Users/jbarrett/Develop/geode/geode-management/src/main/java/org/apache/geode/management/configuration/Pdx.java:78: > warning - Tag @link: reference not found: org.apache.geode.pdx.PdxInstance > /Users/jbarrett/Develop/geode/geode-management/src/main/java/org/apache/geode/management/configuration/Pdx.java:91: > warning - Tag @link: reference not found: org.apache.geode.pdx.PdxSerializer > /Users/jbarrett/Develop/geode/geode-management/src/main/java/org/apache/geode/management/configuration/AutoSerializer.java:34: > warning - Tag @link: reference not found: > org.apache.geode.pdx.ReflectionBasedAutoSerializer > /Users/jbarrett/Develop/geode/geode-management/src/main/java/org/apache/geode/management/configuration/AutoSerializer.java:34: > warning - Tag @link: reference not found: > org.apache.geode.pdx.ReflectionBasedAutoSerializer > /Users/jbarrett/Develop/geode/geode-management/src/main/java/org/apache/geode/management/configuration/Pdx.java:78: > warning - Tag @link: reference not found: org.apache.geode.pdx.PdxInstance -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-7440) automate publishing of Native docker image
[ https://issues.apache.org/jira/browse/GEODE-7440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt closed GEODE-7440. --- Assignee: Ernest Burghardt (was: Owen Nichols) > automate publishing of Native docker image > -- > > Key: GEODE-7440 > URL: https://issues.apache.org/jira/browse/GEODE-7440 > Project: Geode > Issue Type: Improvement > Components: release >Reporter: Owen Nichols >Assignee: Ernest Burghardt >Priority: Major > Fix For: 1.12.0 > > Time Spent: 10m > Remaining Estimate: 0h > > The Geode [release > steps|https://cwiki.apache.org/confluence/display/GEODE/Releasing+Apache+Geode#ReleasingApacheGeode-Updategeode-native-buildDockerimage] > were recently updated to add steps for geode-native-build Docker image. > This should be automated in the release scripts, since Geode docker image > already is. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-7530) For AEQ queue size, GEODE should return local size only
[
https://issues.apache.org/jira/browse/GEODE-7530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ernest Burghardt closed GEODE-7530.
---
Assignee: Ernest Burghardt (was: Eric Shu)
> For AEQ queue size, GEODE should return local size only
>
>
> Key: GEODE-7530
> URL: https://issues.apache.org/jira/browse/GEODE-7530
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.6.0
>Reporter: Eric Shu
>Assignee: Ernest Burghardt
>Priority: Major
> Labels: GeodeCommons
> Fix For: 1.12.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The following stack shows that current it does not.
> {noformat}
> [warn 2019/11/24 19:48:51.755 PST tid=0x1f] Thread <96>
> (0x60) that was executed at <24 Nov 2019 19:47:30 PST> has been stuck for
> <81.69 seconds> and number of thread monitor iteration <1>
> Thread Name GatewaySender_AsyncEventQueue_index#_testRegion_0> state
> Waiting on
> Executor Group
> Monitored metric
> Thread stack:
> sun.misc.Unsafe.park(Native Method)
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
> org.apache.geode.internal.util.concurrent.StoppableCountDownLatch.await(StoppableCountDownLatch.java:72)
> org.apache.geode.distributed.internal.ReplyProcessor21.basicWait(ReplyProcessor21.java:731)
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:802)
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:779)
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:865)
> org.apache.geode.internal.cache.partitioned.SizeMessage$SizeResponse.waitBucketSizes(SizeMessage.java:344)
> org.apache.geode.internal.cache.PartitionedRegion.getSizeRemotely(PartitionedRegion.java:6718)
> org.apache.geode.internal.cache.PartitionedRegion.entryCount(PartitionedRegion.java:6669)
> org.apache.geode.internal.cache.PartitionedRegion.entryCount(PartitionedRegion.java:6651)
> org.apache.geode.internal.cache.PartitionedRegion.getRegionSize(PartitionedRegion.java:6623)
> org.apache.geode.internal.cache.LocalRegionDataView.entryCount(LocalRegionDataView.java:99)
> org.apache.geode.internal.cache.LocalRegion.entryCount(LocalRegion.java:2078)
> org.apache.geode.internal.cache.LocalRegion.size(LocalRegion.java:8262)
> org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue.size(ParallelGatewaySenderQueue.java:1502)
> org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.eventQueueSize(AbstractGatewaySenderEventProcessor.java:271)
> org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.handleSuccessfulBatchDispatch(AbstractGatewaySenderEventProcessor.java:969)
> org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.processQueue(AbstractGatewaySenderEventProcessor.java:667)
> org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.run(AbstractGatewaySenderEventProcessor.java:)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (GEODE-7659) Code clean up, remove unused parameter in wan test
[ https://issues.apache.org/jira/browse/GEODE-7659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt closed GEODE-7659. --- Assignee: Ernest Burghardt (was: Jason Huynh) > Code clean up, remove unused parameter in wan test > -- > > Key: GEODE-7659 > URL: https://issues.apache.org/jira/browse/GEODE-7659 > Project: Geode > Issue Type: Task > Components: tests >Reporter: Jason Huynh >Assignee: Ernest Burghardt >Priority: Major > Fix For: 1.12.0 > > Time Spent: 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-7431) benchmarks may fail due to infrastructure quota
[ https://issues.apache.org/jira/browse/GEODE-7431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt closed GEODE-7431. --- Assignee: Ernest Burghardt > benchmarks may fail due to infrastructure quota > --- > > Key: GEODE-7431 > URL: https://issues.apache.org/jira/browse/GEODE-7431 > Project: Geode > Issue Type: Bug > Components: ci >Reporter: Owen Nichols >Assignee: Ernest Burghardt >Priority: Major > Fix For: 1.12.0 > > Time Spent: 40m > Remaining Estimate: 0h > > For example, > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark/builds/677] > failed because there were already 3 benchmarks jobs running at the time > Since the quota is 40 and each benchmark uses 12, we should restrict > max_in_flight to 3 for this job -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-7734) MembershipLocatorBuilder does not register DSFIDs
[ https://issues.apache.org/jira/browse/GEODE-7734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt closed GEODE-7734. --- Assignee: Ernest Burghardt > MembershipLocatorBuilder does not register DSFIDs > - > > Key: GEODE-7734 > URL: https://issues.apache.org/jira/browse/GEODE-7734 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Dan Smith >Assignee: Ernest Burghardt >Priority: Major > Fix For: 1.12.0 > > > Calling MembershipLocatorBuilder.create() does not register the DSFIDs for > requests that the locator will receive with the DSFIDSerializer that it has. > This means that instead of deserializing classes, it fails with > deserialization errors. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-7613) deadlock initializing DistributionConfig.DEFAULT_MCAST_ADDRESS
[
https://issues.apache.org/jira/browse/GEODE-7613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ernest Burghardt closed GEODE-7613.
---
Assignee: Ernest Burghardt (was: Bill Burcham)
> deadlock initializing DistributionConfig.DEFAULT_MCAST_ADDRESS
> --
>
> Key: GEODE-7613
> URL: https://issues.apache.org/jira/browse/GEODE-7613
> Project: Geode
> Issue Type: Bug
> Components: core
>Reporter: Bill Burcham
>Assignee: Ernest Burghardt
>Priority: Major
> Fix For: 1.12.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> In this JDK11 DUnit test run:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/1402
> there was a deadlock during {{TcpServerProductVersionDUnitTest
> testAllMessageTypes[OLD_CURRENT]}}
> The problem is, this line in {{DistributionConfig}}:
> {code}
> InetAddress DEFAULT_MCAST_ADDRESS =
> AbstractDistributionConfig._getDefaultMcastAddress();
> {code}
> It references a subtype of {{DistributionConfig}}, i.e.
> {{AbstractDistributionConfig}}. When one thread references
> {{DistributionConfig}} and another thread references
> {{AbstractDistributionConfig}}—both for the first time, there is a deadlock
> in class initialization.
> The solution is to make initialization of the base type
> ({{DistributionConfig}}) independent of the derived type
> ({{AbstractDistributionConfig}}).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (GEODE-7721) Unable to define Redis default regions with persistence
[
https://issues.apache.org/jira/browse/GEODE-7721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ernest Burghardt closed GEODE-7721.
---
Assignee: Ernest Burghardt
> Unable to define Redis default regions with persistence
> ---
>
> Key: GEODE-7721
> URL: https://issues.apache.org/jira/browse/GEODE-7721
> Project: Geode
> Issue Type: Improvement
> Components: redis
>Reporter: Jens Deppe
>Assignee: Ernest Burghardt
>Priority: Major
> Fix For: 1.12.0
>
>
> The Redis adapter is able to override the default region type; for example:
> {noformat}
> --J=-Dgemfireredis.regiontype=PARTITION
> {noformat}
> However, when using a default region type with PERSISTENCE (for example
> {{PARTITION_PERSISTENT}}, the following exception is thrown:
> {noformat}
> [info 2020/01/17 10:59:03.392 PST tid=0x1] Starting GeodeRedisServer
> on bind address 127.0.0.1 on port 6379
> [warn 2020/01/17 10:59:03.407 PST tid=0x1] Cache service
> org.apache.geode.redis.internal.GeodeRedisService failed to initialize
> java.lang.NullPointerException
> at
> org.apache.geode.internal.cache.LocalRegion.findDiskStore(LocalRegion.java:7473)
> at
> org.apache.geode.internal.cache.PartitionedRegion.findDiskStore(PartitionedRegion.java:9182)
> at
> org.apache.geode.internal.cache.LocalRegion.(LocalRegion.java:602)
> at
> org.apache.geode.internal.cache.LocalRegion.(LocalRegion.java:546)
> at
> org.apache.geode.internal.cache.PartitionedRegion.(PartitionedRegion.java:758)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:2923)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreateRegion(GemFireCacheImpl.java:2867)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.createRegion(GemFireCacheImpl.java:2851)
> at org.apache.geode.cache.RegionFactory.create(RegionFactory.java:768)
> at
> org.apache.geode.redis.GeodeRedisServer.initializeRedis(GeodeRedisServer.java:423)
> at
> org.apache.geode.redis.GeodeRedisServer.start(GeodeRedisServer.java:379)
> at
> org.apache.geode.redis.internal.GeodeRedisService.startRedisServer(GeodeRedisService.java:61)
> at
> org.apache.geode.redis.internal.GeodeRedisService.init(GeodeRedisService.java:35)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initializeServices(GemFireCacheImpl.java:1416)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1358)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158)
> 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:894)
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:809)
> at
> org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:739)
> at
> org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:256)
> {noformat}
> This is a lifecycle problem since the cache services (Redis is a
> CacheService) are started before the cache is fully and completely
> initiailized.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (GEODE-7437) 1-way SSL is communicating without "ssl-truststore" from the client side when "use-ssl" is set to true
[ https://issues.apache.org/jira/browse/GEODE-7437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt closed GEODE-7437. --- Assignee: Ernest Burghardt > 1-way SSL is communicating without "ssl-truststore" from the client side when > "use-ssl" is set to true > -- > > Key: GEODE-7437 > URL: https://issues.apache.org/jira/browse/GEODE-7437 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Blake Bender >Assignee: Ernest Burghardt >Priority: Major > Fix For: 1.12.0 > > Time Spent: 1h > Remaining Estimate: 0h > > Native client is not failing as it should when server certificate can't be > validated. Need to add support for this, along with proper tests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-7597) Factor out code needed in Membership from SocketCreator
[
https://issues.apache.org/jira/browse/GEODE-7597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ernest Burghardt closed GEODE-7597.
---
Assignee: Ernest Burghardt
> Factor out code needed in Membership from SocketCreator
> ---
>
> Key: GEODE-7597
> URL: https://issues.apache.org/jira/browse/GEODE-7597
> Project: Geode
> Issue Type: Improvement
> Components: membership
>Reporter: Bill Burcham
>Assignee: Ernest Burghardt
>Priority: Major
> Fix For: 1.12.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> {{SocketCreator}} is part of {{geode-core}}. But we need a
> {{TcpSocketCreator}} to test membership. Rather than creating a new
> implementation of {{TcpSocketCreator}} used only in tests, we'll factor out
> the code from {{SocketCreator}} into TBD class/TBD module for use by both
> {{SocketCreator}} and membership tests.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (GEODE-7256) Dunit Test Failure: alterLogFileSizeLimitTooBig_errorCanNotSet(false) [1]
[
https://issues.apache.org/jira/browse/GEODE-7256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ernest Burghardt closed GEODE-7256.
---
Assignee: Ernest Burghardt (was: Kirk Lund)
> Dunit Test Failure: alterLogFileSizeLimitTooBig_errorCanNotSet(false) [1]
> -
>
> Key: GEODE-7256
> URL: https://issues.apache.org/jira/browse/GEODE-7256
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Mark Hanson
>Assignee: Ernest Burghardt
>Priority: Major
> Labels: flaky
> Fix For: 1.12.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> It looks like we are not dealing with a reply well. Logs are not conclusive.
> Test run failed
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsGfshDistributedTestOpenJDK11/builds/890]
>
> Logs are at
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.11.0-SNAPSHOT.0170/test-results/distributedTest/1569874663/
>
> {noformat}
> java.lang.AssertionError: Suspicious strings were written to the log during
> this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 118[fatal 2019/09/30 19:41:11.953 GMT
> tid=2185] Unknown handshake reply code: %s
> nioMessageLength: %s
> at org.junit.Assert.fail(Assert.java:88)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:380)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.after(ClusterStartupRule.java:193)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.access$100(ClusterStartupRule.java:70)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:148)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at
> junitparams.internal.ParameterisedTestMethodRunner.runMethodInvoker(ParameterisedTestMethodRunner.java:47)
> at
> junitparams.internal.ParameterisedTestMethodRunner.runTestMethod(ParameterisedTestMethodRunner.java:40)
> at
> junitparams.internal.ParameterisedTestClassRunner.runParameterisedTest(ParameterisedTestClassRunner.java:146)
> at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:446)
> at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:393)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> at
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
> at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
> at
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:118)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.r
[jira] [Closed] (GEODE-7626) Break dependency on LocalViewMessage in membership
[ https://issues.apache.org/jira/browse/GEODE-7626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt closed GEODE-7626. --- Assignee: Ernest Burghardt (was: Bruce J Schuchardt) > Break dependency on LocalViewMessage in membership > -- > > Key: GEODE-7626 > URL: https://issues.apache.org/jira/browse/GEODE-7626 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Dan Smith >Assignee: Ernest Burghardt >Priority: Major > Fix For: 1.12.0 > > Time Spent: 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-7583) "status locator --name/--dir" is not working properly when locator ssl is enabled
[
https://issues.apache.org/jira/browse/GEODE-7583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ernest Burghardt closed GEODE-7583.
---
Assignee: Ernest Burghardt
> "status locator --name/--dir" is not working properly when locator ssl is
> enabled
> -
>
> Key: GEODE-7583
> URL: https://issues.apache.org/jira/browse/GEODE-7583
> Project: Geode
> Issue Type: Bug
> Components: docs, gfsh
>Affects Versions: 1.8.0, 1.9.0, 1.10.0, 1.11.0
>Reporter: Jinmei Liao
>Assignee: Ernest Burghardt
>Priority: Major
> Fix For: 1.12.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> in 1.8:
> 1. start a locator with ssl enabled
> 2. "status locator --dir" or "status locator --name" would trigger such error
> messages in the locator log:
> {quote}[info 2019/12/16 08:57:39.958 PST locator
> tid=0x23] Exception in processing request from 10.118.20.75
> javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
> at
> sun.security.ssl.InputRecord.handleUnknownRecord(InputRecord.java:710)
> at sun.security.ssl.InputRecord.read(InputRecord.java:527)
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:975)
> at
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1367)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1395)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1379)
> at
> org.apache.geode.internal.net.SocketCreator.handshakeIfSocketIsSSL(SocketCreator.java:981)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:346)
> 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)
> {quote}
> In develop branch: the gfsh output would be a strange ClassCastException.
> It's definitely broken on develop
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (GEODE-7417) CI checks do not trigger on geode-book changes
[ https://issues.apache.org/jira/browse/GEODE-7417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt closed GEODE-7417. --- Assignee: Ernest Burghardt (was: Owen Nichols) > CI checks do not trigger on geode-book changes > -- > > Key: GEODE-7417 > URL: https://issues.apache.org/jira/browse/GEODE-7417 > Project: Geode > Issue Type: Bug > Components: ci >Reporter: Owen Nichols >Assignee: Ernest Burghardt >Priority: Major > Fix For: 1.12.0 > > Time Spent: 20m > Remaining Estimate: 0h > > due to new branch protection rules, it is now impossible to submit geode-book > changes as the required checks will never fire > we should remove the exclusion so checks can run -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-6779) Create disk-store command should only return when DistributedSystemMXBean reflects creation status
[
https://issues.apache.org/jira/browse/GEODE-6779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ernest Burghardt closed GEODE-6779.
---
Assignee: Ernest Burghardt (was: Jens Deppe)
> Create disk-store command should only return when DistributedSystemMXBean
> reflects creation status
> --
>
> Key: GEODE-6779
> URL: https://issues.apache.org/jira/browse/GEODE-6779
> Project: Geode
> Issue Type: Improvement
> Components: gfsh
>Reporter: Jens Deppe
>Assignee: Ernest Burghardt
>Priority: Major
> Fix For: 1.12.0
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> Once fixed, we can remove
> {{MemberVM.waitUntilDiskStoreIsReadyOnExactlyThisManyServers}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (GEODE-7579) improvement: list indexes in REST API need to show all the runtime index info
[
https://issues.apache.org/jira/browse/GEODE-7579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ernest Burghardt closed GEODE-7579.
---
Assignee: Ernest Burghardt
> improvement: list indexes in REST API need to show all the runtime index info
> -
>
> Key: GEODE-7579
> URL: https://issues.apache.org/jira/browse/GEODE-7579
> Project: Geode
> Issue Type: Improvement
> Components: management, rest (admin)
>Reporter: Gang Yan
>Assignee: Ernest Burghardt
>Priority: Minor
> Fix For: 1.12.0
>
> Time Spent: 3h 40m
> Remaining Estimate: 0h
>
> # Steps to reproduce
> gfsh commands:
> start server --server-port=0 --group=g5 --name=g5-s5
> start server --server-port=0 --group=g6 --name=g6-s6
> create region --name=/regionTest --type=PARTITION --group=g5
> create region --name=/regionTest --type=PARTITION_PROXY --group=g6
> create index --name=regionTest.name1 --expression=name --region=/regionTest
> --group=g5
> create index --name=regionTest.name1 --expression=name2 --region=/regionTest
> --group=g6
> create index --name=regionTest.name2 --expression=name --region=/regionTest
> --group=g6
> and then run "list indexes", we will find there are 4 indexes
> gfsh>list indexes
> Member Name | Member ID | Region Path | Name |
> Type | Indexed Expression | From Clause | Valid Index
> --- | - | --- | |
> - | -- | --- | ---
> g5-s5 | 10.118.20.154(g5-s5:967.. | /regionTest | regionTest.name1 |
> RANGE | name | /regionTest | true
> g5-s5 | 10.118.20.154(g5-s5:967.. | /regionTest | regionTest.name2 |
> RANGE | name | /regionTest | true
> g6-s6 | 10.118.20.154(g6-s6:967.. | /regionTest | regionTest.name1 |
> RANGE | name2 | /regionTest | false
> g6-s6 | 10.118.20.154(g6-s6:967.. | /regionTest | regionTest.name2 |
> RANGE | name | /regionTest | false
> but in REST API, [GET]"/management/v1/indexes", there are only 3 indexes:
> {
> "statusCode": "OK",
> "result": [
> {
> "configuration": {
> "group": "g6",
> "name": "regionTest.name1",
> "expression": "name2",
> "regionPath": "/regionTest",
> "indexType": "RANGE"
> },
> "runtimeInfo": [
> {
> "memberName": "g6-s6"
> }
> ],
> "links": {
> "self":
> "http://127.0.0.1:7070/management/v1/regions/regionTest/indexes/regionTest.name1";,
> "list":
> "http://127.0.0.1:7070/management/v1/regions/regionTest/indexes";,
> "region":
> "http://127.0.0.1:7070/management/v1/regions/regionTest";
> }
> },
> {
> "configuration": {
> "group": "g6",
> "name": "regionTest.name2",
> "expression": "name",
> "regionPath": "/regionTest",
> "indexType": "RANGE"
> },
> "runtimeInfo": [
> {
> "memberName": "g6-s6"
> }
> ],
> "links": {
> "self":
> "http://127.0.0.1:7070/management/v1/regions/regionTest/indexes/regionTest.name2";,
> "list":
> "http://127.0.0.1:7070/management/v1/regions/regionTest/indexes";,
> "region":
> "http://127.0.0.1:7070/management/v1/regions/regionTest";
> }
> },
> {
> "configuration": {
> "group": "g5",
> "name": "regionTest.name1",
> "expression": "name",
> "regionPath": "/regionTest",
> "indexType": "RANGE"
> },
> "runtimeInfo": [
> {
> "memberName": "g5-s5"
> }
> ],
> "links": {
> "self":
> "http://127.0.0.1:7070/management/v1/regions/regionTest/indexes/regionTest.name1";,
> "list":
> "http://127.0.0.1:7070/management/v1/regions/regionTest/indexes";,
> "region":
> "http://127.0.0.1:7070/management/v1/regions/regionTest";
> }
> }
> ]
> }
> in REST AP [GET]"/management/v1/indexes", the users can not find "g5-s5
> | 10.118.20.154(g5-s5:967.. | /regionTest | regionTest.name2 | RANGE | name
> | /regionTest | true"
> need to show this in REST API [GET]"/management/v1/indexes".
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (GEODE-7612) Move statistics and logging implementation into .cpp files
[ https://issues.apache.org/jira/browse/GEODE-7612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt closed GEODE-7612. --- Assignee: Ernest Burghardt > Move statistics and logging implementation into .cpp files > -- > > Key: GEODE-7612 > URL: https://issues.apache.org/jira/browse/GEODE-7612 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Blake Bender >Assignee: Ernest Burghardt >Priority: Major > Fix For: 1.12.0 > > Time Spent: 50m > Remaining Estimate: 0h > > As a developer, I would like to minimize the time spent recompiling code that > I haven't modified. One important way to improve this situation in the > native client is to move some of the bazillions of inline methods declared in > headers into .cpp files. A change to one of these methods then triggers a > recompile of just that file, rather than the large number of native client > files that inevitably include the header. > This item covers the above transformation for the internal classes involved > in logging and statistics. While there, we should clean up a couple of other > things that are unnecessary, such as the use of our own `NonCopyable` and > `NonAssignable`, both of which can now easily be accomplished with a standard > C++ 11 mechanism. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-7661) NullPointerException when serializing an EventID to a geode 1.0.0 member
[
https://issues.apache.org/jira/browse/GEODE-7661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ernest Burghardt closed GEODE-7661.
---
Assignee: Ernest Burghardt (was: Dan Smith)
> NullPointerException when serializing an EventID to a geode 1.0.0 member
>
>
> Key: GEODE-7661
> URL: https://issues.apache.org/jira/browse/GEODE-7661
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Dan Smith
>Assignee: Ernest Burghardt
>Priority: Major
> Fix For: 1.12.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When serializing an EventID to a geode 1.0.0 member, there is special logic
> to translate the EventId.membershipID bytes to a different format.
> However, it's possible to construct an EventID with null bytes. This gets
> used as part of GII for server to client queues in HAEventWrapper.toData, as
> seen in this code and stack trace:
> {code}
> context.getSerializer().writeObject(new EventID(), out);
> {code}
> {noformat}
> [warning 2020/01/02 22:03:29.029 PST bridgegemfire5_host1_32096 0.0.0.0/0.0.0.0:24446 Thread 6> tid=0x1b8] Initialization failed for Region
> /_gfe_non_durable_client_with_id_rs-FullRegression03050259a4i32xlarge-hydra-client-19(edgegemfire3_host1_32498:32498:loner):40074:57d9f969:edgegemfire3_host1_32498(version:GFE
> 8.1)_1_queue
> java.lang.NullPointerException
> at Remote Member
> 'rs-FullRegression03050259a4i32xlarge-hydra-client-19(bridgegemfire6_host1_7584:7584):41002(version:UNKNOWN[ordinal=115])'
> in
> org.apache.geode.internal.serialization.ByteArrayDataInput.initialize(ByteArrayDataInput.java:62)
> at Remote Member
> 'rs-FullRegression03050259a4i32xlarge-hydra-client-19(bridgegemfire6_host1_7584:7584):41002(version:UNKNOWN[ordinal=115])'
> in
> org.apache.geode.internal.serialization.ByteArrayDataInput.(ByteArrayDataInput.java:50)
> at Remote Member
> 'rs-FullRegression03050259a4i32xlarge-hydra-client-19(bridgegemfire6_host1_7584:7584):41002(version:UNKNOWN[ordinal=115])'
> in
> org.apache.geode.internal.cache.EventID.getDistributedMember(EventID.java:319)
> at Remote Member
> 'rs-FullRegression03050259a4i32xlarge-hydra-client-19(bridgegemfire6_host1_7584:7584):41002(version:UNKNOWN[ordinal=115])'
> in org.apache.geode.internal.cache.EventID.toData(EventID.java:360)
> at Remote Member
> 'rs-FullRegression03050259a4i32xlarge-hydra-client-19(bridgegemfire6_host1_7584:7584):41002(version:UNKNOWN[ordinal=115])'
> in
> org.apache.geode.internal.serialization.DSFIDSerializerImpl.invokeToData(DSFIDSerializerImpl.java:199)
> at Remote Member
> 'rs-FullRegression03050259a4i32xlarge-hydra-client-19(bridgegemfire6_host1_7584:7584):41002(version:UNKNOWN[ordinal=115])'
> in
> org.apache.geode.internal.serialization.DSFIDSerializerImpl.write(DSFIDSerializerImpl.java:123)
> at Remote Member
> 'rs-FullRegression03050259a4i32xlarge-hydra-client-19(bridgegemfire6_host1_7584:7584):41002(version:UNKNOWN[ordinal=115])'
> in
> org.apache.geode.internal.InternalDataSerializer.basicWriteObject(InternalDataSerializer.java:2007)
> at Remote Member
> 'rs-FullRegression03050259a4i32xlarge-hydra-client-19(bridgegemfire6_host1_7584:7584):41002(version:UNKNOWN[ordinal=115])'
> in org.apache.geode.DataSerializer.writeObject(DataSerializer.java:2839)
> at Remote Member
> 'rs-FullRegression03050259a4i32xlarge-hydra-client-19(bridgegemfire6_host1_7584:7584):41002(version:UNKNOWN[ordinal=115])'
> in
> org.apache.geode.internal.InternalDataSerializer$2.writeObject(InternalDataSerializer.java:293)
> at Remote Member
> 'rs-FullRegression03050259a4i32xlarge-hydra-client-19(bridgegemfire6_host1_7584:7584):41002(version:UNKNOWN[ordinal=115])'
> in
> org.apache.geode.internal.cache.tier.sockets.HAEventWrapper.toData(HAEventWrapper.java:287)
> at Remote Member
> 'rs-FullRegression03050259a4i32xlarge-hydra-client-19(bridgegemfire6_host1_7584:7584):41002(version:UNKNOWN[ordinal=115])'
> in
> org.apache.geode.internal.serialization.DSFIDSerializerImpl.invokeToData(DSFIDSerializerImpl.java:199)
> at Remote Member
> 'rs-FullRegression03050259a4i32xlarge-hydra-client-19(bridgegemfire6_host1_7584:7584):41002(version:UNKNOWN[ordinal=115])'
> in
> org.apache.geode.internal.serialization.DSFIDSerializerImpl.write(DSFIDSerializerImpl.java:123)
> at Remote Member
> 'rs-FullRegression03050259a4i32xlarge-hydra-client-19(bridgegemfire6_host1_7584:7584):41002(version:UNKNOWN[ordinal=115])'
> in
> org.apache.geode.internal.InternalDataSerializer.basicWriteObject(InternalDataSerializer.java:2007)
> at Remote Member
> 'rs-FullRegression03050259a4i32xlarge-hydra-client-19(bridgegemfire6_host1_7584:7584):41002
[jira] [Closed] (GEODE-7294) Update dependencies for v1.12
[ https://issues.apache.org/jira/browse/GEODE-7294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt closed GEODE-7294. --- Assignee: Ernest Burghardt > Update dependencies for v1.12 > - > > Key: GEODE-7294 > URL: https://issues.apache.org/jira/browse/GEODE-7294 > Project: Geode > Issue Type: Improvement > Components: build >Reporter: Anthony Baker >Assignee: Ernest Burghardt >Priority: Major > Fix For: 1.12.0 > > Time Spent: 4h 10m > Remaining Estimate: 0h > > Update all the dependencies we can. See attached PR. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-2184) Docs: Variable-ize Java version numbers
[ https://issues.apache.org/jira/browse/GEODE-2184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt closed GEODE-2184. --- Assignee: Ernest Burghardt (was: Alberto Bustamante Reyes) > Docs: Variable-ize Java version numbers > --- > > Key: GEODE-2184 > URL: https://issues.apache.org/jira/browse/GEODE-2184 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Dave Barnes >Assignee: Ernest Burghardt >Priority: Minor > Labels: pull-request-available > Fix For: 1.12.0 > > Time Spent: 40m > Remaining Estimate: 0h > > Examples containing specific version strings, e.g. "Geode 1.0.0-incubating" > and "javac 1.8.0_92" must be updated with every doc release or they go out of > date. In most cases, the specific numbers are not meaningful to the example. > Updating with every related revision requires considerable, usually > unnecessary, effort. Replace such version strings with generic placeholders. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-7545) Break dependency on AlertingAction
[ https://issues.apache.org/jira/browse/GEODE-7545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt closed GEODE-7545. --- Assignee: Ernest Burghardt > Break dependency on AlertingAction > --- > > Key: GEODE-7545 > URL: https://issues.apache.org/jira/browse/GEODE-7545 > Project: Geode > Issue Type: Sub-task > Components: membership >Reporter: Ernest Burghardt >Assignee: Ernest Burghardt >Priority: Major > Fix For: 1.12.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > JGroupsMessenger usage -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-7788) Alpine tools docker image creation fails due to internal winrm-cli changes.
[ https://issues.apache.org/jira/browse/GEODE-7788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt closed GEODE-7788. --- Assignee: Ernest Burghardt > Alpine tools docker image creation fails due to internal winrm-cli changes. > --- > > Key: GEODE-7788 > URL: https://issues.apache.org/jira/browse/GEODE-7788 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Bala Tripura Sundari Kaza Venkata >Assignee: Ernest Burghardt >Priority: Major > Fix For: 1.12.0, 1.13.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The winrm-cli (https://github.com/masterzen/winrm-cli) folks have changed the > internal go dependencies which results in the failure of building the > cli.This is an important dependency for building the windows image, so we > need a fix for that. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-7717) ClusterManagementListResult should contain a list ConfigurationInfo (config per id)
[ https://issues.apache.org/jira/browse/GEODE-7717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt closed GEODE-7717. --- Assignee: Ernest Burghardt > ClusterManagementListResult should contain a list ConfigurationInfo (config > per id) > --- > > Key: GEODE-7717 > URL: https://issues.apache.org/jira/browse/GEODE-7717 > Project: Geode > Issue Type: Improvement > Components: management >Reporter: Jinmei Liao >Assignee: Ernest Burghardt >Priority: Major > Labels: tech-debt, technical_debt > Fix For: 1.12.0, 1.13.0 > > Time Spent: 1.5h > Remaining Estimate: 0h > > Currently ClusterManagementListResult contains a list > ConfigurationResult(config per group), those configs are not grouped by id, > so a region that belongs to multiple groups might be dispersed in the list. > Since ClsuterManagementGetResult contains a single ConfigurationInfo, it > seems to make sense to have the ListResult contains a list of > ConfigurationInfo. > Also, after the ClusterManagementListResult contains the list grouped by id, > it would be good for us to display "links" in the ConfigurationInfo level > instead of ConfigurationResult level. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-7690) make it less difficult to run benchmarks against a fork or PR
[ https://issues.apache.org/jira/browse/GEODE-7690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt closed GEODE-7690. --- Assignee: Ernest Burghardt (was: Owen Nichols) > make it less difficult to run benchmarks against a fork or PR > - > > Key: GEODE-7690 > URL: https://issues.apache.org/jira/browse/GEODE-7690 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Owen Nichols >Assignee: Ernest Burghardt >Priority: Major > Fix For: 1.12.0 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > To run Benchmarks against a personal fork, it's not immediately obvious where > to override the default of "apache/geode" > Would be nice to add variables for this at the top of run_benchmarks.sh so > they can be easily adapted without having to figure out how to update the > very long call into benchmarks. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-7753) CI Failure: Tomcat9CachingClientServerTest. multipleClientsCanMaintainOwnSessions
[ https://issues.apache.org/jira/browse/GEODE-7753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt closed GEODE-7753. --- Assignee: Ernest Burghardt (was: Eric Shu) > CI Failure: Tomcat9CachingClientServerTest. > multipleClientsCanMaintainOwnSessions > - > > Key: GEODE-7753 > URL: https://issues.apache.org/jira/browse/GEODE-7753 > Project: Geode > Issue Type: Bug >Reporter: Benjamin P Ross >Assignee: Ernest Burghardt >Priority: Major > Fix For: 1.12.0 > > > We saw a failure in CI for this test: > org.apache.geode.session.tests.Tomcat9CachingClientServerTest > > multipleClientsCanMaintainOwnSessions FAILED > org.awaitility.core.ConditionTimeoutException: Assertion condition > defined as a lambda expression in > org.apache.geode.session.tests.CargoTestBase expected:<"[Foo55]"> but > was:<"[]"> within 300 seconds. > Caused by: > org.junit.ComparisonFailure: expected:<"[Foo55]"> but was:<"[]"> > java.lang.NullPointerException > org.apache.geode.session.tests.Tomcat6CachingClientServerTest > > multipleClientsCanMaintainOwnSessions FAILED > org.awaitility.core.ConditionTimeoutException: Assertion condition > defined as a lambda expression in > org.apache.geode.session.tests.CargoTestBase expected:<"[Foo55]"> but > was:<"[]"> within 300 seconds. > Caused by: > org.junit.ComparisonFailure: expected:<"[Foo55]"> but was:<"[]"> > java.lang.NullPointerException > org.apache.geode.session.tests.Tomcat7CachingClientServerTest > > multipleClientsCanMaintainOwnSessions FAILED > org.awaitility.core.ConditionTimeoutException: Assertion condition > defined as a lambda expression in > org.apache.geode.session.tests.CargoTestBase expected:<"[Foo55]"> but > was:<"[]"> within 300 seconds. > Caused by: > org.junit.ComparisonFailure: expected:<"[Foo55]"> but was:<"[]"> > org.awaitility.core.ConditionTimeoutException: Assertion condition > defined as a lambda expression in > org.apache.geode.session.tests.CargoTestBase expected:<"[Foo55]"> but > was:<"[]"> within 300 seconds. > Caused by: > org.junit.ComparisonFailure: expected:<"[Foo55]"> but was:<"[]"> > java.lang.NullPointerException > java.lang.NullPointerException > > It's possible that this issue could show up in Tomcat 7,8, and 9 tests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-7494) Update ArchUnit from 0.10.2 to 0.12.0
[ https://issues.apache.org/jira/browse/GEODE-7494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt closed GEODE-7494. --- Assignee: Ernest Burghardt (was: Kirk Lund) > Update ArchUnit from 0.10.2 to 0.12.0 > - > > Key: GEODE-7494 > URL: https://issues.apache.org/jira/browse/GEODE-7494 > Project: Geode > Issue Type: Wish > Components: tests >Reporter: Kirk Lund >Assignee: Ernest Burghardt >Priority: Major > Fix For: 1.12.0 > > Time Spent: 20m > Remaining Estimate: 0h > > ArchUnit 0.12.0 has been released. We should update the Geode dependency: > [https://github.com/TNG/ArchUnit/releases/tag/v0.12.0|https://github.com/TNG/ArchUnit/releases/tag/v0.12.0] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-7424) Ability: can create index in RESTAPI for Management
[
https://issues.apache.org/jira/browse/GEODE-7424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ernest Burghardt closed GEODE-7424.
---
Assignee: Ernest Burghardt
> Ability: can create index in RESTAPI for Management
> ---
>
> Key: GEODE-7424
> URL: https://issues.apache.org/jira/browse/GEODE-7424
> Project: Geode
> Issue Type: New Feature
> Components: management, rest (admin)
>Reporter: Gang Yan
>Assignee: Ernest Burghardt
>Priority: Major
> Fix For: 1.12.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> # WHAT
> 1. endpoint: [POST] `management/v1/indexes`
> 1. parameter: "name(indexID)", "expression", "region", "type", "group"
> 1. expected result: create index by specified parameters
> 1. type: default is "range"
> 1. region is required
> 1. name(indexID) is required
> 1. expression is required
> 1. "hash" type is not supported.
> ### Note
> 1. request body
> ```JSON
> {
> "name": "Foo6name3",
> "expression": "name3",
> "regionPath": "/Foo6",
> “group”：“”，
> “type”：“” range|key
> }
> ```
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (GEODE-7741) Clean up failed Packer instances in the GCP project
[ https://issues.apache.org/jira/browse/GEODE-7741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt closed GEODE-7741. --- Assignee: Ernest Burghardt > Clean up failed Packer instances in the GCP project > --- > > Key: GEODE-7741 > URL: https://issues.apache.org/jira/browse/GEODE-7741 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Robert Houghton >Assignee: Ernest Burghardt >Priority: Major > Fix For: 1.12.0 > > Time Spent: 20m > Remaining Estimate: 0h > > If the Packer jobs fail in Concourse, they are not always cleaned up from the > project, and are left running until somebody notices. > Adding labels to the instances like for the 'heavy-lifter' instances will > allow the Geode reaper job to find and delete these instances in a timely > manner. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-7522) always link to rest wiki page by Geode version number, not "develop"
[ https://issues.apache.org/jira/browse/GEODE-7522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt closed GEODE-7522. --- Assignee: Ernest Burghardt > always link to rest wiki page by Geode version number, not "develop" > > > Key: GEODE-7522 > URL: https://issues.apache.org/jira/browse/GEODE-7522 > Project: Geode > Issue Type: Improvement > Components: management >Reporter: Owen Nichols >Assignee: Ernest Burghardt >Priority: Major > Fix For: 1.12.0 > > Time Spent: 20m > Remaining Estimate: 0h > > update wiki generator script to name the page with the actual version rather > than `develop` so that corresponding documentation can be created with a link > that will remain valid through development phase, release phase, and after > release. > change has already been made, changing > https://cwiki.apache.org/confluence/display/GEODE/develop+Management+REST+API+-+v1 > to > https://cwiki.apache.org/confluence/display/GEODE/1.12.0+Management+REST+API+-+v1 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-7393) Parameterize concourse team variable
[ https://issues.apache.org/jira/browse/GEODE-7393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt closed GEODE-7393. --- Assignee: Ernest Burghardt > Parameterize concourse team variable > > > Key: GEODE-7393 > URL: https://issues.apache.org/jira/browse/GEODE-7393 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Bala Tripura Sundari Kaza Venkata >Assignee: Ernest Burghardt >Priority: Trivial > Fix For: 1.12.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Geode needs 'CONCOURSE_TEAM' in meta.properties > This would allow us to override the pipeline groupings. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-7625) Remove broken DH support
[ https://issues.apache.org/jira/browse/GEODE-7625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt closed GEODE-7625. --- Assignee: Ernest Burghardt > Remove broken DH support > > > Key: GEODE-7625 > URL: https://issues.apache.org/jira/browse/GEODE-7625 > Project: Geode > Issue Type: Task > Components: native client >Reporter: Jacob Barrett >Assignee: Ernest Burghardt >Priority: Major > Fix For: 1.12.0 > > Time Spent: 50m > Remaining Estimate: 0h > > The DH support in geode native client has been broken since donation. There > are currently no enabled tests for DH. The current sources compile but > guarantee a memory access violation. All 4 implementation in the code base > have the same bug. I recommend removal of the source to cleanup the code and > build. > If DH support is required in the client at a later date we can either recover > the sources or better yet start over with testing. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-7534) Add to documentation how to access top level region data with bind parameters in the path expression (FROM)
[ https://issues.apache.org/jira/browse/GEODE-7534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt closed GEODE-7534. --- Assignee: Ernest Burghardt (was: Alberto Gomez) > Add to documentation how to access top level region data with bind parameters > in the path expression (FROM) > --- > > Key: GEODE-7534 > URL: https://issues.apache.org/jira/browse/GEODE-7534 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Alberto Gomez >Assignee: Ernest Burghardt >Priority: Major > Fix For: 1.12.0 > > Time Spent: 20m > Remaining Estimate: 0h > > When trying to create a query using bind parameters in the path expression > (FROM) in order to select to level region data it is not obvious that in > order for the expression to be correct, the bind parameter must be surrounded > by parenthesis as in the following example: > > SELECT e.key FROM ($1).entrySet e WHERE e.value.name=$2" -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-7519) GMSHealthMonitorJUnitTest fails in testCheckIfAvailableNoHeartBeatDontRemoveMember
[
https://issues.apache.org/jira/browse/GEODE-7519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ernest Burghardt closed GEODE-7519.
---
Assignee: Ernest Burghardt
> GMSHealthMonitorJUnitTest fails in
> testCheckIfAvailableNoHeartBeatDontRemoveMember
> --
>
> Key: GEODE-7519
> URL: https://issues.apache.org/jira/browse/GEODE-7519
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Scott Jewell
>Assignee: Ernest Burghardt
>Priority: Major
> Fix For: 1.12.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> {noformat}
>
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitorJUnitTest
> > testCheckIfAvailableNoHeartBeatDontRemoveMember FAILED
> java.lang.AssertionError: This should have taken member ping timeout 100ms
> but it took 999
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitorJUnitTest.testCheckIfAvailableNoHeartBeatDontRemoveMember(GMSHealthMonitorJUnitTest.java:468){noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.12.0-SNAPSHOT.0058/test-results/integrationTest/1574889470/]
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.12.0-SNAPSHOT.0058/test-artifacts/1574889470/windows-coreintegrationtestfiles-OpenJDK8-1.12.0-SNAPSHOT.0058.tgz]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (GEODE-7450) SSL peerAppDataBuffer expansion needs work
[
https://issues.apache.org/jira/browse/GEODE-7450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ernest Burghardt closed GEODE-7450.
---
Assignee: Ernest Burghardt (was: Bruce J Schuchardt)
> SSL peerAppDataBuffer expansion needs work
> --
>
> Key: GEODE-7450
> URL: https://issues.apache.org/jira/browse/GEODE-7450
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Affects Versions: 1.10.0
>Reporter: Bruce J Schuchardt
>Assignee: Ernest Burghardt
>Priority: Major
> Fix For: 1.12.0
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> I commented out the first invocation of expandPeerAppData() in
> NioSslEngine.unwrap() and found that the handling of BufferOverFlowException
> in that method doesn't always handle increase of the decrypt buffer
> ("peerAppData") correctly with all cipher suites.
> The handling of that exception needs to ensure that it increases the capacity
> of the peerAppData buffer every time an overflow happens. Repeated overflows
> should cause the buffer to keep expanding until it's big enough to hold the
> decrypted data.
> If that's done the initial invocation of expandPeerAppData() could be
> removed, saving us from having to perform calculations that usually aren't
> necessary.
> The exception handling could be something like this:
> {code:java}
> int newCapacity = (peerAppData.limit() - peerAppData.position()) * 2 +
> peerAppData.position();
> newCapacity = Math.max(newCapacity, peerAppData.capacity() / 2 * 3);
> peerAppData = bufferPool.expandWriteBufferIfNeeded(TRACKED_RECEIVER,
> peerAppData, newCapacity);
> peerAppData.limit(peerAppData.capacity());
> break;
> {code}
> I've done informal testing of that change and it seems to work. The test
> created a cache using 100k socket buffers and did puts using 70k byte-array
> payloads that were replicated to a second node. TLSv1.2 was used as the SSL
> protocol. Logging traces that I had in place showed the buffer increasing in
> capacity with each overflow exception until the buffer was big enough to hold
> the 70k+ decrypted update messages.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
