[jira] [Commented] (GEODE-8421) Improve clearing of existing GW sender queue
[ https://issues.apache.org/jira/browse/GEODE-8421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17208534#comment-17208534 ] ASF GitHub Bot commented on GEODE-8421: --- mivanac merged pull request #5445: URL: https://github.com/apache/geode/pull/5445 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Improve clearing of existing GW sender queue > > > Key: GEODE-8421 > URL: https://issues.apache.org/jira/browse/GEODE-8421 > Project: Geode > Issue Type: Improvement > Components: wan >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > Labels: pull-request-available > > It is observed that clearing of GW sender queue, can take some time, due to > mechanism which calls clear on all BucketRegions. This is improvement which > proposes destroying of partition region, which is much faster. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8421) Improve clearing of existing GW sender queue
[ https://issues.apache.org/jira/browse/GEODE-8421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17208535#comment-17208535 ] ASF subversion and git services commented on GEODE-8421: Commit 9bc288a6c421315e8da4fb00d8461f6312fa0ced in geode's branch refs/heads/develop from Mario Ivanac [ https://gitbox.apache.org/repos/asf?p=geode.git;h=9bc288a ] GEODE-8421: replace clean with destroy region (#5445) > Improve clearing of existing GW sender queue > > > Key: GEODE-8421 > URL: https://issues.apache.org/jira/browse/GEODE-8421 > Project: Geode > Issue Type: Improvement > Components: wan >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > Labels: pull-request-available > > It is observed that clearing of GW sender queue, can take some time, due to > mechanism which calls clear on all BucketRegions. This is improvement which > proposes destroying of partition region, which is much faster. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8421) Improve clearing of existing GW sender queue
[ https://issues.apache.org/jira/browse/GEODE-8421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivanac resolved GEODE-8421. - Fix Version/s: 1.14.0 Resolution: Fixed > Improve clearing of existing GW sender queue > > > Key: GEODE-8421 > URL: https://issues.apache.org/jira/browse/GEODE-8421 > Project: Geode > Issue Type: Improvement > Components: wan >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > It is observed that clearing of GW sender queue, can take some time, due to > mechanism which calls clear on all BucketRegions. This is improvement which > proposes destroying of partition region, which is much faster. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8553) Reduce ThinClientLocatorHelper lock time
[ https://issues.apache.org/jira/browse/GEODE-8553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17208730#comment-17208730 ] ASF GitHub Bot commented on GEODE-8553: --- gaussianrecurrence commented on pull request #660: URL: https://github.com/apache/geode-native/pull/660#issuecomment-704262279 > If you push the build fix to your branch, my pipeline will run build/test for all platforms automatically... Oh that's nice. On either case I completed the execution of the tests. They are all passing except for this new integration test: BasicIPv6Test.queryResultForRange Thing is the problem seems ip6-locahost does not exist in my host. I modified it so it uses ::1 as binding address, just to see if that was the problem but it failed due to ACE not being able to find the host. Which leds me to think. Shouldn't be IPV6 tests disabled if WITH_IPV6 CMake option is not enabled? Or should I always compile with IPV6 in order to run the tests? Summaziring here: "In theory all test should pass except for the IPV6 one" This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Reduce ThinClientLocatorHelper lock time > > > Key: GEODE-8553 > URL: https://issues.apache.org/jira/browse/GEODE-8553 > Project: Geode > Issue Type: Improvement > Components: native client >Affects Versions: 1.12.0, 1.13.0 >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > > During my troublshootings, I've seen that locking m_locatorLock for the whole > scope of the class function members might cause some inter-locks. > Problem here and in many other places of the NC is that networking operations > are performed while a mutex is locked. Therefore if *thread A* takes longer > than expected in performing its network operation, it might block another one > which does not requires any resource of the first *thread A*. Hence, the > inter-lock. > This improvement is the first one of a series regarding to lock scope > reduction when it comes with code regarding networking in NC. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8577) PubSubNativeRedisAcceptanceTest is flaky
[ https://issues.apache.org/jira/browse/GEODE-8577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17208762#comment-17208762 ] ASF GitHub Bot commented on GEODE-8577: --- jdeppe-pivotal merged pull request #5597: URL: https://github.com/apache/geode/pull/5597 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > PubSubNativeRedisAcceptanceTest is flaky > > > Key: GEODE-8577 > URL: https://issues.apache.org/jira/browse/GEODE-8577 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Jens Deppe >Priority: Major > Labels: pull-request-available > > Going to disable this one test and work on fixing that. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8577) PubSubNativeRedisAcceptanceTest is flaky
[ https://issues.apache.org/jira/browse/GEODE-8577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17208764#comment-17208764 ] ASF subversion and git services commented on GEODE-8577: Commit f8dae61cf9c7b9b1be20b1ed99dbee9d208595ea in geode's branch refs/heads/develop from Jens Deppe [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f8dae61 ] GEODE-8577: Fix flaky PubSubNativeRedisAcceptanceTest (#5597) - Apparently we need more time between retrying for a new connection on docker. > PubSubNativeRedisAcceptanceTest is flaky > > > Key: GEODE-8577 > URL: https://issues.apache.org/jira/browse/GEODE-8577 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Jens Deppe >Priority: Major > Labels: pull-request-available > > Going to disable this one test and work on fixing that. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8538) Create test to validate ordering of redis pipeline commands
[ https://issues.apache.org/jira/browse/GEODE-8538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17208771#comment-17208771 ] ASF subversion and git services commented on GEODE-8538: Commit 0c412718ce97fd143231ab24585dc39d7db8bd6d in geode's branch refs/heads/develop from John Hutchison [ https://gitbox.apache.org/repos/asf?p=geode.git;h=0c41271 ] GEODE-8538: Create test to validate ordering of redis pipeline commands (#5552) Co-authored-by: Ray Ingles Co-authored-by: Darrel Schneider Co-authored-by: Jens Deppe Co-authored-by: Sarah Abbey > Create test to validate ordering of redis pipeline commands > --- > > Key: GEODE-8538 > URL: https://issues.apache.org/jira/browse/GEODE-8538 > Project: Geode > Issue Type: Test > Components: redis >Reporter: John Hutchison >Priority: Major > Labels: pull-request-available > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8538) Create test to validate ordering of redis pipeline commands
[ https://issues.apache.org/jira/browse/GEODE-8538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17208769#comment-17208769 ] ASF GitHub Bot commented on GEODE-8538: --- sabbey37 merged pull request #5552: URL: https://github.com/apache/geode/pull/5552 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Create test to validate ordering of redis pipeline commands > --- > > Key: GEODE-8538 > URL: https://issues.apache.org/jira/browse/GEODE-8538 > Project: Geode > Issue Type: Test > Components: redis >Reporter: John Hutchison >Priority: Major > Labels: pull-request-available > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8576) "security-peer-auth-init" property should not be marked as deprecated
[ https://issues.apache.org/jira/browse/GEODE-8576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-8576. Fix Version/s: 1.14.0 Resolution: Fixed > "security-peer-auth-init" property should not be marked as deprecated > - > > Key: GEODE-8576 > URL: https://issues.apache.org/jira/browse/GEODE-8576 > Project: Geode > Issue Type: Bug > Components: configuration >Affects Versions: 1.13.0 >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.14.0 > > > in some cases, this is still useful if credentials are not supplied as plain > text in "security-username" and "security-password" -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8576) "security-peer-auth-init" property should not be marked as deprecated
[ https://issues.apache.org/jira/browse/GEODE-8576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17208839#comment-17208839 ] ASF GitHub Bot commented on GEODE-8576: --- jinmeiliao merged pull request #5592: URL: https://github.com/apache/geode/pull/5592 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > "security-peer-auth-init" property should not be marked as deprecated > - > > Key: GEODE-8576 > URL: https://issues.apache.org/jira/browse/GEODE-8576 > Project: Geode > Issue Type: Bug > Components: configuration >Affects Versions: 1.13.0 >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > in some cases, this is still useful if credentials are not supplied as plain > text in "security-username" and "security-password" -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8576) "security-peer-auth-init" property should not be marked as deprecated
[ https://issues.apache.org/jira/browse/GEODE-8576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17208841#comment-17208841 ] ASF subversion and git services commented on GEODE-8576: Commit e4c077a0b8229b941e52a965ac7364b933c02804 in geode's branch refs/heads/develop from Jinmei Liao [ https://gitbox.apache.org/repos/asf?p=geode.git;h=e4c077a ] GEODE-8576: fix doc on "security-peer-auth-init" (#5592) > "security-peer-auth-init" property should not be marked as deprecated > - > > Key: GEODE-8576 > URL: https://issues.apache.org/jira/browse/GEODE-8576 > Project: Geode > Issue Type: Bug > Components: configuration >Affects Versions: 1.13.0 >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.14.0 > > > in some cases, this is still useful if credentials are not supplied as plain > text in "security-username" and "security-password" -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8538) Create test to validate ordering of redis pipeline commands
[ https://issues.apache.org/jira/browse/GEODE-8538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sarah Abbey updated GEODE-8538: --- Fix Version/s: 1.14.0 > Create test to validate ordering of redis pipeline commands > --- > > Key: GEODE-8538 > URL: https://issues.apache.org/jira/browse/GEODE-8538 > Project: Geode > Issue Type: Test > Components: redis >Reporter: John Hutchison >Assignee: Sarah Abbey >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8538) Create test to validate ordering of redis pipeline commands
[ https://issues.apache.org/jira/browse/GEODE-8538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sarah Abbey resolved GEODE-8538. Resolution: Fixed > Create test to validate ordering of redis pipeline commands > --- > > Key: GEODE-8538 > URL: https://issues.apache.org/jira/browse/GEODE-8538 > Project: Geode > Issue Type: Test > Components: redis >Reporter: John Hutchison >Assignee: Sarah Abbey >Priority: Major > Labels: pull-request-available > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8538) Create test to validate ordering of redis pipeline commands
[ https://issues.apache.org/jira/browse/GEODE-8538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sarah Abbey reassigned GEODE-8538: -- Assignee: Sarah Abbey > Create test to validate ordering of redis pipeline commands > --- > > Key: GEODE-8538 > URL: https://issues.apache.org/jira/browse/GEODE-8538 > Project: Geode > Issue Type: Test > Components: redis >Reporter: John Hutchison >Assignee: Sarah Abbey >Priority: Major > Labels: pull-request-available > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8578) Parse PartitionResolverName in RESPONSE_CLIENT_PARTITION_ATTRIBUTES
Alberto Bustamante Reyes created GEODE-8578: --- Summary: Parse PartitionResolverName in RESPONSE_CLIENT_PARTITION_ATTRIBUTES Key: GEODE-8578 URL: https://issues.apache.org/jira/browse/GEODE-8578 Project: Geode Issue Type: Improvement Components: native client Reporter: Alberto Bustamante Reyes I tried the gnmsg tool with a client file connecting to a cluster that contains a partition region with a partition resolver, which caused an exception in the tool. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8578) Parse PartitionResolverName in RESPONSE_CLIENT_PARTITION_ATTRIBUTES
[ https://issues.apache.org/jira/browse/GEODE-8578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Bustamante Reyes reassigned GEODE-8578: --- Assignee: Alberto Bustamante Reyes > Parse PartitionResolverName in RESPONSE_CLIENT_PARTITION_ATTRIBUTES > --- > > Key: GEODE-8578 > URL: https://issues.apache.org/jira/browse/GEODE-8578 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Major > > I tried the gnmsg tool with a client file connecting to a cluster that > contains a partition region with a partition resolver, which caused an > exception in the tool. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8172) CI failure: ParallelWANPersistenceEnabledGatewaySenderOffHeapDUnitTest.testpersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived
[
https://issues.apache.org/jira/browse/GEODE-8172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17208913#comment-17208913
]
Mark Hanson commented on GEODE-8172:
Failed again.
[https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/529]
=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0394/test-results/distributedTest/1602001897/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Test report artifacts from this job are available at:
http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0394/test-artifacts/1602001897/distributedtestfiles-OpenJDK8-1.14.0-build.0394.tgz
> CI failure:
> ParallelWANPersistenceEnabledGatewaySenderOffHeapDUnitTest.testpersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived
> ---
>
> Key: GEODE-8172
> URL: https://issues.apache.org/jira/browse/GEODE-8172
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Bruce J Schuchardt
>Assignee: Mario Ivanac
>Priority: Major
>
> Failed in a CI run
> (https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/191#A).
> No previous failures for this issue are found in JIRA and no recent WAN
> changes could be detected. Flaky?
> {noformat}
> > Task :geode-wan:distributedTest
> org.apache.geode.internal.cache.wan.offheap.ParallelWANPersistenceEnabledGatewaySenderOffHeapDUnitTest
> >
> testpersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived
> FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.wan.parallel.ParallelWANPersistenceEnabledGatewaySenderDUnitTest$$Lambda$487/908301056.run
> in VM 2 running on Host 8e35f765a792 with 8 VMs
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.internal.cache.wan.WANTestBase that uses int,
> intorg.apache.geode.cache.Region Expected region entries: 0 but actual
> entries: 20 present region keyset [3, 5, 8, 13, 16, 21, 27, 30, 35, 38, 43,
> 45, 50, 54, 58, 62, 65, 68, 73, 78] expected:<0> but was:<20> within 5
> minutes.
> Caused by:
> java.lang.AssertionError: Expected region entries: 0 but actual
> entries: 20 present region keyset [3, 5, 8, 13, 16, 21, 27, 30, 35, 38, 43,
> 45, 50, 54, 58, 62, 65, 68, 73, 78] expected:<0> but was:<20>
> 824 tests completed, 1 failed, 59 skipped
> > Task :geode-wan:distributedTest FAILED
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7710) JMXMBeanReconnectDUnitTest fails intermittently because one locator is missing the LockServiceMXBean
[
https://issues.apache.org/jira/browse/GEODE-7710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17208967#comment-17208967
]
Mark Hanson commented on GEODE-7710:
Failed again
[https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/502]
JMXMBeanReconnectDUnitTest >
serverMXBeansOnLocatorAreRestoredAfterCrashedServerReturns FAILED
=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0393/test-results/distributedTest/1602000585/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Test report artifacts from this job are available at:
http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0393/test-artifacts/1602000585/distributedtestfiles-OpenJDK11-1.14.0-build.0393.tgz
> JMXMBeanReconnectDUnitTest fails intermittently because one locator is
> missing the LockServiceMXBean
>
>
> Key: GEODE-7710
> URL: https://issues.apache.org/jira/browse/GEODE-7710
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.13.0
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: flaky
> Time Spent: 5h
> Remaining Estimate: 0h
>
> Multiple tests in JMXMBeanReconnectDUnitTest may fail an await due to one of
> the locators missing the LockServiceMXBean for the cluster config service.
> {noformat}
> but could not find:
>
> <[GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator1]>
> {noformat}
> These test failures are caused by *GEODE-7739*.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-8525) PubSubNativeRedisAcceptanceTest.concurrentSubscribers_andPublishers_doesNotHang CI failure
[
https://issues.apache.org/jira/browse/GEODE-8525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sarah Abbey resolved GEODE-8525.
Fix Version/s: 1.14.0
Resolution: Fixed
> PubSubNativeRedisAcceptanceTest.concurrentSubscribers_andPublishers_doesNotHang
> CI failure
> --
>
> Key: GEODE-8525
> URL: https://issues.apache.org/jira/browse/GEODE-8525
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Sarah Abbey
>Assignee: Sarah Abbey
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> {code:java}
> org.apache.geode.redis.internal.executor.pubsub.PubSubNativeRedisAcceptanceTest
> > concurrentSubscribers_andPublishers_doesNotHang FAILED
> java.util.concurrent.ExecutionException:
> java.util.concurrent.ExecutionException: java.lang.RuntimeException:
> java.util.concurrent.ExecutionException: java.lang.RuntimeException:
> inner.get() errored after unsubscribe: null
> Caused by:
> java.util.concurrent.ExecutionException: java.lang.RuntimeException:
> java.util.concurrent.ExecutionException: java.lang.RuntimeException:
> inner.get() errored after unsubscribe: null
> Caused by:
> java.lang.RuntimeException:
> java.util.concurrent.ExecutionException: java.lang.RuntimeException:
> inner.get() errored after unsubscribe: null
> Caused by:
> java.util.concurrent.ExecutionException:
> java.lang.RuntimeException: inner.get() errored after unsubscribe: null
> Caused by:
> java.lang.RuntimeException: inner.get() errored after
> unsubscribe: null
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8172) CI failure: ParallelWANPersistenceEnabledGatewaySenderOffHeapDUnitTest.testpersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived
[
https://issues.apache.org/jira/browse/GEODE-8172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17208970#comment-17208970
]
Mark Hanson commented on GEODE-8172:
.ParallelWANPersistenceEnabledGatewaySenderOffHeapDUnitTest >
testpersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived
FAILED
[https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/526]
=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
[http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0391/test-results/distributedTest/1601977431/]
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Test report artifacts from this job are available at:
[http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0391/test-artifacts/1601977431/distributedtestfiles-OpenJDK8-1.14.0-build.0391.tgz]
> CI failure:
> ParallelWANPersistenceEnabledGatewaySenderOffHeapDUnitTest.testpersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived
> ---
>
> Key: GEODE-8172
> URL: https://issues.apache.org/jira/browse/GEODE-8172
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Bruce J Schuchardt
>Assignee: Mario Ivanac
>Priority: Major
>
> Failed in a CI run
> (https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/191#A).
> No previous failures for this issue are found in JIRA and no recent WAN
> changes could be detected. Flaky?
> {noformat}
> > Task :geode-wan:distributedTest
> org.apache.geode.internal.cache.wan.offheap.ParallelWANPersistenceEnabledGatewaySenderOffHeapDUnitTest
> >
> testpersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived
> FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.wan.parallel.ParallelWANPersistenceEnabledGatewaySenderDUnitTest$$Lambda$487/908301056.run
> in VM 2 running on Host 8e35f765a792 with 8 VMs
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.internal.cache.wan.WANTestBase that uses int,
> intorg.apache.geode.cache.Region Expected region entries: 0 but actual
> entries: 20 present region keyset [3, 5, 8, 13, 16, 21, 27, 30, 35, 38, 43,
> 45, 50, 54, 58, 62, 65, 68, 73, 78] expected:<0> but was:<20> within 5
> minutes.
> Caused by:
> java.lang.AssertionError: Expected region entries: 0 but actual
> entries: 20 present region keyset [3, 5, 8, 13, 16, 21, 27, 30, 35, 38, 43,
> 45, 50, 54, 58, 62, 65, 68, 73, 78] expected:<0> but was:<20>
> 824 tests completed, 1 failed, 59 skipped
> > Task :geode-wan:distributedTest FAILED
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-8579) Locators should stop waiting for locator-wait-time if all locators contacted
Dan Smith created GEODE-8579: Summary: Locators should stop waiting for locator-wait-time if all locators contacted Key: GEODE-8579 URL: https://issues.apache.org/jira/browse/GEODE-8579 Project: Geode Issue Type: Improvement Components: membership Reporter: Dan Smith If locator-wait-time is set on one or more locators, the locators can currently end up waiting for the entire locator-wait-time before starting up, even if all locators can contact each other. If the locators can all contact each other, they should start up right away and not wait any longer, even if locator-wait-time is set. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7460) CI failure: DistributedMemberDUnitTest.testGroupsInAllVMs ForcedDisconnectException Failure
[ https://issues.apache.org/jira/browse/GEODE-7460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17208976#comment-17208976 ] Mark Hanson commented on GEODE-7460: [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/525] DistributedMemberDUnitTest > testGroupsInAllVMs FAILED =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= [http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0391/test-results/distributedTest/1601968579/] =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test report artifacts from this job are available at: [http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0391/test-artifacts/1601968579/distributedtestfiles-OpenJDK8-1.14.0-build.0391.tgz] > 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 >Affects Versions: 1.13.0, 1.14.0 >Reporter: Robert Houghton >Assignee: Bill Burcham >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > 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.apach
[jira] [Updated] (GEODE-8578) Parse PartitionResolverName in RESPONSE_CLIENT_PARTITION_ATTRIBUTES
[ https://issues.apache.org/jira/browse/GEODE-8578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8578: -- Labels: pull-request-available (was: ) > Parse PartitionResolverName in RESPONSE_CLIENT_PARTITION_ATTRIBUTES > --- > > Key: GEODE-8578 > URL: https://issues.apache.org/jira/browse/GEODE-8578 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Major > Labels: pull-request-available > > I tried the gnmsg tool with a client file connecting to a cluster that > contains a partition region with a partition resolver, which caused an > exception in the tool. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8578) Parse PartitionResolverName in RESPONSE_CLIENT_PARTITION_ATTRIBUTES
[
https://issues.apache.org/jira/browse/GEODE-8578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17208977#comment-17208977
]
ASF GitHub Bot commented on GEODE-8578:
---
alb3rtobr opened a new pull request #669:
URL: https://github.com/apache/geode-native/pull/669
I tried the gnmsg tool with a client log file connecting to a cluster that
contains a partition region with a partition resolver, which caused an
exception.
With this change, it is possible to parse the partition resolver name. Still
pending to parse the list of fixed partition attributes, maybe in other
ticket...
This is how the message looks like after parsing my log file:
```
{
"message": {
"Timestamp": "16:47:55.225776",
"Connection": "0",
"Direction": "<---",
"Type": "RESPONSE_CLIENT_PARTITION_ATTRIBUTES",
"Length": 80,
"Parts": 3,
"TransactionId": -1,
"SecurityFlag": 0,
"BucketCount": {
"Size": 5,
"IsObject": 1,
"Data": {
"DSCode": "CacheableInt32",
"Value": 113
}
},
"ColocatedWith": {
"Size": 0,
"IsObject": 0
},
"PartitionResolverName": {
"Size": 60,
"IsObject": 1,
"Data": {
"DSCode": "CacheableASCIIString",
"StringLength": 57,
"Value": "org.apache.geode.cache.util.StringPrefixPartitionResolver"
}
}
}
}
```
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Parse PartitionResolverName in RESPONSE_CLIENT_PARTITION_ATTRIBUTES
> ---
>
> Key: GEODE-8578
> URL: https://issues.apache.org/jira/browse/GEODE-8578
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Alberto Bustamante Reyes
>Assignee: Alberto Bustamante Reyes
>Priority: Major
>
> I tried the gnmsg tool with a client file connecting to a cluster that
> contains a partition region with a partition resolver, which caused an
> exception in the tool.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8567) CI Failure: ConcurrentSerialGatewaySenderOperationsDistributedTest > testRestartSerialGatewaySendersWhilePutting
[
https://issues.apache.org/jira/browse/GEODE-8567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17208981#comment-17208981
]
Mark Hanson commented on GEODE-8567:
Another failure
[https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/524]
{noformat}
org.apache.geode.internal.cache.wan.concurrent.ConcurrentSerialGatewaySenderOperationsOffHeapDistributedTest
> testRestartSerialGatewaySendersWhilePutting[1: numDispatchers=3] FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest$$Lambda$354/724101787.run
in VM 4 running on Host e3e97bd3cc72 with 8 VMs
Caused by:
org.awaitility.core.ConditionTimeoutException: Assertion condition defined as
a lambda expression in
org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest
that uses org.apache.geode.internal.cache.wan.InternalGatewaySender,
org.apache.geode.internal.cache.wan.InternalGatewaySenderint [Sender statistics
unprocessed event map size] expected:<[0]> but was:<[3]> within 5 minutes.
Caused by:
org.junit.ComparisonFailure: [Sender statistics unprocessed event map size]
expected:<[0]> but was:<[3]> {noformat}
=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0391/test-results/distributedTest/1601958075/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Test report artifacts from this job are available at:
http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0391/test-artifacts/1601958075/distributedtestfiles-OpenJDK8-1.14.0-build.0391.tgz
> CI Failure: ConcurrentSerialGatewaySenderOperationsDistributedTest >
> testRestartSerialGatewaySendersWhilePutting
>
>
> Key: GEODE-8567
> URL: https://issues.apache.org/jira/browse/GEODE-8567
> Project: Geode
> Issue Type: Improvement
> Components: wan
>Reporter: Owen Nichols
>Priority: Major
>
> ConcurrentSerialGatewaySenderOperationsDistributedTest >
> testRestartSerialGatewaySendersWhilePutting[1: numDispatchers=3] FAILED
> seen in
> [DistributedTestOpenJDK11|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/490]
> #490
> > Task :geode-wan:distributedTest
> org.apache.geode.internal.cache.wan.concurrent.ConcurrentSerialGatewaySenderOperationsDistributedTest
> > testRestartSerialGatewaySendersWhilePutting[1: numDispatchers=3] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest$$Lambda$490/0x00010094b040.run
> in VM 5 running on Host 60d64fc07216 with 8 VMs
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest
> that uses org.apache.geode.internal.cache.wan.InternalGatewaySender,
> org.apache.geode.internal.cache.wan.InternalGatewaySenderint [Sender
> statistics unprocessed event map size] expected:<[0]> but was:<[2]> within 5
> minutes.
> Caused by:
> org.junit.ComparisonFailure: [Sender statistics unprocessed event
> map size] expected:<[0]> but was:<[2]>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> [*http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0380/test-results/distributedTest/1601531249/*]
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> [*http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0380/test-artifacts/1601531249/distributedtestfiles-OpenJDK11-1.14.0-build.0380.tgz*]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8572) LogExporter throws if a directory matches its file selector
[
https://issues.apache.org/jira/browse/GEODE-8572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17208991#comment-17208991
]
ASF GitHub Bot commented on GEODE-8572:
---
jchen21 commented on a change in pull request #5595:
URL: https://github.com/apache/geode/pull/5595#discussion_r500475855
##
File path:
geode-gfsh/src/integrationTest/java/org/apache/geode/management/internal/cli/util/LogExporterIntegrationTest.java
##
@@ -50,127 +48,146 @@
@Category({GfshTest.class, LoggingTest.class})
public class LogExporterIntegrationTest {
+ @Rule
+ public ServerStarterRule server = new ServerStarterRule();
private final LogFilter filter = new LogFilter(Level.INFO, null, null);
- private LogExporter logExporter;
- private Properties properties;
-
- @Rule
- public ServerStarterRule server = new ServerStarterRule();
+ public Path serverFilesDir;
@Before
- public void before() {
-properties = new Properties();
-// make sure the server's working dir has no log files or stats file to
begin with, since in
-// some tests we are asserting on the # of log files and stats files
created by the server
-File workingDir = server.getWorkingDir();
-Arrays.stream(workingDir.listFiles())
-.filter(f -> (f.getName().endsWith(".log") ||
f.getName().endsWith(".gfs")))
-.forEach(FileUtils::deleteQuietly);
+ public void createServerFilesDir() throws IOException {
+// Name the directory after this test instance and the Gradle test worker,
to ensure that tests
+// running in parallel use different directories.
+String testRunnerID = System.getProperty("org.gradle.test.worker",
"standalone");
+int testInstanceID = System.identityHashCode(this);
+String className = getClass().getSimpleName();
+String dirName = String.format("%s-%x-%s", className, testInstanceID,
testRunnerID);
+serverFilesDir =
Files.createDirectories(Paths.get(dirName)).normalize().toAbsolutePath();
+ }
+
+ @After
+ public void deleteServerFilesDir() {
+FileUtils.deleteQuietly(serverFilesDir.toFile());
}
@Test
public void serverStartedWithWrongSuffix() throws Exception {
-properties.setProperty(LOG_FILE, new File("test.txt").getAbsolutePath());
-properties.setProperty(STATISTIC_ARCHIVE_FILE, "archive.archive");
-server.withProperties(properties).startServer();
-File serverWorkingDir = server.getWorkingDir();
-
-logExporter = new LogExporter(filter, new File(serverWorkingDir,
"test.log"),
-new File(serverWorkingDir, "stats.gfs"));
-List logFiles = logExporter.findLogFiles(serverWorkingDir.toPath());
-assertThat(logFiles).isEmpty();
-
-List statsFiles =
logExporter.findStatFiles(serverWorkingDir.toPath());
-assertThat(statsFiles).isEmpty();
+String logFileNameWithWrongSuffix = "test.txt";
+String statsFileNameWithWrongSuffix = "archive.archive";
+
+Path logFile = serverFilesDir.resolve(logFileNameWithWrongSuffix);
+Path statsFile = serverFilesDir.resolve(statsFileNameWithWrongSuffix);
+
+server.withProperty(LOG_FILE, logFile.toString())
+.withProperty(STATISTIC_ARCHIVE_FILE, statsFile.toString())
+.startServer();
+
+LogExporter logExporter = new LogExporter(filter, null, null);
+List logFiles = logExporter.findLogFiles(serverFilesDir);
+
+assertThat(logFiles)
+.as("log files")
+.isEmpty();
+
+List statsFiles = logExporter.findStatFiles(serverFilesDir);
+assertThat(statsFiles)
+.as("stat files")
+.isEmpty();
}
@Test
public void serverStartedWithCorrectSuffix() throws Exception {
-// ("relative log file is problematic in the test environment")
-properties.setProperty(LOG_FILE, new File("test.log").getAbsolutePath());
-properties.setProperty(STATISTIC_ARCHIVE_FILE, "archive.gfs");
-server.withProperties(properties).startServer();
-File serverWorkingDir = server.getWorkingDir();
-
-logExporter = new LogExporter(filter, new File(serverWorkingDir,
"test.log"),
-new File(serverWorkingDir, "archive.gfs"));
-List logFiles = logExporter.findLogFiles(serverWorkingDir.toPath());
-assertThat(logFiles).hasSize(1);
-assertThat(logFiles.get(0)).hasFileName("test.log");
-
-List statsFiles =
logExporter.findStatFiles(serverWorkingDir.toPath());
-assertThat(statsFiles).hasSize(1);
-assertThat(statsFiles.get(0)).hasFileName("archive.gfs");
+String logFileName = "test.log";
+String statsFileName = "archive.gfs";
+Path logFile = serverFilesDir.resolve(logFileName);
+Path statsFile = serverFilesDir.resolve(statsFileName);
+
+server.withProperty(LOG_FILE, logFile.toString())
+.withProperty(STATISTIC_ARCHIVE_FILE, statsFile.toString())
+.startServer();
+
+LogExporter logExporter = new LogExporter(filter, null, null);
+List logFiles = logExporter
[jira] [Commented] (GEODE-8566) Redis native tests should not also stand up a Geode server
[
https://issues.apache.org/jira/browse/GEODE-8566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209001#comment-17209001
]
Mark Hanson commented on GEODE-8566:
Another occurrence
=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0396/test-results/acceptanceTest/1602006536/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Test report artifacts from this job are available at:
http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0396/test-artifacts/1602006536/acceptancetestfiles-OpenJDK8-1.14.0-build.0396.tgz
> Redis native tests should not also stand up a Geode server
> --
>
> Key: GEODE-8566
> URL: https://issues.apache.org/jira/browse/GEODE-8566
> Project: Geode
> Issue Type: Test
> Components: redis
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> Our native acceptance tests currently extend from the integration tests and
> both classes have a {{@ClassRule}} that results in both a native (container)
> instance and a Geode instance starting up. Mostly not a problem except for
> {{PubSubNativeAcceptanceTest}} which was not testing against native redis.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8579) Locators should stop waiting for locator-wait-time if all locators contacted
[ https://issues.apache.org/jira/browse/GEODE-8579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8579: -- Labels: pull-request-available (was: ) > Locators should stop waiting for locator-wait-time if all locators contacted > > > Key: GEODE-8579 > URL: https://issues.apache.org/jira/browse/GEODE-8579 > Project: Geode > Issue Type: Improvement > Components: membership >Reporter: Dan Smith >Priority: Major > Labels: pull-request-available > > If locator-wait-time is set on one or more locators, the locators can > currently end up waiting for the entire locator-wait-time before starting up, > even if all locators can contact each other. > If the locators can all contact each other, they should start up right away > and not wait any longer, even if locator-wait-time is set. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8579) Locators should stop waiting for locator-wait-time if all locators contacted
[ https://issues.apache.org/jira/browse/GEODE-8579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209002#comment-17209002 ] ASF GitHub Bot commented on GEODE-8579: --- upthewaterspout opened a new pull request #5598: URL: https://github.com/apache/geode/pull/5598 If we can contact all other locators, we should stop waiting for locator-wait-time to elapse. Thank you for submitting a contribution to Apache Geode. In order to streamline the review of the contribution we ask you to ensure the following steps have been taken: ### For all changes: - [ ] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [ ] Has your PR been rebased against the latest commit within the target branch (typically `develop`)? - [ ] Is your initial contribution a single, squashed commit? - [ ] Does `gradlew build` run cleanly? - [ ] Have you written or updated unit tests to verify your changes? - [ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)? ### Note: Please ensure that once the PR is submitted, check Concourse for build issues and submit an update to your PR as soon as possible. If you need help, please send an email to d...@geode.apache.org. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Locators should stop waiting for locator-wait-time if all locators contacted > > > Key: GEODE-8579 > URL: https://issues.apache.org/jira/browse/GEODE-8579 > Project: Geode > Issue Type: Improvement > Components: membership >Reporter: Dan Smith >Priority: Major > > If locator-wait-time is set on one or more locators, the locators can > currently end up waiting for the entire locator-wait-time before starting up, > even if all locators can contact each other. > If the locators can all contact each other, they should start up right away > and not wait any longer, even if locator-wait-time is set. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8579) Locators should stop waiting for locator-wait-time if all locators contacted
[ https://issues.apache.org/jira/browse/GEODE-8579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209005#comment-17209005 ] ASF GitHub Bot commented on GEODE-8579: --- upthewaterspout commented on pull request #5598: URL: https://github.com/apache/geode/pull/5598#issuecomment-704445463 BTW, the actual product change is just shifting some parenthesis around in an if statement. Most of these changes have to do with moving AvailablePort so that I could write a good test. We need to be able to write a test at the membership level where two locators are started up that both know about each other (including their ports) at startup. The best way to do that is to use AvailablePort to get the ports before starting the locators. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Locators should stop waiting for locator-wait-time if all locators contacted > > > Key: GEODE-8579 > URL: https://issues.apache.org/jira/browse/GEODE-8579 > Project: Geode > Issue Type: Improvement > Components: membership >Reporter: Dan Smith >Priority: Major > Labels: pull-request-available > > If locator-wait-time is set on one or more locators, the locators can > currently end up waiting for the entire locator-wait-time before starting up, > even if all locators can contact each other. > If the locators can all contact each other, they should start up right away > and not wait any longer, even if locator-wait-time is set. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8419) SSL/TLS protocol and cipher suite configuration is ignored
[
https://issues.apache.org/jira/browse/GEODE-8419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209009#comment-17209009
]
ASF subversion and git services commented on GEODE-8419:
Commit 93a4ef9fd7af105a840e648fe878893eb5b28ab6 in geode's branch
refs/heads/feature/GEODE-8419-backport-1-13 from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=93a4ef9 ]
GEODE-8419: SSL/TLS protocol and cipher suite configuration is ignored (#5465)
* GEODE-8419: SSL/TLS protocol and cipher suite configuration is ignored
Configure cipher suites when creating an SSLEngine
* addressing test issues
* fixing error in SSLSocket endpoint validation
* addressing Jake's comments
* change test to use ArgumentCaptor - thanks Jake\!
* check captured argument content
(cherry picked from commit 537721ff815cf40eff85fde65db9b5e787471c89)
> SSL/TLS protocol and cipher suite configuration is ignored
> --
>
> Key: GEODE-8419
> URL: https://issues.apache.org/jira/browse/GEODE-8419
> Project: Geode
> Issue Type: Bug
> Components: client/server, membership, security
>Affects Versions: 1.10.0, 1.11.0, 1.12.0, 1.13.0, 1.14.0
>Reporter: Jacob Barrett
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> Configuring {{ssl-protocols}} or {{ssl-ciphers}} properties, or per-component
> ssl properties, have no effect. Configuring {{ssl-protocols}} may effect the
> {{SSLContext}} selected and limit some of the protocols allowed but does not
> restrict to just the set specified in the property. The {{ssl-ciphers}}
> property does not limit cipher selection at all.
> The result is that all ciphers allowed under the match {{SSLContext}} are
> allowed and negotiated. This can result in an unintended cipher being used in
> SSL/TLS communication.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8419) SSL/TLS protocol and cipher suite configuration is ignored
[
https://issues.apache.org/jira/browse/GEODE-8419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209010#comment-17209010
]
ASF subversion and git services commented on GEODE-8419:
Commit 93a4ef9fd7af105a840e648fe878893eb5b28ab6 in geode's branch
refs/heads/feature/GEODE-8419-backport-1-13 from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=93a4ef9 ]
GEODE-8419: SSL/TLS protocol and cipher suite configuration is ignored (#5465)
* GEODE-8419: SSL/TLS protocol and cipher suite configuration is ignored
Configure cipher suites when creating an SSLEngine
* addressing test issues
* fixing error in SSLSocket endpoint validation
* addressing Jake's comments
* change test to use ArgumentCaptor - thanks Jake\!
* check captured argument content
(cherry picked from commit 537721ff815cf40eff85fde65db9b5e787471c89)
> SSL/TLS protocol and cipher suite configuration is ignored
> --
>
> Key: GEODE-8419
> URL: https://issues.apache.org/jira/browse/GEODE-8419
> Project: Geode
> Issue Type: Bug
> Components: client/server, membership, security
>Affects Versions: 1.10.0, 1.11.0, 1.12.0, 1.13.0, 1.14.0
>Reporter: Jacob Barrett
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> Configuring {{ssl-protocols}} or {{ssl-ciphers}} properties, or per-component
> ssl properties, have no effect. Configuring {{ssl-protocols}} may effect the
> {{SSLContext}} selected and limit some of the protocols allowed but does not
> restrict to just the set specified in the property. The {{ssl-ciphers}}
> property does not limit cipher selection at all.
> The result is that all ciphers allowed under the match {{SSLContext}} are
> allowed and negotiated. This can result in an unintended cipher being used in
> SSL/TLS communication.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-8539) Update FixedPartitioningDUnitTest to use Rules and non-deprecated APIs
[ https://issues.apache.org/jira/browse/GEODE-8539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund resolved GEODE-8539. -- Fix Version/s: 1.14.0 Resolution: Fixed > Update FixedPartitioningDUnitTest to use Rules and non-deprecated APIs > -- > > Key: GEODE-8539 > URL: https://issues.apache.org/jira/browse/GEODE-8539 > Project: Geode > Issue Type: Wish > Components: regions, tests >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > Update FixedPartitioningDUnitTest to use Rules and non-deprecated APIs -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8540) Repackage DUnitBlackboard in a JUnit Rule
[ https://issues.apache.org/jira/browse/GEODE-8540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund resolved GEODE-8540. -- Fix Version/s: 1.14.0 Resolution: Fixed > Repackage DUnitBlackboard in a JUnit Rule > - > > Key: GEODE-8540 > URL: https://issues.apache.org/jira/browse/GEODE-8540 > Project: Geode > Issue Type: Wish > Components: tests >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > Repackage DUnitBlackboard in a JUnit Rule -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8252) Rename dunit rules to follow consistent naming scheme
[ https://issues.apache.org/jira/browse/GEODE-8252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund resolved GEODE-8252. -- Fix Version/s: 1.14.0 Resolution: Fixed > Rename dunit rules to follow consistent naming scheme > - > > Key: GEODE-8252 > URL: https://issues.apache.org/jira/browse/GEODE-8252 > Project: Geode > Issue Type: Improvement > Components: tests >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > Rename dunit rules to follow consistent naming scheme. The following rules > should be consistent with each other: > * DistributedRule > * DistributedRestoreSystemProperties > * DistributedExecutorServiceRule > * SharedErrorCollector > * SharedCountersRule > * CacheRule > * ClientCacheRule > * CleanupDUnitVMsRule > * CacheXmlRule -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-1383) LogBanner is missing from rolled log files
[ https://issues.apache.org/jira/browse/GEODE-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund updated GEODE-1383: - Labels: GeodeOperationAPI LogBanner observability starter (was: LogBanner observability starter) > LogBanner is missing from rolled log files > -- > > Key: GEODE-1383 > URL: https://issues.apache.org/jira/browse/GEODE-1383 > Project: Geode > Issue Type: Bug > Components: logging >Reporter: Jens Deppe >Assignee: Kirk Lund >Priority: Major > Labels: GeodeOperationAPI, LogBanner, observability, starter > > Please add gemfire,heap, xml configuration information to start of every log > file > We often have situations where we have difficulty establishing the > configuration or JVM startup arguments, or XML configuration without multiple > interactions with the customer, even when they've provided logs. When the > customer has rolled over enough, and we overwrite the "parent" first log, we > then lose all of that detail from startup that often proves very helpful. > If it would be easy to incorporate this startup configuration information > into the beginning of each log file as we rollover, we would always have it > and be able to be more productive debugging prod issues and ultimately have > happier users. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8550) Integration tests need a version of DistributedReference
[ https://issues.apache.org/jira/browse/GEODE-8550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund resolved GEODE-8550. -- Fix Version/s: 1.14.0 Resolution: Fixed > Integration tests need a version of DistributedReference > > > Key: GEODE-8550 > URL: https://issues.apache.org/jira/browse/GEODE-8550 > Project: Geode > Issue Type: Wish > Components: tests >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > Integration tests need a version of DistributedReference. This will allow > both integration and distributed tests to follow a similar approach for > closable resources. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8475) Resolve a potential dead lock in ParallelGatewaySenderQueue
[ https://issues.apache.org/jira/browse/GEODE-8475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209034#comment-17209034 ] ASF subversion and git services commented on GEODE-8475: Commit 9c22643a42de156cde149e74257047d0849db23e in geode's branch refs/heads/support/1.12 from Xiaojian Zhou [ https://gitbox.apache.org/repos/asf?p=geode.git;h=9c22643 ] GEODE-8475: Resolve a potential dead lock in ParallelGatewaySenderQueue (#5492) Co-authored-by: Darrel Schneider (cherry picked from commit b62e033af490d6f1e8f40621ff084b099f5b52e8) > Resolve a potential dead lock in ParallelGatewaySenderQueue > > > Key: GEODE-8475 > URL: https://issues.apache.org/jira/browse/GEODE-8475 > Project: Geode > Issue Type: Improvement >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.13.0, 1.14.0 > > > When brq is created but encountered a failed GII, enqueue to it could have a > potential deadlock: > Thread-1: > ParallelGatewaySenderQueue.put() will get a > brq.getInitializationLock().readLock().lock() (lock-A’s read lock). Then > during the put operation, it will try to call lockWhenRegionIsInitializing() > to get failedInitialImageLock.readLock().lock (lock-B’s read lock) > Thread-2: > PRDS.createBucketRegion() will trigger GII but failed. So it will call > cleanUpAfterFailedGII(), where it will call lockFailedInitialImageWriteLock > () to get lock-B’s write lock first. Then call > BucketRegionQueue.clearEntries(). > It will call getInitializationLock().writeLock().lock() (lock-A’s write lock). > To fix it, we need to let thread-1 to get failedInitialImageLock.readLock() > (lock-B) before requesting lock-A. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8432) use regionPath directly instead of getRegion when put event into parallelGatewaySenderQueue
[ https://issues.apache.org/jira/browse/GEODE-8432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209033#comment-17209033 ] ASF subversion and git services commented on GEODE-8432: Commit ee4ff0e4660c5d5a26a6d5f31cfa3a83cbde5024 in geode's branch refs/heads/support/1.12 from Xiaojian Zhou [ https://gitbox.apache.org/repos/asf?p=geode.git;h=ee4ff0e ] GEODE-8432: use regionPath directly instead of getRegion when put eve… (#5464) (cherry picked from commit 6f12a360d82f0de9259557af2bca34cd84e4b5f4) > use regionPath directly instead of getRegion when put event into > parallelGatewaySenderQueue > --- > > Key: GEODE-8432 > URL: https://issues.apache.org/jira/browse/GEODE-8432 > Project: Geode > Issue Type: Improvement >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.13.0, 1.14.0 > > > ParallelGatewaySenderQueue tried to put but find the value's reference to > region is null. > When the put happens, the data region might be in middle of GII. Need to > error handle this case. > It looks like the member received the reply from SyncWith message for the > queue. > But when the member tried to put the event into its own queue, and find the > local data region is not ready. (because it's in middle of GII or recovery) > The stack trace is: > at > org.apache.geode.internal.cache.CacheFactoryStatics.getAnyInstance(CacheFactoryStatics.java:85) > at > org.apache.geode.cache.CacheFactory.getAnyInstance(CacheFactory.java:396) > at > org.apache.geode.internal.cache.wan.GatewaySenderEventImpl.getRegion(GatewaySenderEventImpl.java:1217) > at > org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue.put(ParallelGatewaySenderQueue.java:696) > at > org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderEventProcessor.enqueueEvent(ParallelGatewaySenderEventProcessor.java:138) > at > org.apache.geode.internal.cache.wan.parallel.ConcurrentParallelGatewaySenderEventProcessor.enqueueEvent(ConcurrentParallelGatewaySenderEventProcessor.java:354) > at > org.apache.geode.internal.cache.wan.AbstractGatewaySender.putSynchronizationEvent(AbstractGatewaySender.java:1507) > at > org.apache.geode.internal.cache.wan.GatewaySenderQueueEntrySynchronizationOperation$GatewaySenderQueueEntrySynchronizationReplyProcessor.putSynchronizationEvents(GatewaySenderQueueEntrySynchronizationOperation.java:162) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8531) Coredump when removing an entry
[
https://issues.apache.org/jira/browse/GEODE-8531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209036#comment-17209036
]
ASF GitHub Bot commented on GEODE-8531:
---
mreddington commented on a change in pull request #667:
URL: https://github.com/apache/geode-native/pull/667#discussion_r500527381
##
File path: cppcache/integration/test/RegisterKeysTest.cpp
##
@@ -46,9 +46,11 @@ Cache createTestCache() {
.create();
}
-std::shared_ptr setupCachingProxyRegion(Cache& cache) {
+std::shared_ptr setupCachingProxyRegion(Cache& cache,
Review comment:
Prefer an overload over a default parameter. This obfuscates the code as
documentation and the meaning of all the prior tests. You're explicitly stating
concurrency checks are not to be enabled. Why is that an important condition
for the other tests? I presume what you wanted was the ability to enable checks
for your one test.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Coredump when removing an entry
> ---
>
> Key: GEODE-8531
> URL: https://issues.apache.org/jira/browse/GEODE-8531
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
> Labels: pull-request-available
> Attachments: notifications-no-massif.log
>
>
> The scenario is the following:
> *HAVING* a configured concurrency-checks-enabled=false in the
> client-cache.xml for a region
> *HAVING* a configured subscription-notification for the pool on which the
> region is defined
> *HAVING* regsitered interest on all the keys of this region, values included
> *WHEN* a LOCAL_DESTROY notification arrives and therefore
> {color:#4c9aff}MapSegment::remove{color}{color:#172b4d} is called{color}
> {color:#172b4d}*THEN* the application crashes, claiming that the variable
> entry is a nullptr.{color}
>
> This is the segmentation report:
> {code:java}
> [debug 2020/09/24 17:21:07.263036 CEST DESKTOP-3SQUK3P:586546
> 140013383710464] Region::destroy: region [/region] destroying key
> [entry-152150]
> Segmentation fault
> *** Segmentation fault
> Register dump: RAX: RBX: RCX:
>
> RDX: RSI: 7f57580008e0 RDI: 7f5767ffe670
> RBP: 7f5767ffe6c0 R8 : 7f5758000d70 R9 : 563da49f0ac0
> R10: 000c R11: 7f57815a2058 R12: 563da6971a48
> R13: 563da696dbd0 R14: R15: 7ffd06db85a0
> RSP: 7f5767ffe610 RIP: 7f578159ac47 EFLAGS: 00010202 CS: 0033
> FS: GS: Trap: 000e Error: 0004 OldMask:
> CR2: FPUCW: 037f FPUSW: TAG: 7f57
> RIP: 80b37f70 RDP: ST(0) ST(1)
>
> ST(2) ST(3)
> ST(4) ST(5) c000
> ST(6) c000 ST(7) e000 e000
> mxcsr: 1f80
> XMM0: 25252525 XMM1:
> 25252525
> XMM2: 25252525 XMM3:
> 25252525
> XMM4: 25252525 XMM5:
> 25252525
> XMM6: 25252525 XMM7:
> 25252525
> XMM8: 25252525 XMM9:
> 25252525
> XMM10: 25252525 XMM11:
> 25252525
> XMM12: 25252525 XMM13:
> 25252525
> XMM14: 25252525 XMM15:
> 25252525Backtrace:
> /usr/local/lib/libapache-geode.so(_ZN6apache5geode6client10MapSegment6removeERKSt10shared_ptrINS1_12CacheableKeyEERS3_INS1_12SerializableEERS3_INS1_12MapEntryImplEEiS3_INS1_10VersionTagEEbRb+0x287)[0x7f578159ac47]
> /usr/local/lib/libapache-geode.so(_ZN6apache5geode6client20ConcurrentEntriesMap6removeERKSt10shared_ptrINS1_12CacheableKeyEERS3_INS1_12SerializableEERS3_INS1_12MapEntryImplEEiS3_INS1_10VersionTagEEb+0xa0)[0x7f57814e1782]
> /usr/local/lib/libapache-geode.so(+0x77173d)[0x7f578157673d]
> /usr/local/lib/libapache-geode.so(_ZN6apache5geode6client11LocalRegion13updateNoThrowINS1_14DestroyActionsEEE9GfErrTypeRKSt10shared_ptrINS1_12CacheableKeyEERKS6_INS1_12SerializableEESE_RSC_iNS1_15CacheEventFlagsES6_INS1_10VersionTagEEPNS1_9DataInputES6_INS1_7EventIdEE+0x515)[0x7
[jira] [Commented] (GEODE-8572) LogExporter throws if a directory matches its file selector
[
https://issues.apache.org/jira/browse/GEODE-8572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209041#comment-17209041
]
ASF GitHub Bot commented on GEODE-8572:
---
demery-pivotal commented on a change in pull request #5595:
URL: https://github.com/apache/geode/pull/5595#discussion_r500529398
##
File path:
geode-gfsh/src/main/java/org/apache/geode/management/internal/cli/util/LogExporter.java
##
@@ -181,12 +180,13 @@ private long filterAndSize(Path originalLogFile) throws
IOException {
}
private List findFiles(Path workingDir, Predicate fileSelector)
throws IOException {
-Stream selectedFiles/* = null */;
if (!workingDir.toFile().isDirectory()) {
return Collections.emptyList();
}
-selectedFiles =
Files.list(workingDir).filter(fileSelector).filter(this.logFilter::acceptsFile);
-
-return selectedFiles.collect(toList());
+return Files.list(workingDir)
+.filter(Files::isRegularFile)
Review comment:
I hadn't thought about that. Is there a way to ensure that the path
represents a regular file without following symbolic links?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> LogExporter throws if a directory matches its file selector
> ---
>
> Key: GEODE-8572
> URL: https://issues.apache.org/jira/browse/GEODE-8572
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Affects Versions: 1.13.0
>Reporter: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> {{LogExporter}} tries to read and export any directory entry whose name is
> accepted by its log file selector predicate. The predicate accepts any entry
> whose name, when converted to lower case, contains ".log". If one of those
> entries is directory, the predicate accepts it anyway. When {{LogExporter}}
> attempts to create a {{FileReader}} read it, the {{FileReader}} constructor
> throws {{FileNotFoundException}}.
> There is a stat file selector predicate that works similarly.
> {{LogExporter}}'s log and stat file selector predicates should accept only
> files, and not directories. And perhaps the should accept only files whose
> names _end_ in the appropriate extension, rather than _containing_ the
> characters. The predicates are defined in {{LogExporter}}'s
> {{findLogFiles()}} and {{findStatFiles()}} methods.
> I discovered this defect by running {{LogExporterIntegrationTest}} on macOS.
> Each test's preparation writes some to-be-exported files into a temporary
> directory that, on macOS, may contain numerous other files and directories.
> One of those directories (e.g.
> /var/folders/yz/6y59fxln38d7lf2jxng1zgg4gn/T/com.apple.LoginUserService),
> which matches the {{LogExporter}}'s predicate.
> These tests should also be changed to write their to-be-exported files to a
> directory that is known to be empty.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8531) Coredump when removing an entry
[
https://issues.apache.org/jira/browse/GEODE-8531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209042#comment-17209042
]
ASF GitHub Bot commented on GEODE-8531:
---
mreddington commented on a change in pull request #667:
URL: https://github.com/apache/geode-native/pull/667#discussion_r500529469
##
File path: cppcache/integration/test/RegisterKeysTest.cpp
##
@@ -112,6 +114,51 @@ TEST(RegisterKeysTest, RegisterAllWithCachingRegion) {
}
}
+TEST(RegisterKeysTest, RegisterAllWithConsistencyDisabled) {
+ Cluster cluster{LocatorCount{1}, ServerCount{1}};
+
+ cluster.start();
+
+ cluster.getGfsh()
+ .create()
+ .region()
+ .withName("region")
+ .withType("PARTITION")
+ .execute();
+
+ auto producer_cache = createTestCache();
+ auto listener_cache = createTestCache();
+
+ auto producer_region = [&cluster](Cache& cache) {
Review comment:
Write it as a function. This looks like celebrating lambdas. A function
that is only ever called in one place is inlined by all the major compilers.
The lambda here obscures the code; you could have used a function with a useful
name that tells me what you're doing, now I have an unnamed function body and I
have to deduce it's meaning.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Coredump when removing an entry
> ---
>
> Key: GEODE-8531
> URL: https://issues.apache.org/jira/browse/GEODE-8531
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
> Labels: pull-request-available
> Attachments: notifications-no-massif.log
>
>
> The scenario is the following:
> *HAVING* a configured concurrency-checks-enabled=false in the
> client-cache.xml for a region
> *HAVING* a configured subscription-notification for the pool on which the
> region is defined
> *HAVING* regsitered interest on all the keys of this region, values included
> *WHEN* a LOCAL_DESTROY notification arrives and therefore
> {color:#4c9aff}MapSegment::remove{color}{color:#172b4d} is called{color}
> {color:#172b4d}*THEN* the application crashes, claiming that the variable
> entry is a nullptr.{color}
>
> This is the segmentation report:
> {code:java}
> [debug 2020/09/24 17:21:07.263036 CEST DESKTOP-3SQUK3P:586546
> 140013383710464] Region::destroy: region [/region] destroying key
> [entry-152150]
> Segmentation fault
> *** Segmentation fault
> Register dump: RAX: RBX: RCX:
>
> RDX: RSI: 7f57580008e0 RDI: 7f5767ffe670
> RBP: 7f5767ffe6c0 R8 : 7f5758000d70 R9 : 563da49f0ac0
> R10: 000c R11: 7f57815a2058 R12: 563da6971a48
> R13: 563da696dbd0 R14: R15: 7ffd06db85a0
> RSP: 7f5767ffe610 RIP: 7f578159ac47 EFLAGS: 00010202 CS: 0033
> FS: GS: Trap: 000e Error: 0004 OldMask:
> CR2: FPUCW: 037f FPUSW: TAG: 7f57
> RIP: 80b37f70 RDP: ST(0) ST(1)
>
> ST(2) ST(3)
> ST(4) ST(5) c000
> ST(6) c000 ST(7) e000 e000
> mxcsr: 1f80
> XMM0: 25252525 XMM1:
> 25252525
> XMM2: 25252525 XMM3:
> 25252525
> XMM4: 25252525 XMM5:
> 25252525
> XMM6: 25252525 XMM7:
> 25252525
> XMM8: 25252525 XMM9:
> 25252525
> XMM10: 25252525 XMM11:
> 25252525
> XMM12: 25252525 XMM13:
> 25252525
> XMM14: 25252525 XMM15:
> 25252525Backtrace:
> /usr/local/lib/libapache-geode.so(_ZN6apache5geode6client10MapSegment6removeERKSt10shared_ptrINS1_12CacheableKeyEERS3_INS1_12SerializableEERS3_INS1_12MapEntryImplEEiS3_INS1_10VersionTagEEbRb+0x287)[0x7f578159ac47]
> /usr/local/lib/libapache-geode.so(_ZN6apache5geode6client20ConcurrentEntriesMap6removeERKSt10shared_ptrINS1_12CacheableKeyEERS3_INS1_12SerializableEERS3_INS1_12MapEntryImplEEiS3_INS1_10VersionTagEEb+0xa0)[0x7f57814e1782]
> /usr/local/l
[jira] [Commented] (GEODE-8531) Coredump when removing an entry
[
https://issues.apache.org/jira/browse/GEODE-8531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209044#comment-17209044
]
ASF GitHub Bot commented on GEODE-8531:
---
mreddington commented on a change in pull request #667:
URL: https://github.com/apache/geode-native/pull/667#discussion_r500530049
##
File path: cppcache/integration/test/RegisterKeysTest.cpp
##
@@ -112,6 +114,51 @@ TEST(RegisterKeysTest, RegisterAllWithCachingRegion) {
}
}
+TEST(RegisterKeysTest, RegisterAllWithConsistencyDisabled) {
+ Cluster cluster{LocatorCount{1}, ServerCount{1}};
+
+ cluster.start();
+
+ cluster.getGfsh()
+ .create()
+ .region()
+ .withName("region")
+ .withType("PARTITION")
+ .execute();
+
+ auto producer_cache = createTestCache();
+ auto listener_cache = createTestCache();
+
+ auto producer_region = [&cluster](Cache& cache) {
+auto poolFactory = cache.getPoolManager().createFactory();
+cluster.applyLocators(poolFactory);
+poolFactory.create("default");
+return setupProxyRegion(cache);
+ }(producer_cache);
+
+ auto listener_region = [&cluster](Cache& cache) {
Review comment:
Write it as a function.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Coredump when removing an entry
> ---
>
> Key: GEODE-8531
> URL: https://issues.apache.org/jira/browse/GEODE-8531
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
> Labels: pull-request-available
> Attachments: notifications-no-massif.log
>
>
> The scenario is the following:
> *HAVING* a configured concurrency-checks-enabled=false in the
> client-cache.xml for a region
> *HAVING* a configured subscription-notification for the pool on which the
> region is defined
> *HAVING* regsitered interest on all the keys of this region, values included
> *WHEN* a LOCAL_DESTROY notification arrives and therefore
> {color:#4c9aff}MapSegment::remove{color}{color:#172b4d} is called{color}
> {color:#172b4d}*THEN* the application crashes, claiming that the variable
> entry is a nullptr.{color}
>
> This is the segmentation report:
> {code:java}
> [debug 2020/09/24 17:21:07.263036 CEST DESKTOP-3SQUK3P:586546
> 140013383710464] Region::destroy: region [/region] destroying key
> [entry-152150]
> Segmentation fault
> *** Segmentation fault
> Register dump: RAX: RBX: RCX:
>
> RDX: RSI: 7f57580008e0 RDI: 7f5767ffe670
> RBP: 7f5767ffe6c0 R8 : 7f5758000d70 R9 : 563da49f0ac0
> R10: 000c R11: 7f57815a2058 R12: 563da6971a48
> R13: 563da696dbd0 R14: R15: 7ffd06db85a0
> RSP: 7f5767ffe610 RIP: 7f578159ac47 EFLAGS: 00010202 CS: 0033
> FS: GS: Trap: 000e Error: 0004 OldMask:
> CR2: FPUCW: 037f FPUSW: TAG: 7f57
> RIP: 80b37f70 RDP: ST(0) ST(1)
>
> ST(2) ST(3)
> ST(4) ST(5) c000
> ST(6) c000 ST(7) e000 e000
> mxcsr: 1f80
> XMM0: 25252525 XMM1:
> 25252525
> XMM2: 25252525 XMM3:
> 25252525
> XMM4: 25252525 XMM5:
> 25252525
> XMM6: 25252525 XMM7:
> 25252525
> XMM8: 25252525 XMM9:
> 25252525
> XMM10: 25252525 XMM11:
> 25252525
> XMM12: 25252525 XMM13:
> 25252525
> XMM14: 25252525 XMM15:
> 25252525Backtrace:
> /usr/local/lib/libapache-geode.so(_ZN6apache5geode6client10MapSegment6removeERKSt10shared_ptrINS1_12CacheableKeyEERS3_INS1_12SerializableEERS3_INS1_12MapEntryImplEEiS3_INS1_10VersionTagEEbRb+0x287)[0x7f578159ac47]
> /usr/local/lib/libapache-geode.so(_ZN6apache5geode6client20ConcurrentEntriesMap6removeERKSt10shared_ptrINS1_12CacheableKeyEERS3_INS1_12SerializableEERS3_INS1_12MapEntryImplEEiS3_INS1_10VersionTagEEb+0xa0)[0x7f57814e1782]
> /usr/local/lib/libapache-geode.so(+0x77173d)[0x7f578157673d]
> /usr/local/l
[jira] [Commented] (GEODE-8572) LogExporter throws if a directory matches its file selector
[
https://issues.apache.org/jira/browse/GEODE-8572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209045#comment-17209045
]
ASF GitHub Bot commented on GEODE-8572:
---
demery-pivotal commented on a change in pull request #5595:
URL: https://github.com/apache/geode/pull/5595#discussion_r500530806
##
File path:
geode-gfsh/src/integrationTest/java/org/apache/geode/management/internal/cli/util/LogExporterIntegrationTest.java
##
@@ -50,127 +48,146 @@
@Category({GfshTest.class, LoggingTest.class})
public class LogExporterIntegrationTest {
+ @Rule
+ public ServerStarterRule server = new ServerStarterRule();
private final LogFilter filter = new LogFilter(Level.INFO, null, null);
- private LogExporter logExporter;
- private Properties properties;
-
- @Rule
- public ServerStarterRule server = new ServerStarterRule();
+ public Path serverFilesDir;
@Before
- public void before() {
-properties = new Properties();
-// make sure the server's working dir has no log files or stats file to
begin with, since in
-// some tests we are asserting on the # of log files and stats files
created by the server
-File workingDir = server.getWorkingDir();
-Arrays.stream(workingDir.listFiles())
-.filter(f -> (f.getName().endsWith(".log") ||
f.getName().endsWith(".gfs")))
-.forEach(FileUtils::deleteQuietly);
+ public void createServerFilesDir() throws IOException {
+// Name the directory after this test instance and the Gradle test worker,
to ensure that tests
+// running in parallel use different directories.
+String testRunnerID = System.getProperty("org.gradle.test.worker",
"standalone");
+int testInstanceID = System.identityHashCode(this);
+String className = getClass().getSimpleName();
+String dirName = String.format("%s-%x-%s", className, testInstanceID,
testRunnerID);
+serverFilesDir =
Files.createDirectories(Paths.get(dirName)).normalize().toAbsolutePath();
+ }
+
+ @After
+ public void deleteServerFilesDir() {
+FileUtils.deleteQuietly(serverFilesDir.toFile());
}
@Test
public void serverStartedWithWrongSuffix() throws Exception {
-properties.setProperty(LOG_FILE, new File("test.txt").getAbsolutePath());
-properties.setProperty(STATISTIC_ARCHIVE_FILE, "archive.archive");
-server.withProperties(properties).startServer();
-File serverWorkingDir = server.getWorkingDir();
-
-logExporter = new LogExporter(filter, new File(serverWorkingDir,
"test.log"),
-new File(serverWorkingDir, "stats.gfs"));
-List logFiles = logExporter.findLogFiles(serverWorkingDir.toPath());
-assertThat(logFiles).isEmpty();
-
-List statsFiles =
logExporter.findStatFiles(serverWorkingDir.toPath());
-assertThat(statsFiles).isEmpty();
+String logFileNameWithWrongSuffix = "test.txt";
+String statsFileNameWithWrongSuffix = "archive.archive";
+
+Path logFile = serverFilesDir.resolve(logFileNameWithWrongSuffix);
+Path statsFile = serverFilesDir.resolve(statsFileNameWithWrongSuffix);
+
+server.withProperty(LOG_FILE, logFile.toString())
+.withProperty(STATISTIC_ARCHIVE_FILE, statsFile.toString())
+.startServer();
+
+LogExporter logExporter = new LogExporter(filter, null, null);
+List logFiles = logExporter.findLogFiles(serverFilesDir);
+
+assertThat(logFiles)
+.as("log files")
+.isEmpty();
+
+List statsFiles = logExporter.findStatFiles(serverFilesDir);
+assertThat(statsFiles)
+.as("stat files")
+.isEmpty();
}
@Test
public void serverStartedWithCorrectSuffix() throws Exception {
-// ("relative log file is problematic in the test environment")
-properties.setProperty(LOG_FILE, new File("test.log").getAbsolutePath());
-properties.setProperty(STATISTIC_ARCHIVE_FILE, "archive.gfs");
-server.withProperties(properties).startServer();
-File serverWorkingDir = server.getWorkingDir();
-
-logExporter = new LogExporter(filter, new File(serverWorkingDir,
"test.log"),
-new File(serverWorkingDir, "archive.gfs"));
-List logFiles = logExporter.findLogFiles(serverWorkingDir.toPath());
-assertThat(logFiles).hasSize(1);
-assertThat(logFiles.get(0)).hasFileName("test.log");
-
-List statsFiles =
logExporter.findStatFiles(serverWorkingDir.toPath());
-assertThat(statsFiles).hasSize(1);
-assertThat(statsFiles.get(0)).hasFileName("archive.gfs");
+String logFileName = "test.log";
+String statsFileName = "archive.gfs";
+Path logFile = serverFilesDir.resolve(logFileName);
+Path statsFile = serverFilesDir.resolve(statsFileName);
+
+server.withProperty(LOG_FILE, logFile.toString())
+.withProperty(STATISTIC_ARCHIVE_FILE, statsFile.toString())
+.startServer();
+
+LogExporter logExporter = new LogExporter(filter, null, null);
+List logFiles = logE
[jira] [Commented] (GEODE-8531) Coredump when removing an entry
[
https://issues.apache.org/jira/browse/GEODE-8531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209049#comment-17209049
]
ASF GitHub Bot commented on GEODE-8531:
---
mreddington commented on a change in pull request #667:
URL: https://github.com/apache/geode-native/pull/667#discussion_r500531805
##
File path: cppcache/integration/test/RegisterKeysTest.cpp
##
@@ -112,6 +114,51 @@ TEST(RegisterKeysTest, RegisterAllWithCachingRegion) {
}
}
+TEST(RegisterKeysTest, RegisterAllWithConsistencyDisabled) {
+ Cluster cluster{LocatorCount{1}, ServerCount{1}};
+
+ cluster.start();
+
+ cluster.getGfsh()
+ .create()
+ .region()
+ .withName("region")
+ .withType("PARTITION")
+ .execute();
+
+ auto producer_cache = createTestCache();
+ auto listener_cache = createTestCache();
+
+ auto producer_region = [&cluster](Cache& cache) {
+auto poolFactory = cache.getPoolManager().createFactory();
+cluster.applyLocators(poolFactory);
+poolFactory.create("default");
+return setupProxyRegion(cache);
+ }(producer_cache);
+
+ auto listener_region = [&cluster](Cache& cache) {
+auto poolFactory =
+cache.getPoolManager().createFactory().setSubscriptionEnabled(true);
+cluster.applyLocators(poolFactory);
+poolFactory.create("default");
+auto region = setupCachingProxyRegion(cache, false);
+region->registerAllKeys();
+return region;
+ }(listener_cache);
+
+ ASSERT_FALSE(listener_region->containsValueForKey("one"));
Review comment:
No need to establish a new, empty region, that cannot possibly have any
preloaded data in it is indeed empty.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Coredump when removing an entry
> ---
>
> Key: GEODE-8531
> URL: https://issues.apache.org/jira/browse/GEODE-8531
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
> Labels: pull-request-available
> Attachments: notifications-no-massif.log
>
>
> The scenario is the following:
> *HAVING* a configured concurrency-checks-enabled=false in the
> client-cache.xml for a region
> *HAVING* a configured subscription-notification for the pool on which the
> region is defined
> *HAVING* regsitered interest on all the keys of this region, values included
> *WHEN* a LOCAL_DESTROY notification arrives and therefore
> {color:#4c9aff}MapSegment::remove{color}{color:#172b4d} is called{color}
> {color:#172b4d}*THEN* the application crashes, claiming that the variable
> entry is a nullptr.{color}
>
> This is the segmentation report:
> {code:java}
> [debug 2020/09/24 17:21:07.263036 CEST DESKTOP-3SQUK3P:586546
> 140013383710464] Region::destroy: region [/region] destroying key
> [entry-152150]
> Segmentation fault
> *** Segmentation fault
> Register dump: RAX: RBX: RCX:
>
> RDX: RSI: 7f57580008e0 RDI: 7f5767ffe670
> RBP: 7f5767ffe6c0 R8 : 7f5758000d70 R9 : 563da49f0ac0
> R10: 000c R11: 7f57815a2058 R12: 563da6971a48
> R13: 563da696dbd0 R14: R15: 7ffd06db85a0
> RSP: 7f5767ffe610 RIP: 7f578159ac47 EFLAGS: 00010202 CS: 0033
> FS: GS: Trap: 000e Error: 0004 OldMask:
> CR2: FPUCW: 037f FPUSW: TAG: 7f57
> RIP: 80b37f70 RDP: ST(0) ST(1)
>
> ST(2) ST(3)
> ST(4) ST(5) c000
> ST(6) c000 ST(7) e000 e000
> mxcsr: 1f80
> XMM0: 25252525 XMM1:
> 25252525
> XMM2: 25252525 XMM3:
> 25252525
> XMM4: 25252525 XMM5:
> 25252525
> XMM6: 25252525 XMM7:
> 25252525
> XMM8: 25252525 XMM9:
> 25252525
> XMM10: 25252525 XMM11:
> 25252525
> XMM12: 25252525 XMM13:
> 25252525
> XMM14: 25252525 XMM15:
> 25252525Backtrace:
> /usr/local/lib/libapache-geode.so(_ZN6apache5geode6c
[jira] [Commented] (GEODE-8531) Coredump when removing an entry
[
https://issues.apache.org/jira/browse/GEODE-8531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209056#comment-17209056
]
ASF GitHub Bot commented on GEODE-8531:
---
mreddington commented on a change in pull request #667:
URL: https://github.com/apache/geode-native/pull/667#discussion_r500535449
##
File path: cppcache/integration/test/RegisterKeysTest.cpp
##
@@ -112,6 +114,51 @@ TEST(RegisterKeysTest, RegisterAllWithCachingRegion) {
}
}
+TEST(RegisterKeysTest, RegisterAllWithConsistencyDisabled) {
+ Cluster cluster{LocatorCount{1}, ServerCount{1}};
+
+ cluster.start();
+
+ cluster.getGfsh()
+ .create()
+ .region()
+ .withName("region")
+ .withType("PARTITION")
+ .execute();
+
+ auto producer_cache = createTestCache();
+ auto listener_cache = createTestCache();
+
+ auto producer_region = [&cluster](Cache& cache) {
+auto poolFactory = cache.getPoolManager().createFactory();
+cluster.applyLocators(poolFactory);
+poolFactory.create("default");
+return setupProxyRegion(cache);
+ }(producer_cache);
+
+ auto listener_region = [&cluster](Cache& cache) {
+auto poolFactory =
+cache.getPoolManager().createFactory().setSubscriptionEnabled(true);
+cluster.applyLocators(poolFactory);
+poolFactory.create("default");
+auto region = setupCachingProxyRegion(cache, false);
+region->registerAllKeys();
+return region;
+ }(listener_cache);
+
+ ASSERT_FALSE(listener_region->containsValueForKey("one"));
+
+ producer_region->put("one", std::make_shared(1));
+ std::this_thread::sleep_for(std::chrono::seconds(5));
+
+ ASSERT_TRUE(listener_region->containsValueForKey("one"));
+
+ producer_region->destroy("one");
+ std::this_thread::sleep_for(std::chrono::seconds(5));
Review comment:
Again, this should be unnecessary.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Coredump when removing an entry
> ---
>
> Key: GEODE-8531
> URL: https://issues.apache.org/jira/browse/GEODE-8531
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
> Labels: pull-request-available
> Attachments: notifications-no-massif.log
>
>
> The scenario is the following:
> *HAVING* a configured concurrency-checks-enabled=false in the
> client-cache.xml for a region
> *HAVING* a configured subscription-notification for the pool on which the
> region is defined
> *HAVING* regsitered interest on all the keys of this region, values included
> *WHEN* a LOCAL_DESTROY notification arrives and therefore
> {color:#4c9aff}MapSegment::remove{color}{color:#172b4d} is called{color}
> {color:#172b4d}*THEN* the application crashes, claiming that the variable
> entry is a nullptr.{color}
>
> This is the segmentation report:
> {code:java}
> [debug 2020/09/24 17:21:07.263036 CEST DESKTOP-3SQUK3P:586546
> 140013383710464] Region::destroy: region [/region] destroying key
> [entry-152150]
> Segmentation fault
> *** Segmentation fault
> Register dump: RAX: RBX: RCX:
>
> RDX: RSI: 7f57580008e0 RDI: 7f5767ffe670
> RBP: 7f5767ffe6c0 R8 : 7f5758000d70 R9 : 563da49f0ac0
> R10: 000c R11: 7f57815a2058 R12: 563da6971a48
> R13: 563da696dbd0 R14: R15: 7ffd06db85a0
> RSP: 7f5767ffe610 RIP: 7f578159ac47 EFLAGS: 00010202 CS: 0033
> FS: GS: Trap: 000e Error: 0004 OldMask:
> CR2: FPUCW: 037f FPUSW: TAG: 7f57
> RIP: 80b37f70 RDP: ST(0) ST(1)
>
> ST(2) ST(3)
> ST(4) ST(5) c000
> ST(6) c000 ST(7) e000 e000
> mxcsr: 1f80
> XMM0: 25252525 XMM1:
> 25252525
> XMM2: 25252525 XMM3:
> 25252525
> XMM4: 25252525 XMM5:
> 25252525
> XMM6: 25252525 XMM7:
> 25252525
> XMM8: 25252525 XMM9:
> 25252525
> XMM10: 25252525 XMM11:
> 25252525
> XMM12: 25252525
[jira] [Commented] (GEODE-8531) Coredump when removing an entry
[
https://issues.apache.org/jira/browse/GEODE-8531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209055#comment-17209055
]
ASF GitHub Bot commented on GEODE-8531:
---
mreddington commented on a change in pull request #667:
URL: https://github.com/apache/geode-native/pull/667#discussion_r500535319
##
File path: cppcache/integration/test/RegisterKeysTest.cpp
##
@@ -112,6 +114,51 @@ TEST(RegisterKeysTest, RegisterAllWithCachingRegion) {
}
}
+TEST(RegisterKeysTest, RegisterAllWithConsistencyDisabled) {
+ Cluster cluster{LocatorCount{1}, ServerCount{1}};
+
+ cluster.start();
+
+ cluster.getGfsh()
+ .create()
+ .region()
+ .withName("region")
+ .withType("PARTITION")
+ .execute();
+
+ auto producer_cache = createTestCache();
+ auto listener_cache = createTestCache();
+
+ auto producer_region = [&cluster](Cache& cache) {
+auto poolFactory = cache.getPoolManager().createFactory();
+cluster.applyLocators(poolFactory);
+poolFactory.create("default");
+return setupProxyRegion(cache);
+ }(producer_cache);
+
+ auto listener_region = [&cluster](Cache& cache) {
+auto poolFactory =
+cache.getPoolManager().createFactory().setSubscriptionEnabled(true);
+cluster.applyLocators(poolFactory);
+poolFactory.create("default");
+auto region = setupCachingProxyRegion(cache, false);
+region->registerAllKeys();
+return region;
+ }(listener_cache);
+
+ ASSERT_FALSE(listener_region->containsValueForKey("one"));
+
+ producer_region->put("one", std::make_shared(1));
+ std::this_thread::sleep_for(std::chrono::seconds(5));
Review comment:
Correct me if I'm wrong, but this delay should be unnecessary.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Coredump when removing an entry
> ---
>
> Key: GEODE-8531
> URL: https://issues.apache.org/jira/browse/GEODE-8531
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
> Labels: pull-request-available
> Attachments: notifications-no-massif.log
>
>
> The scenario is the following:
> *HAVING* a configured concurrency-checks-enabled=false in the
> client-cache.xml for a region
> *HAVING* a configured subscription-notification for the pool on which the
> region is defined
> *HAVING* regsitered interest on all the keys of this region, values included
> *WHEN* a LOCAL_DESTROY notification arrives and therefore
> {color:#4c9aff}MapSegment::remove{color}{color:#172b4d} is called{color}
> {color:#172b4d}*THEN* the application crashes, claiming that the variable
> entry is a nullptr.{color}
>
> This is the segmentation report:
> {code:java}
> [debug 2020/09/24 17:21:07.263036 CEST DESKTOP-3SQUK3P:586546
> 140013383710464] Region::destroy: region [/region] destroying key
> [entry-152150]
> Segmentation fault
> *** Segmentation fault
> Register dump: RAX: RBX: RCX:
>
> RDX: RSI: 7f57580008e0 RDI: 7f5767ffe670
> RBP: 7f5767ffe6c0 R8 : 7f5758000d70 R9 : 563da49f0ac0
> R10: 000c R11: 7f57815a2058 R12: 563da6971a48
> R13: 563da696dbd0 R14: R15: 7ffd06db85a0
> RSP: 7f5767ffe610 RIP: 7f578159ac47 EFLAGS: 00010202 CS: 0033
> FS: GS: Trap: 000e Error: 0004 OldMask:
> CR2: FPUCW: 037f FPUSW: TAG: 7f57
> RIP: 80b37f70 RDP: ST(0) ST(1)
>
> ST(2) ST(3)
> ST(4) ST(5) c000
> ST(6) c000 ST(7) e000 e000
> mxcsr: 1f80
> XMM0: 25252525 XMM1:
> 25252525
> XMM2: 25252525 XMM3:
> 25252525
> XMM4: 25252525 XMM5:
> 25252525
> XMM6: 25252525 XMM7:
> 25252525
> XMM8: 25252525 XMM9:
> 25252525
> XMM10: 25252525 XMM11:
> 25252525
> XMM12: 25252525 XMM13:
> 25252525
> XMM14: 25252525 XMM15:
> 25252525B
[jira] [Commented] (GEODE-8531) Coredump when removing an entry
[
https://issues.apache.org/jira/browse/GEODE-8531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209059#comment-17209059
]
ASF GitHub Bot commented on GEODE-8531:
---
gaussianrecurrence commented on a change in pull request #667:
URL: https://github.com/apache/geode-native/pull/667#discussion_r500536104
##
File path: cppcache/integration/test/RegisterKeysTest.cpp
##
@@ -112,6 +114,51 @@ TEST(RegisterKeysTest, RegisterAllWithCachingRegion) {
}
}
+TEST(RegisterKeysTest, RegisterAllWithConsistencyDisabled) {
+ Cluster cluster{LocatorCount{1}, ServerCount{1}};
+
+ cluster.start();
+
+ cluster.getGfsh()
+ .create()
+ .region()
+ .withName("region")
+ .withType("PARTITION")
+ .execute();
+
+ auto producer_cache = createTestCache();
+ auto listener_cache = createTestCache();
+
+ auto producer_region = [&cluster](Cache& cache) {
+auto poolFactory = cache.getPoolManager().createFactory();
+cluster.applyLocators(poolFactory);
+poolFactory.create("default");
+return setupProxyRegion(cache);
+ }(producer_cache);
+
+ auto listener_region = [&cluster](Cache& cache) {
+auto poolFactory =
+cache.getPoolManager().createFactory().setSubscriptionEnabled(true);
+cluster.applyLocators(poolFactory);
+poolFactory.create("default");
+auto region = setupCachingProxyRegion(cache, false);
+region->registerAllKeys();
+return region;
+ }(listener_cache);
+
+ ASSERT_FALSE(listener_region->containsValueForKey("one"));
Review comment:
Yes, indeed, this is overtesting
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Coredump when removing an entry
> ---
>
> Key: GEODE-8531
> URL: https://issues.apache.org/jira/browse/GEODE-8531
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
> Labels: pull-request-available
> Attachments: notifications-no-massif.log
>
>
> The scenario is the following:
> *HAVING* a configured concurrency-checks-enabled=false in the
> client-cache.xml for a region
> *HAVING* a configured subscription-notification for the pool on which the
> region is defined
> *HAVING* regsitered interest on all the keys of this region, values included
> *WHEN* a LOCAL_DESTROY notification arrives and therefore
> {color:#4c9aff}MapSegment::remove{color}{color:#172b4d} is called{color}
> {color:#172b4d}*THEN* the application crashes, claiming that the variable
> entry is a nullptr.{color}
>
> This is the segmentation report:
> {code:java}
> [debug 2020/09/24 17:21:07.263036 CEST DESKTOP-3SQUK3P:586546
> 140013383710464] Region::destroy: region [/region] destroying key
> [entry-152150]
> Segmentation fault
> *** Segmentation fault
> Register dump: RAX: RBX: RCX:
>
> RDX: RSI: 7f57580008e0 RDI: 7f5767ffe670
> RBP: 7f5767ffe6c0 R8 : 7f5758000d70 R9 : 563da49f0ac0
> R10: 000c R11: 7f57815a2058 R12: 563da6971a48
> R13: 563da696dbd0 R14: R15: 7ffd06db85a0
> RSP: 7f5767ffe610 RIP: 7f578159ac47 EFLAGS: 00010202 CS: 0033
> FS: GS: Trap: 000e Error: 0004 OldMask:
> CR2: FPUCW: 037f FPUSW: TAG: 7f57
> RIP: 80b37f70 RDP: ST(0) ST(1)
>
> ST(2) ST(3)
> ST(4) ST(5) c000
> ST(6) c000 ST(7) e000 e000
> mxcsr: 1f80
> XMM0: 25252525 XMM1:
> 25252525
> XMM2: 25252525 XMM3:
> 25252525
> XMM4: 25252525 XMM5:
> 25252525
> XMM6: 25252525 XMM7:
> 25252525
> XMM8: 25252525 XMM9:
> 25252525
> XMM10: 25252525 XMM11:
> 25252525
> XMM12: 25252525 XMM13:
> 25252525
> XMM14: 25252525 XMM15:
> 25252525Backtrace:
> /usr/local/lib/libapache-geode.so(_ZN6apache5geode6client10MapSegment6removeERKSt10shared_ptrINS1_12CacheableKeyEERS3_INS1_
[jira] [Commented] (GEODE-8531) Coredump when removing an entry
[
https://issues.apache.org/jira/browse/GEODE-8531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209058#comment-17209058
]
ASF GitHub Bot commented on GEODE-8531:
---
gaussianrecurrence commented on a change in pull request #667:
URL: https://github.com/apache/geode-native/pull/667#discussion_r500535923
##
File path: cppcache/integration/test/RegisterKeysTest.cpp
##
@@ -112,6 +114,51 @@ TEST(RegisterKeysTest, RegisterAllWithCachingRegion) {
}
}
+TEST(RegisterKeysTest, RegisterAllWithConsistencyDisabled) {
+ Cluster cluster{LocatorCount{1}, ServerCount{1}};
+
+ cluster.start();
+
+ cluster.getGfsh()
+ .create()
+ .region()
+ .withName("region")
+ .withType("PARTITION")
+ .execute();
+
+ auto producer_cache = createTestCache();
+ auto listener_cache = createTestCache();
+
+ auto producer_region = [&cluster](Cache& cache) {
+auto poolFactory = cache.getPoolManager().createFactory();
+cluster.applyLocators(poolFactory);
+poolFactory.create("default");
+return setupProxyRegion(cache);
+ }(producer_cache);
+
+ auto listener_region = [&cluster](Cache& cache) {
Review comment:
Got it :)
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Coredump when removing an entry
> ---
>
> Key: GEODE-8531
> URL: https://issues.apache.org/jira/browse/GEODE-8531
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
> Labels: pull-request-available
> Attachments: notifications-no-massif.log
>
>
> The scenario is the following:
> *HAVING* a configured concurrency-checks-enabled=false in the
> client-cache.xml for a region
> *HAVING* a configured subscription-notification for the pool on which the
> region is defined
> *HAVING* regsitered interest on all the keys of this region, values included
> *WHEN* a LOCAL_DESTROY notification arrives and therefore
> {color:#4c9aff}MapSegment::remove{color}{color:#172b4d} is called{color}
> {color:#172b4d}*THEN* the application crashes, claiming that the variable
> entry is a nullptr.{color}
>
> This is the segmentation report:
> {code:java}
> [debug 2020/09/24 17:21:07.263036 CEST DESKTOP-3SQUK3P:586546
> 140013383710464] Region::destroy: region [/region] destroying key
> [entry-152150]
> Segmentation fault
> *** Segmentation fault
> Register dump: RAX: RBX: RCX:
>
> RDX: RSI: 7f57580008e0 RDI: 7f5767ffe670
> RBP: 7f5767ffe6c0 R8 : 7f5758000d70 R9 : 563da49f0ac0
> R10: 000c R11: 7f57815a2058 R12: 563da6971a48
> R13: 563da696dbd0 R14: R15: 7ffd06db85a0
> RSP: 7f5767ffe610 RIP: 7f578159ac47 EFLAGS: 00010202 CS: 0033
> FS: GS: Trap: 000e Error: 0004 OldMask:
> CR2: FPUCW: 037f FPUSW: TAG: 7f57
> RIP: 80b37f70 RDP: ST(0) ST(1)
>
> ST(2) ST(3)
> ST(4) ST(5) c000
> ST(6) c000 ST(7) e000 e000
> mxcsr: 1f80
> XMM0: 25252525 XMM1:
> 25252525
> XMM2: 25252525 XMM3:
> 25252525
> XMM4: 25252525 XMM5:
> 25252525
> XMM6: 25252525 XMM7:
> 25252525
> XMM8: 25252525 XMM9:
> 25252525
> XMM10: 25252525 XMM11:
> 25252525
> XMM12: 25252525 XMM13:
> 25252525
> XMM14: 25252525 XMM15:
> 25252525Backtrace:
> /usr/local/lib/libapache-geode.so(_ZN6apache5geode6client10MapSegment6removeERKSt10shared_ptrINS1_12CacheableKeyEERS3_INS1_12SerializableEERS3_INS1_12MapEntryImplEEiS3_INS1_10VersionTagEEbRb+0x287)[0x7f578159ac47]
> /usr/local/lib/libapache-geode.so(_ZN6apache5geode6client20ConcurrentEntriesMap6removeERKSt10shared_ptrINS1_12CacheableKeyEERS3_INS1_12SerializableEERS3_INS1_12MapEntryImplEEiS3_INS1_10VersionTagEEb+0xa0)[0x7f57814e1782]
> /usr/local/lib/libapache-geode.so(+0x77173d)[0x7f578157673d]
> /usr/local/lib/liba
[jira] [Commented] (GEODE-8531) Coredump when removing an entry
[
https://issues.apache.org/jira/browse/GEODE-8531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209057#comment-17209057
]
ASF GitHub Bot commented on GEODE-8531:
---
gaussianrecurrence commented on a change in pull request #667:
URL: https://github.com/apache/geode-native/pull/667#discussion_r500535836
##
File path: cppcache/integration/test/RegisterKeysTest.cpp
##
@@ -46,9 +46,11 @@ Cache createTestCache() {
.create();
}
-std::shared_ptr setupCachingProxyRegion(Cache& cache) {
+std::shared_ptr setupCachingProxyRegion(Cache& cache,
Review comment:
You have a good point indeed. Noted :)
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Coredump when removing an entry
> ---
>
> Key: GEODE-8531
> URL: https://issues.apache.org/jira/browse/GEODE-8531
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
> Labels: pull-request-available
> Attachments: notifications-no-massif.log
>
>
> The scenario is the following:
> *HAVING* a configured concurrency-checks-enabled=false in the
> client-cache.xml for a region
> *HAVING* a configured subscription-notification for the pool on which the
> region is defined
> *HAVING* regsitered interest on all the keys of this region, values included
> *WHEN* a LOCAL_DESTROY notification arrives and therefore
> {color:#4c9aff}MapSegment::remove{color}{color:#172b4d} is called{color}
> {color:#172b4d}*THEN* the application crashes, claiming that the variable
> entry is a nullptr.{color}
>
> This is the segmentation report:
> {code:java}
> [debug 2020/09/24 17:21:07.263036 CEST DESKTOP-3SQUK3P:586546
> 140013383710464] Region::destroy: region [/region] destroying key
> [entry-152150]
> Segmentation fault
> *** Segmentation fault
> Register dump: RAX: RBX: RCX:
>
> RDX: RSI: 7f57580008e0 RDI: 7f5767ffe670
> RBP: 7f5767ffe6c0 R8 : 7f5758000d70 R9 : 563da49f0ac0
> R10: 000c R11: 7f57815a2058 R12: 563da6971a48
> R13: 563da696dbd0 R14: R15: 7ffd06db85a0
> RSP: 7f5767ffe610 RIP: 7f578159ac47 EFLAGS: 00010202 CS: 0033
> FS: GS: Trap: 000e Error: 0004 OldMask:
> CR2: FPUCW: 037f FPUSW: TAG: 7f57
> RIP: 80b37f70 RDP: ST(0) ST(1)
>
> ST(2) ST(3)
> ST(4) ST(5) c000
> ST(6) c000 ST(7) e000 e000
> mxcsr: 1f80
> XMM0: 25252525 XMM1:
> 25252525
> XMM2: 25252525 XMM3:
> 25252525
> XMM4: 25252525 XMM5:
> 25252525
> XMM6: 25252525 XMM7:
> 25252525
> XMM8: 25252525 XMM9:
> 25252525
> XMM10: 25252525 XMM11:
> 25252525
> XMM12: 25252525 XMM13:
> 25252525
> XMM14: 25252525 XMM15:
> 25252525Backtrace:
> /usr/local/lib/libapache-geode.so(_ZN6apache5geode6client10MapSegment6removeERKSt10shared_ptrINS1_12CacheableKeyEERS3_INS1_12SerializableEERS3_INS1_12MapEntryImplEEiS3_INS1_10VersionTagEEbRb+0x287)[0x7f578159ac47]
> /usr/local/lib/libapache-geode.so(_ZN6apache5geode6client20ConcurrentEntriesMap6removeERKSt10shared_ptrINS1_12CacheableKeyEERS3_INS1_12SerializableEERS3_INS1_12MapEntryImplEEiS3_INS1_10VersionTagEEb+0xa0)[0x7f57814e1782]
> /usr/local/lib/libapache-geode.so(+0x77173d)[0x7f578157673d]
> /usr/local/lib/libapache-geode.so(_ZN6apache5geode6client11LocalRegion13updateNoThrowINS1_14DestroyActionsEEE9GfErrTypeRKSt10shared_ptrINS1_12CacheableKeyEERKS6_INS1_12SerializableEESE_RSC_iNS1_15CacheEventFlagsES6_INS1_10VersionTagEEPNS1_9DataInputES6_INS1_7EventIdEE+0x515)[0x7f578157af2b]
> /usr/local/lib/libapache-geode.so(_ZN6apache5geode6client11LocalRegion14destroyNoThrowERKSt10shared_ptrINS1_12CacheableKeyEERKS3_INS1_12SerializableEEiNS1_15CacheEventFlagsES3_INS1_10VersionTagEE+0xae)[0x7f578156cf9a]
> /usr/local/lib/libapache-geode.so(_ZN6apache5geode6c
[jira] [Commented] (GEODE-8531) Coredump when removing an entry
[
https://issues.apache.org/jira/browse/GEODE-8531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209060#comment-17209060
]
ASF GitHub Bot commented on GEODE-8531:
---
gaussianrecurrence commented on a change in pull request #667:
URL: https://github.com/apache/geode-native/pull/667#discussion_r500536351
##
File path: cppcache/integration/test/RegisterKeysTest.cpp
##
@@ -112,6 +114,51 @@ TEST(RegisterKeysTest, RegisterAllWithCachingRegion) {
}
}
+TEST(RegisterKeysTest, RegisterAllWithConsistencyDisabled) {
+ Cluster cluster{LocatorCount{1}, ServerCount{1}};
+
+ cluster.start();
+
+ cluster.getGfsh()
+ .create()
+ .region()
+ .withName("region")
+ .withType("PARTITION")
+ .execute();
+
+ auto producer_cache = createTestCache();
+ auto listener_cache = createTestCache();
+
+ auto producer_region = [&cluster](Cache& cache) {
+auto poolFactory = cache.getPoolManager().createFactory();
+cluster.applyLocators(poolFactory);
+poolFactory.create("default");
+return setupProxyRegion(cache);
+ }(producer_cache);
+
+ auto listener_region = [&cluster](Cache& cache) {
+auto poolFactory =
+cache.getPoolManager().createFactory().setSubscriptionEnabled(true);
+cluster.applyLocators(poolFactory);
+poolFactory.create("default");
+auto region = setupCachingProxyRegion(cache, false);
+region->registerAllKeys();
+return region;
+ }(listener_cache);
+
+ ASSERT_FALSE(listener_region->containsValueForKey("one"));
+
+ producer_region->put("one", std::make_shared(1));
+ std::this_thread::sleep_for(std::chrono::seconds(5));
Review comment:
See my answer below
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Coredump when removing an entry
> ---
>
> Key: GEODE-8531
> URL: https://issues.apache.org/jira/browse/GEODE-8531
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
> Labels: pull-request-available
> Attachments: notifications-no-massif.log
>
>
> The scenario is the following:
> *HAVING* a configured concurrency-checks-enabled=false in the
> client-cache.xml for a region
> *HAVING* a configured subscription-notification for the pool on which the
> region is defined
> *HAVING* regsitered interest on all the keys of this region, values included
> *WHEN* a LOCAL_DESTROY notification arrives and therefore
> {color:#4c9aff}MapSegment::remove{color}{color:#172b4d} is called{color}
> {color:#172b4d}*THEN* the application crashes, claiming that the variable
> entry is a nullptr.{color}
>
> This is the segmentation report:
> {code:java}
> [debug 2020/09/24 17:21:07.263036 CEST DESKTOP-3SQUK3P:586546
> 140013383710464] Region::destroy: region [/region] destroying key
> [entry-152150]
> Segmentation fault
> *** Segmentation fault
> Register dump: RAX: RBX: RCX:
>
> RDX: RSI: 7f57580008e0 RDI: 7f5767ffe670
> RBP: 7f5767ffe6c0 R8 : 7f5758000d70 R9 : 563da49f0ac0
> R10: 000c R11: 7f57815a2058 R12: 563da6971a48
> R13: 563da696dbd0 R14: R15: 7ffd06db85a0
> RSP: 7f5767ffe610 RIP: 7f578159ac47 EFLAGS: 00010202 CS: 0033
> FS: GS: Trap: 000e Error: 0004 OldMask:
> CR2: FPUCW: 037f FPUSW: TAG: 7f57
> RIP: 80b37f70 RDP: ST(0) ST(1)
>
> ST(2) ST(3)
> ST(4) ST(5) c000
> ST(6) c000 ST(7) e000 e000
> mxcsr: 1f80
> XMM0: 25252525 XMM1:
> 25252525
> XMM2: 25252525 XMM3:
> 25252525
> XMM4: 25252525 XMM5:
> 25252525
> XMM6: 25252525 XMM7:
> 25252525
> XMM8: 25252525 XMM9:
> 25252525
> XMM10: 25252525 XMM11:
> 25252525
> XMM12: 25252525 XMM13:
> 25252525
> XMM14: 25252525 XMM15:
> 25252525Backtrace:
> /usr/local/lib/libapache
[jira] [Commented] (GEODE-8579) Locators should stop waiting for locator-wait-time if all locators contacted
[
https://issues.apache.org/jira/browse/GEODE-8579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209075#comment-17209075
]
ASF GitHub Bot commented on GEODE-8579:
---
Bill commented on a change in pull request #5598:
URL: https://github.com/apache/geode/pull/5598#discussion_r500523949
##
File path:
geode-membership/src/main/java/org/apache/geode/internal/AvailablePort.java
##
@@ -32,7 +32,7 @@
import java.util.Random;
import org.apache.geode.annotations.Immutable;
-import org.apache.geode.distributed.internal.DistributionConfig;
+import org.apache.geode.distributed.internal.membership.api.MembershipConfig;
Review comment:
better (narrower) dependency!
##
File path:
geode-assembly/src/acceptanceTest/java/org/apache/geode/management/internal/cli/shell/StatusLocatorExitCodeAcceptanceTest.java
##
@@ -57,7 +56,7 @@
@BeforeClass
public static void startLocator() throws IOException {
rootPath = gfshRule.getTemporaryFolder().getRoot().toPath();
-locatorPort = getRandomAvailablePort(SOCKET);
+locatorPort = AvailablePortHelper.getRandomAvailableTCPPort();
Review comment:
better!
##
File path:
geode-membership/src/integrationTest/java/org/apache/geode/distributed/internal/membership/gms/MembershipIntegrationTest.java
##
@@ -272,6 +276,65 @@ public void secondMembershipPausesForLocatorWaitTime()
stop(coordinatorLocator, lateJoiningLocator);
}
+ @Test
+ public void locatorsStopWaitingForLocatorWaitTimeIfAllLocatorsContacted()
+ throws IOException, MemberStartupException, InterruptedException,
TimeoutException,
+ ExecutionException {
+
+final Supplier executorServiceSupplier =
+() -> LoggingExecutors.newCachedThreadPool("membership", false);
+
+int[] locatorPorts = AvailablePortHelper.getRandomAvailableTCPPorts(2);
+
+int locatorWaitTime = (int) Duration.ofMinutes(5).getSeconds();
+final MembershipConfig config =
+createMembershipConfig(true, locatorWaitTime, locatorPorts[0],
locatorPorts[1]);
+
+CompletableFuture> createMembership0 =
+launchLocator(executorServiceSupplier, locatorPorts[0], config);
+
+// Assert that membership 0 is waiting for the other locator to start
+Thread.sleep(5000);
+assertThat(createMembership0.getNow(null)).isNull();
+
+CompletableFuture> createMembership1 =
+launchLocator(executorServiceSupplier, locatorPorts[1], config);
+
+// Make sure the members are created in less than the locator-wait-time
+Membership membership0 = createMembership0.get(2,
TimeUnit.MINUTES);
+Membership membership1 = createMembership1.get(2,
TimeUnit.MINUTES);
+
+// Make sure the members see each other in the view
+assertThat(membership0.getView().getMembers()).hasSize(2);
+assertThat(membership1.getView().getMembers()).hasSize(2);
+ }
Review comment:
This is a good test and it's acceptable as-is. I wonder though, if you'd
be willing to entertain reducing run-time and increasing determinism by by
injecting the (millisecond) time keeper and sleeper into the locator, the way
it's done for `PrimaryHandler`?
Here is the PR from August that added that injection:
https://github.com/apache/geode/pull/5422
As of that PR (and now on `develop`) there are a couple functional
interfaces defined in `PrimaryHander` that could be hoisted a little higher and
used in `MembershipLocator` for your purposes, i.e. `Sleeper`,
`MillisecondProvider`.
With those injected, this test could control time similar to how
`PrimaryHandlerTest` does.
##
File path:
geode-membership/src/main/java/org/apache/geode/internal/AvailablePort.java
##
@@ -547,12 +548,7 @@ public static void main(String[] args) {
InetAddress addr = null;
if (addrString != null) {
- try {
-addr = InetAddress.getByName(addrString);
- } catch (Exception e) {
-e.printStackTrace();
-ExitCode.FATAL.doSystemExit();
- }
+ addr = InetAddress.getByName(addrString);
Review comment:
verified when address cannot be resolved the exception causes exit code
1 (on macos) ✓
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Locators should stop waiting for locator-wait-time if all locators contacted
>
>
> Key: GEODE-8579
> URL: https://issues.apache.org/jira/browse/GEODE-8579
> Project: Geode
> Issue Type: Improvement
> Components: membership
>Reporter: Dan Smith
>
[jira] [Commented] (GEODE-8565) c++ client tries to connect to down server until IO error is thrown
[
https://issues.apache.org/jira/browse/GEODE-8565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209077#comment-17209077
]
ASF GitHub Bot commented on GEODE-8565:
---
mreddington commented on a change in pull request #662:
URL: https://github.com/apache/geode-native/pull/662#discussion_r500546322
##
File path: cppcache/integration/test/PartitionRegionOpsTest.cpp
##
@@ -15,6 +15,8 @@
* limitations under the License.
*/
+#include
Review comment:
Why is this header necessary?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> c++ client tries to connect to down server until IO error is thrown
> ---
>
> Key: GEODE-8565
> URL: https://issues.apache.org/jira/browse/GEODE-8565
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Alberto Bustamante Reyes
>Assignee: Alberto Bustamante Reyes
>Priority: Major
> Labels: pull-request-available
>
> This ticket is an improvement over GEODE-8231:
> {quote}If a C++ client connected to a cluster is sending operations to a
> partitioned region and one of the server goes down, the client keeps trying
> to send operations to the down server. This can be observed in the logs by a
> continuous flow of lines containing: "IO error in handshake with endpoint..."
> {quote}
> After that improvement, the c++ client removes the metadata info of the
> failing server once the "IO error in handshake" is received.
> But it has been observed that before that error is received, "timeout error"
> can be returned. So the client will try to reconnect until the "IO error in
> handshake" is received.
> This ticket aims to extend the GEODE-8231 solution so the client removes the
> server metadata information when a timeout is received.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8565) c++ client tries to connect to down server until IO error is thrown
[
https://issues.apache.org/jira/browse/GEODE-8565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209092#comment-17209092
]
ASF GitHub Bot commented on GEODE-8565:
---
alb3rtobr commented on a change in pull request #662:
URL: https://github.com/apache/geode-native/pull/662#discussion_r500551118
##
File path: cppcache/integration/test/PartitionRegionOpsTest.cpp
##
@@ -15,6 +15,8 @@
* limitations under the License.
*/
+#include
Review comment:
Good catch, it is not needed. I forgot to remove it when preparing the
PR.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> c++ client tries to connect to down server until IO error is thrown
> ---
>
> Key: GEODE-8565
> URL: https://issues.apache.org/jira/browse/GEODE-8565
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Alberto Bustamante Reyes
>Assignee: Alberto Bustamante Reyes
>Priority: Major
> Labels: pull-request-available
>
> This ticket is an improvement over GEODE-8231:
> {quote}If a C++ client connected to a cluster is sending operations to a
> partitioned region and one of the server goes down, the client keeps trying
> to send operations to the down server. This can be observed in the logs by a
> continuous flow of lines containing: "IO error in handshake with endpoint..."
> {quote}
> After that improvement, the c++ client removes the metadata info of the
> failing server once the "IO error in handshake" is received.
> But it has been observed that before that error is received, "timeout error"
> can be returned. So the client will try to reconnect until the "IO error in
> handshake" is received.
> This ticket aims to extend the GEODE-8231 solution so the client removes the
> server metadata information when a timeout is received.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8565) c++ client tries to connect to down server until IO error is thrown
[
https://issues.apache.org/jira/browse/GEODE-8565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209097#comment-17209097
]
ASF GitHub Bot commented on GEODE-8565:
---
mreddington commented on a change in pull request #662:
URL: https://github.com/apache/geode-native/pull/662#discussion_r500552393
##
File path: cppcache/integration/test/PartitionRegionOpsTest.cpp
##
@@ -46,11 +48,21 @@ using apache::geode::client::RegionShortcut;
using std::chrono::minutes;
+std::string getClientLogName() {
Review comment:
Oof... Man, I looked into why you're doing this, and I get you, and I'm
just as sorry.
Can I convince you to add a refactor that will eliminate all this dubious
file handling? If you look at cppcache/src/Log.cpp, there are 2 places, 2 lines
each, where we fprintf(stdout... and a flush. What if you replaced both those
with a write to ::std::cerr? No need to flush, cerr has unitbuf enabled by
default.
What this should allow you to do, but I'm not exactly familiar with how this
behaves over a shared object boundary, is you can replace the stream buffer of
cerr with your own.
::std::istringstream log_stream;
auto old_rdbuf = ::std::cerr.rdbuf(log_stream.rdbuf());
// Test code...
::std::getline(log_stream, log_line);
// etc...
::std::cerr.rdbuf(old_rdbuf);
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> c++ client tries to connect to down server until IO error is thrown
> ---
>
> Key: GEODE-8565
> URL: https://issues.apache.org/jira/browse/GEODE-8565
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Alberto Bustamante Reyes
>Assignee: Alberto Bustamante Reyes
>Priority: Major
> Labels: pull-request-available
>
> This ticket is an improvement over GEODE-8231:
> {quote}If a C++ client connected to a cluster is sending operations to a
> partitioned region and one of the server goes down, the client keeps trying
> to send operations to the down server. This can be observed in the logs by a
> continuous flow of lines containing: "IO error in handshake with endpoint..."
> {quote}
> After that improvement, the c++ client removes the metadata info of the
> failing server once the "IO error in handshake" is received.
> But it has been observed that before that error is received, "timeout error"
> can be returned. So the client will try to reconnect until the "IO error in
> handshake" is received.
> This ticket aims to extend the GEODE-8231 solution so the client removes the
> server metadata information when a timeout is received.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8531) Coredump when removing an entry
[
https://issues.apache.org/jira/browse/GEODE-8531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209100#comment-17209100
]
ASF GitHub Bot commented on GEODE-8531:
---
gaussianrecurrence commented on a change in pull request #667:
URL: https://github.com/apache/geode-native/pull/667#discussion_r500553468
##
File path: cppcache/integration/test/RegisterKeysTest.cpp
##
@@ -112,6 +114,51 @@ TEST(RegisterKeysTest, RegisterAllWithCachingRegion) {
}
}
+TEST(RegisterKeysTest, RegisterAllWithConsistencyDisabled) {
+ Cluster cluster{LocatorCount{1}, ServerCount{1}};
+
+ cluster.start();
+
+ cluster.getGfsh()
+ .create()
+ .region()
+ .withName("region")
+ .withType("PARTITION")
+ .execute();
+
+ auto producer_cache = createTestCache();
+ auto listener_cache = createTestCache();
+
+ auto producer_region = [&cluster](Cache& cache) {
+auto poolFactory = cache.getPoolManager().createFactory();
+cluster.applyLocators(poolFactory);
+poolFactory.create("default");
+return setupProxyRegion(cache);
+ }(producer_cache);
+
+ auto listener_region = [&cluster](Cache& cache) {
+auto poolFactory =
+cache.getPoolManager().createFactory().setSubscriptionEnabled(true);
+cluster.applyLocators(poolFactory);
+poolFactory.create("default");
+auto region = setupCachingProxyRegion(cache, false);
+region->registerAllKeys();
+return region;
+ }(listener_cache);
+
+ ASSERT_FALSE(listener_region->containsValueForKey("one"));
+
+ producer_region->put("one", std::make_shared(1));
+ std::this_thread::sleep_for(std::chrono::seconds(5));
+
+ ASSERT_TRUE(listener_region->containsValueForKey("one"));
+
+ producer_region->destroy("one");
+ std::this_thread::sleep_for(std::chrono::seconds(5));
Review comment:
Thing to be tested here is that whenever MapSegment::remove is called
with consistency is disabled no coredump occurs. I reproduced the issue with
client notifications, that's why I created the test here. The delay is in order
to make sure that the listener cache has enough time to receive the destroy
event.
---
However I have to say I've suffered having to run testing pipelines for
hours for each change, so I was thinking on changing the test to remove the
delay and instead make it a timeout.
---
Other choice could be to just try remove without notifications, but I am not
sure about this. What do you think?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Coredump when removing an entry
> ---
>
> Key: GEODE-8531
> URL: https://issues.apache.org/jira/browse/GEODE-8531
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
> Labels: pull-request-available
> Attachments: notifications-no-massif.log
>
>
> The scenario is the following:
> *HAVING* a configured concurrency-checks-enabled=false in the
> client-cache.xml for a region
> *HAVING* a configured subscription-notification for the pool on which the
> region is defined
> *HAVING* regsitered interest on all the keys of this region, values included
> *WHEN* a LOCAL_DESTROY notification arrives and therefore
> {color:#4c9aff}MapSegment::remove{color}{color:#172b4d} is called{color}
> {color:#172b4d}*THEN* the application crashes, claiming that the variable
> entry is a nullptr.{color}
>
> This is the segmentation report:
> {code:java}
> [debug 2020/09/24 17:21:07.263036 CEST DESKTOP-3SQUK3P:586546
> 140013383710464] Region::destroy: region [/region] destroying key
> [entry-152150]
> Segmentation fault
> *** Segmentation fault
> Register dump: RAX: RBX: RCX:
>
> RDX: RSI: 7f57580008e0 RDI: 7f5767ffe670
> RBP: 7f5767ffe6c0 R8 : 7f5758000d70 R9 : 563da49f0ac0
> R10: 000c R11: 7f57815a2058 R12: 563da6971a48
> R13: 563da696dbd0 R14: R15: 7ffd06db85a0
> RSP: 7f5767ffe610 RIP: 7f578159ac47 EFLAGS: 00010202 CS: 0033
> FS: GS: Trap: 000e Error: 0004 OldMask:
> CR2: FPUCW: 037f FPUSW: TAG: 7f57
> RIP: 80b37f70 RDP: ST(0) ST(1)
>
> ST(2) ST(3)
> ST(4) ST(5) c000
> ST(6) c
[jira] [Commented] (GEODE-8565) c++ client tries to connect to down server until IO error is thrown
[
https://issues.apache.org/jira/browse/GEODE-8565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209102#comment-17209102
]
ASF GitHub Bot commented on GEODE-8565:
---
mreddington commented on a change in pull request #662:
URL: https://github.com/apache/geode-native/pull/662#discussion_r500554011
##
File path: cppcache/src/ThinClientPoolDM.cpp
##
@@ -1427,17 +1427,18 @@ GfErrType ThinClientPoolDM::sendSyncRequest(
GF_SAFE_DELETE_CON(conn);
}
excludeServers.insert(ServerLocation(ep->name()));
- if (error == GF_IOERR) {
+ if (error == GF_IOERR || error == GF_TIMEOUT) {
Review comment:
Can you combine these nested conditions into one and remove a whole
level of indentation?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> c++ client tries to connect to down server until IO error is thrown
> ---
>
> Key: GEODE-8565
> URL: https://issues.apache.org/jira/browse/GEODE-8565
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Alberto Bustamante Reyes
>Assignee: Alberto Bustamante Reyes
>Priority: Major
> Labels: pull-request-available
>
> This ticket is an improvement over GEODE-8231:
> {quote}If a C++ client connected to a cluster is sending operations to a
> partitioned region and one of the server goes down, the client keeps trying
> to send operations to the down server. This can be observed in the logs by a
> continuous flow of lines containing: "IO error in handshake with endpoint..."
> {quote}
> After that improvement, the c++ client removes the metadata info of the
> failing server once the "IO error in handshake" is received.
> But it has been observed that before that error is received, "timeout error"
> can be returned. So the client will try to reconnect until the "IO error in
> handshake" is received.
> This ticket aims to extend the GEODE-8231 solution so the client removes the
> server metadata information when a timeout is received.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8565) c++ client tries to connect to down server until IO error is thrown
[
https://issues.apache.org/jira/browse/GEODE-8565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209103#comment-17209103
]
ASF GitHub Bot commented on GEODE-8565:
---
mreddington commented on a change in pull request #662:
URL: https://github.com/apache/geode-native/pull/662#discussion_r500554917
##
File path: cppcache/src/ThinClientPoolDM.cpp
##
@@ -2351,11 +2352,12 @@ TcrConnection*
ThinClientPoolDM::getConnectionFromQueueW(
version);
}
return nullptr;
- } else if (*error == GF_IOERR) {
+ } else if (*error == GF_IOERR || *error == GF_TIMEOUT) {
Review comment:
Combine, reduce nesting, etc...
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> c++ client tries to connect to down server until IO error is thrown
> ---
>
> Key: GEODE-8565
> URL: https://issues.apache.org/jira/browse/GEODE-8565
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Alberto Bustamante Reyes
>Assignee: Alberto Bustamante Reyes
>Priority: Major
> Labels: pull-request-available
>
> This ticket is an improvement over GEODE-8231:
> {quote}If a C++ client connected to a cluster is sending operations to a
> partitioned region and one of the server goes down, the client keeps trying
> to send operations to the down server. This can be observed in the logs by a
> continuous flow of lines containing: "IO error in handshake with endpoint..."
> {quote}
> After that improvement, the c++ client removes the metadata info of the
> failing server once the "IO error in handshake" is received.
> But it has been observed that before that error is received, "timeout error"
> can be returned. So the client will try to reconnect until the "IO error in
> handshake" is received.
> This ticket aims to extend the GEODE-8231 solution so the client removes the
> server metadata information when a timeout is received.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8565) c++ client tries to connect to down server until IO error is thrown
[
https://issues.apache.org/jira/browse/GEODE-8565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209105#comment-17209105
]
ASF GitHub Bot commented on GEODE-8565:
---
alb3rtobr commented on a change in pull request #662:
URL: https://github.com/apache/geode-native/pull/662#discussion_r500556185
##
File path: cppcache/src/ThinClientPoolDM.cpp
##
@@ -1427,17 +1427,18 @@ GfErrType ThinClientPoolDM::sendSyncRequest(
GF_SAFE_DELETE_CON(conn);
}
excludeServers.insert(ServerLocation(ep->name()));
- if (error == GF_IOERR) {
+ if (error == GF_IOERR || error == GF_TIMEOUT) {
Review comment:
+1! And the same in line 2355
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> c++ client tries to connect to down server until IO error is thrown
> ---
>
> Key: GEODE-8565
> URL: https://issues.apache.org/jira/browse/GEODE-8565
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Alberto Bustamante Reyes
>Assignee: Alberto Bustamante Reyes
>Priority: Major
> Labels: pull-request-available
>
> This ticket is an improvement over GEODE-8231:
> {quote}If a C++ client connected to a cluster is sending operations to a
> partitioned region and one of the server goes down, the client keeps trying
> to send operations to the down server. This can be observed in the logs by a
> continuous flow of lines containing: "IO error in handshake with endpoint..."
> {quote}
> After that improvement, the c++ client removes the metadata info of the
> failing server once the "IO error in handshake" is received.
> But it has been observed that before that error is received, "timeout error"
> can be returned. So the client will try to reconnect until the "IO error in
> handshake" is received.
> This ticket aims to extend the GEODE-8231 solution so the client removes the
> server metadata information when a timeout is received.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8553) Reduce ThinClientLocatorHelper lock time
[
https://issues.apache.org/jira/browse/GEODE-8553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209112#comment-17209112
]
ASF GitHub Bot commented on GEODE-8553:
---
mreddington commented on a change in pull request #660:
URL: https://github.com/apache/geode-native/pull/660#discussion_r500561294
##
File path: cppcache/src/ThinClientLocatorHelper.cpp
##
@@ -174,30 +176,25 @@ GfErrType
ThinClientLocatorHelper::getEndpointForNewCallBackConn(
ClientProxyMembershipID& memId, std::list& outEndpoint,
std::string&, int redundancy, const std::set& exclEndPts,
const std::string& serverGrp) {
- std::lock_guard guard(m_locatorLock);
auto& sysProps = m_poolDM->getConnectionManager()
.getCacheImpl()
->getDistributedSystem()
.getSystemProperties();
- int locatorsRetry = 3;
- if (m_poolDM) {
-int poolRetry = m_poolDM->getRetryAttempts();
-locatorsRetry = poolRetry <= 0 ? locatorsRetry : poolRetry;
- }
+
+ auto poolRetry = m_poolDM->getRetryAttempts();
+ auto locatorsRetry = poolRetry <= 0 ? 3 : poolRetry;
+
LOGFINER(
"ThinClientLocatorHelper::getEndpointForNewCallBackConn locatorsRetry = "
"%d ",
locatorsRetry);
- for (unsigned attempts = 0;
- attempts <
- (m_locHostPort.size() == 1 ? locatorsRetry : m_locHostPort.size());
- attempts++) {
-ServerLocation loc;
-if (m_locHostPort.size() == 1) {
- loc = m_locHostPort[0];
-} else {
- loc = m_locHostPort[attempts];
-}
+
+ auto locators = getLocators();
+ auto locatorsSize = locators.size();
+ auto maxAttempts = locatorsSize == 1 ? locatorsRetry : locatorsSize;
+
+ for (auto attempts = 0ULL; attempts < maxAttempts; ++attempts) {
+const auto& loc = locatorsSize == 1 ? locators[0] : locators[attempts];
Review comment:
I'm not opposed to changing the business logic, since A) this business
logic is not part of any formal specification, we make no promises here and are
free to do what we want, and B) this code contains obvious bugs.
That said, so long as the bug is addressed, whatever solution you like. Your
suggestion is just fine.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Reduce ThinClientLocatorHelper lock time
>
>
> Key: GEODE-8553
> URL: https://issues.apache.org/jira/browse/GEODE-8553
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Affects Versions: 1.12.0, 1.13.0
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
> Labels: pull-request-available
>
> During my troublshootings, I've seen that locking m_locatorLock for the whole
> scope of the class function members might cause some inter-locks.
> Problem here and in many other places of the NC is that networking operations
> are performed while a mutex is locked. Therefore if *thread A* takes longer
> than expected in performing its network operation, it might block another one
> which does not requires any resource of the first *thread A*. Hence, the
> inter-lock.
> This improvement is the first one of a series regarding to lock scope
> reduction when it comes with code regarding networking in NC.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8553) Reduce ThinClientLocatorHelper lock time
[
https://issues.apache.org/jira/browse/GEODE-8553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209113#comment-17209113
]
ASF GitHub Bot commented on GEODE-8553:
---
gaussianrecurrence commented on a change in pull request #660:
URL: https://github.com/apache/geode-native/pull/660#discussion_r500563207
##
File path: cppcache/src/ThinClientLocatorHelper.cpp
##
@@ -174,30 +176,25 @@ GfErrType
ThinClientLocatorHelper::getEndpointForNewCallBackConn(
ClientProxyMembershipID& memId, std::list& outEndpoint,
std::string&, int redundancy, const std::set& exclEndPts,
const std::string& serverGrp) {
- std::lock_guard guard(m_locatorLock);
auto& sysProps = m_poolDM->getConnectionManager()
.getCacheImpl()
->getDistributedSystem()
.getSystemProperties();
- int locatorsRetry = 3;
- if (m_poolDM) {
-int poolRetry = m_poolDM->getRetryAttempts();
-locatorsRetry = poolRetry <= 0 ? locatorsRetry : poolRetry;
- }
+
+ auto poolRetry = m_poolDM->getRetryAttempts();
+ auto locatorsRetry = poolRetry <= 0 ? 3 : poolRetry;
+
LOGFINER(
"ThinClientLocatorHelper::getEndpointForNewCallBackConn locatorsRetry = "
"%d ",
locatorsRetry);
- for (unsigned attempts = 0;
- attempts <
- (m_locHostPort.size() == 1 ? locatorsRetry : m_locHostPort.size());
- attempts++) {
-ServerLocation loc;
-if (m_locHostPort.size() == 1) {
- loc = m_locHostPort[0];
-} else {
- loc = m_locHostPort[attempts];
-}
+
+ auto locators = getLocators();
+ auto locatorsSize = locators.size();
+ auto maxAttempts = locatorsSize == 1 ? locatorsRetry : locatorsSize;
+
+ for (auto attempts = 0ULL; attempts < maxAttempts; ++attempts) {
+const auto& loc = locatorsSize == 1 ? locators[0] : locators[attempts];
Review comment:
Perfect, then I'll resolve this conversation :)
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Reduce ThinClientLocatorHelper lock time
>
>
> Key: GEODE-8553
> URL: https://issues.apache.org/jira/browse/GEODE-8553
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Affects Versions: 1.12.0, 1.13.0
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
> Labels: pull-request-available
>
> During my troublshootings, I've seen that locking m_locatorLock for the whole
> scope of the class function members might cause some inter-locks.
> Problem here and in many other places of the NC is that networking operations
> are performed while a mutex is locked. Therefore if *thread A* takes longer
> than expected in performing its network operation, it might block another one
> which does not requires any resource of the first *thread A*. Hence, the
> inter-lock.
> This improvement is the first one of a series regarding to lock scope
> reduction when it comes with code regarding networking in NC.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8579) Locators should stop waiting for locator-wait-time if all locators contacted
[
https://issues.apache.org/jira/browse/GEODE-8579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209130#comment-17209130
]
ASF GitHub Bot commented on GEODE-8579:
---
rhoughton-pivot commented on a change in pull request #5598:
URL: https://github.com/apache/geode/pull/5598#discussion_r500570669
##
File path: geode-memcached/build.gradle
##
@@ -31,6 +31,7 @@ dependencies {
testImplementation('org.mockito:mockito-core')
testImplementation(project(':geode-junit'))
+ integrationTestImplementation(project(':geode-membership'))
Review comment:
What symbol does `geode-membership` bring that `geode-memcached` is
consuming?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Locators should stop waiting for locator-wait-time if all locators contacted
>
>
> Key: GEODE-8579
> URL: https://issues.apache.org/jira/browse/GEODE-8579
> Project: Geode
> Issue Type: Improvement
> Components: membership
>Reporter: Dan Smith
>Priority: Major
> Labels: pull-request-available
>
> If locator-wait-time is set on one or more locators, the locators can
> currently end up waiting for the entire locator-wait-time before starting up,
> even if all locators can contact each other.
> If the locators can all contact each other, they should start up right away
> and not wait any longer, even if locator-wait-time is set.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8572) LogExporter throws if a directory matches its file selector
[
https://issues.apache.org/jira/browse/GEODE-8572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209142#comment-17209142
]
ASF GitHub Bot commented on GEODE-8572:
---
jchen21 commented on a change in pull request #5595:
URL: https://github.com/apache/geode/pull/5595#discussion_r500576818
##
File path:
geode-gfsh/src/main/java/org/apache/geode/management/internal/cli/util/LogExporter.java
##
@@ -181,12 +180,13 @@ private long filterAndSize(Path originalLogFile) throws
IOException {
}
private List findFiles(Path workingDir, Predicate fileSelector)
throws IOException {
-Stream selectedFiles/* = null */;
if (!workingDir.toFile().isDirectory()) {
return Collections.emptyList();
}
-selectedFiles =
Files.list(workingDir).filter(fileSelector).filter(this.logFilter::acceptsFile);
-
-return selectedFiles.collect(toList());
+return Files.list(workingDir)
+.filter(Files::isRegularFile)
Review comment:
You might want
[`NOFOLLOW_LINKS`](https://docs.oracle.com/javase/8/docs/api/java/nio/file/Files.html#isRegularFile-java.nio.file.Path-java.nio.file.LinkOption...-).
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> LogExporter throws if a directory matches its file selector
> ---
>
> Key: GEODE-8572
> URL: https://issues.apache.org/jira/browse/GEODE-8572
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Affects Versions: 1.13.0
>Reporter: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> {{LogExporter}} tries to read and export any directory entry whose name is
> accepted by its log file selector predicate. The predicate accepts any entry
> whose name, when converted to lower case, contains ".log". If one of those
> entries is directory, the predicate accepts it anyway. When {{LogExporter}}
> attempts to create a {{FileReader}} read it, the {{FileReader}} constructor
> throws {{FileNotFoundException}}.
> There is a stat file selector predicate that works similarly.
> {{LogExporter}}'s log and stat file selector predicates should accept only
> files, and not directories. And perhaps the should accept only files whose
> names _end_ in the appropriate extension, rather than _containing_ the
> characters. The predicates are defined in {{LogExporter}}'s
> {{findLogFiles()}} and {{findStatFiles()}} methods.
> I discovered this defect by running {{LogExporterIntegrationTest}} on macOS.
> Each test's preparation writes some to-be-exported files into a temporary
> directory that, on macOS, may contain numerous other files and directories.
> One of those directories (e.g.
> /var/folders/yz/6y59fxln38d7lf2jxng1zgg4gn/T/com.apple.LoginUserService),
> which matches the {{LogExporter}}'s predicate.
> These tests should also be changed to write their to-be-exported files to a
> directory that is known to be empty.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8579) Locators should stop waiting for locator-wait-time if all locators contacted
[
https://issues.apache.org/jira/browse/GEODE-8579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209145#comment-17209145
]
ASF GitHub Bot commented on GEODE-8579:
---
upthewaterspout commented on a change in pull request #5598:
URL: https://github.com/apache/geode/pull/5598#discussion_r500577538
##
File path: geode-memcached/build.gradle
##
@@ -31,6 +31,7 @@ dependencies {
testImplementation('org.mockito:mockito-core')
testImplementation(project(':geode-junit'))
+ integrationTestImplementation(project(':geode-membership'))
Review comment:
AvailablePort
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Locators should stop waiting for locator-wait-time if all locators contacted
>
>
> Key: GEODE-8579
> URL: https://issues.apache.org/jira/browse/GEODE-8579
> Project: Geode
> Issue Type: Improvement
> Components: membership
>Reporter: Dan Smith
>Priority: Major
> Labels: pull-request-available
>
> If locator-wait-time is set on one or more locators, the locators can
> currently end up waiting for the entire locator-wait-time before starting up,
> even if all locators can contact each other.
> If the locators can all contact each other, they should start up right away
> and not wait any longer, even if locator-wait-time is set.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8579) Locators should stop waiting for locator-wait-time if all locators contacted
[
https://issues.apache.org/jira/browse/GEODE-8579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209152#comment-17209152
]
ASF GitHub Bot commented on GEODE-8579:
---
aaronlindsey commented on a change in pull request #5598:
URL: https://github.com/apache/geode/pull/5598#discussion_r500581229
##
File path:
geode-membership/src/main/java/org/apache/geode/distributed/internal/membership/gms/membership/GMSJoinLeave.java
##
@@ -349,9 +349,9 @@ public boolean join() throws MemberStartupException {
&& state.possibleCoordinator.equals(this.localAddress)) {
// if we haven't contacted a member of a cluster maybe this node
should
// become the coordinator.
-if (state.joinedMembersContacted <= 0 && (now >=
locatorGiveUpTime) &&
-(tries >= minimumRetriesBeforeBecomingCoordinator ||
-state.locatorsContacted >= locators.size())) {
+if (state.joinedMembersContacted <= 0 && (now >= locatorGiveUpTime
&&
+tries >= minimumRetriesBeforeBecomingCoordinator) ||
+state.locatorsContacted >= locators.size()) {
Review comment:
It looks like this evaluates to `true` any time we are able to contact
all of the locators, even if one of those locators is part of an existing DS.
In other words, if `joinedMembersContacted` is greater than zero but
`locatorsContacted` is equal to `locators.size()` it tries to become the
coordinator. Is that OK/can that even happen? I don't know enough about this
code to say for sure.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Locators should stop waiting for locator-wait-time if all locators contacted
>
>
> Key: GEODE-8579
> URL: https://issues.apache.org/jira/browse/GEODE-8579
> Project: Geode
> Issue Type: Improvement
> Components: membership
>Reporter: Dan Smith
>Priority: Major
> Labels: pull-request-available
>
> If locator-wait-time is set on one or more locators, the locators can
> currently end up waiting for the entire locator-wait-time before starting up,
> even if all locators can contact each other.
> If the locators can all contact each other, they should start up right away
> and not wait any longer, even if locator-wait-time is set.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8579) Locators should stop waiting for locator-wait-time if all locators contacted
[
https://issues.apache.org/jira/browse/GEODE-8579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209156#comment-17209156
]
ASF GitHub Bot commented on GEODE-8579:
---
rhoughton-pivot commented on a change in pull request #5598:
URL: https://github.com/apache/geode/pull/5598#discussion_r500585310
##
File path: geode-memcached/build.gradle
##
@@ -31,6 +31,7 @@ dependencies {
testImplementation('org.mockito:mockito-core')
testImplementation(project(':geode-junit'))
+ integrationTestImplementation(project(':geode-membership'))
Review comment:
Wow, shame on me. I didn't catch that there was a file-move by looking
at the change summary. #approved
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Locators should stop waiting for locator-wait-time if all locators contacted
>
>
> Key: GEODE-8579
> URL: https://issues.apache.org/jira/browse/GEODE-8579
> Project: Geode
> Issue Type: Improvement
> Components: membership
>Reporter: Dan Smith
>Priority: Major
> Labels: pull-request-available
>
> If locator-wait-time is set on one or more locators, the locators can
> currently end up waiting for the entire locator-wait-time before starting up,
> even if all locators can contact each other.
> If the locators can all contact each other, they should start up right away
> and not wait any longer, even if locator-wait-time is set.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8569) Missing message security footer check in gnmsg
[ https://issues.apache.org/jira/browse/GEODE-8569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209159#comment-17209159 ] ASF subversion and git services commented on GEODE-8569: Commit 496541a5ebd9c50b7abf61d38ea91c981a37f1c3 in geode-native's branch refs/heads/develop from Blake Bender [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=496541a ] GEODE-8569: Add missing method to ClientMessageDecoder (#663) - This would be called, and thus throw an exception, for client logs using AuthInitialize - Also added v10.0.3 to version lookup for regex function dispatcher. Apparently we'd never tried to decode a v10.0.3 log before, go figure - geode-native only dumps up to 8KB of a message, then truncates, so just catch all exceptions reading a message and add an error message to the JSON output for that message Co-authored-by: Blake Bender > Missing message security footer check in gnmsg > -- > > Key: GEODE-8569 > URL: https://issues.apache.org/jira/browse/GEODE-8569 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Blake Bender >Assignee: Blake Bender >Priority: Major > Labels: pull-request-available > > In an older version of the `gnmsg.py` script, there was a function called > request_requires_security_footer that returned a boolean based on the message > name, indictating whether or not the message needed the security footer in a > server conversation with authentication. In the refactor that moved the > client message decoding into a class, this method was left out, so attempting > to decode messages from a client log that used AuthInitialize will throw an > exception attempting to call this missing function. We need to add this call > to the ClientMessageDecoder class. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8569) Missing message security footer check in gnmsg
[ https://issues.apache.org/jira/browse/GEODE-8569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209160#comment-17209160 ] ASF GitHub Bot commented on GEODE-8569: --- pdxcodemonkey merged pull request #663: URL: https://github.com/apache/geode-native/pull/663 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Missing message security footer check in gnmsg > -- > > Key: GEODE-8569 > URL: https://issues.apache.org/jira/browse/GEODE-8569 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Blake Bender >Assignee: Blake Bender >Priority: Major > Labels: pull-request-available > > In an older version of the `gnmsg.py` script, there was a function called > request_requires_security_footer that returned a boolean based on the message > name, indictating whether or not the message needed the security footer in a > server conversation with authentication. In the refactor that moved the > client message decoding into a class, this method was left out, so attempting > to decode messages from a client log that used AuthInitialize will throw an > exception attempting to call this missing function. We need to add this call > to the ClientMessageDecoder class. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8480) Add tx manager check in geode-native transaction example
[ https://issues.apache.org/jira/browse/GEODE-8480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209162#comment-17209162 ] ASF GitHub Bot commented on GEODE-8480: --- pdxcodemonkey merged pull request #648: URL: https://github.com/apache/geode-native/pull/648 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Add tx manager check in geode-native transaction example > > > Key: GEODE-8480 > URL: https://issues.apache.org/jira/browse/GEODE-8480 > Project: Geode > Issue Type: Improvement > Components: docs, native client >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Minor > Labels: pull-request-available > > Transactions documentation & example in the geode C++ client is not checking > if the transaction manager exists before calling to rollback, as it is done > in the transactions documentation and example in geode. > I have seen that depending on the exception, the rollback can generate an > error so I think its something that should be added to the example. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8480) Add tx manager check in geode-native transaction example
[ https://issues.apache.org/jira/browse/GEODE-8480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209161#comment-17209161 ] ASF subversion and git services commented on GEODE-8480: Commit 36b500e4355ccc7453c9b91aa7cb7a38893eb072 in geode-native's branch refs/heads/develop from Alberto Bustamante Reyes [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=36b500e ] GEODE-8480: Add txmanager check in tx example (#648) * Test to show the issue * Fix for the issue > Add tx manager check in geode-native transaction example > > > Key: GEODE-8480 > URL: https://issues.apache.org/jira/browse/GEODE-8480 > Project: Geode > Issue Type: Improvement > Components: docs, native client >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Minor > Labels: pull-request-available > > Transactions documentation & example in the geode C++ client is not checking > if the transaction manager exists before calling to rollback, as it is done > in the transactions documentation and example in geode. > I have seen that depending on the exception, the rollback can generate an > error so I think its something that should be added to the example. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8579) Locators should stop waiting for locator-wait-time if all locators contacted
[
https://issues.apache.org/jira/browse/GEODE-8579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209165#comment-17209165
]
ASF GitHub Bot commented on GEODE-8579:
---
upthewaterspout commented on a change in pull request #5598:
URL: https://github.com/apache/geode/pull/5598#discussion_r500594061
##
File path:
geode-membership/src/main/java/org/apache/geode/distributed/internal/membership/gms/membership/GMSJoinLeave.java
##
@@ -349,9 +349,9 @@ public boolean join() throws MemberStartupException {
&& state.possibleCoordinator.equals(this.localAddress)) {
// if we haven't contacted a member of a cluster maybe this node
should
// become the coordinator.
-if (state.joinedMembersContacted <= 0 && (now >=
locatorGiveUpTime) &&
-(tries >= minimumRetriesBeforeBecomingCoordinator ||
-state.locatorsContacted >= locators.size())) {
+if (state.joinedMembersContacted <= 0 && (now >= locatorGiveUpTime
&&
+tries >= minimumRetriesBeforeBecomingCoordinator) ||
+state.locatorsContacted >= locators.size()) {
Review comment:
Gah! Good catch! Let me see if I have any more parenthesis lying around
here.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Locators should stop waiting for locator-wait-time if all locators contacted
>
>
> Key: GEODE-8579
> URL: https://issues.apache.org/jira/browse/GEODE-8579
> Project: Geode
> Issue Type: Improvement
> Components: membership
>Reporter: Dan Smith
>Priority: Major
> Labels: pull-request-available
>
> If locator-wait-time is set on one or more locators, the locators can
> currently end up waiting for the entire locator-wait-time before starting up,
> even if all locators can contact each other.
> If the locators can all contact each other, they should start up right away
> and not wait any longer, even if locator-wait-time is set.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8565) c++ client tries to connect to down server until IO error is thrown
[
https://issues.apache.org/jira/browse/GEODE-8565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209168#comment-17209168
]
ASF GitHub Bot commented on GEODE-8565:
---
alb3rtobr commented on a change in pull request #662:
URL: https://github.com/apache/geode-native/pull/662#discussion_r500601281
##
File path: cppcache/integration/test/PartitionRegionOpsTest.cpp
##
@@ -46,11 +48,21 @@ using apache::geode::client::RegionShortcut;
using std::chrono::minutes;
+std::string getClientLogName() {
Review comment:
@mreddington I have tried your approach (check last commit) but it does
not work fine. There are no lines when reading from the `istringstream`, it
seems empty. Am I missing something?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> c++ client tries to connect to down server until IO error is thrown
> ---
>
> Key: GEODE-8565
> URL: https://issues.apache.org/jira/browse/GEODE-8565
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Alberto Bustamante Reyes
>Assignee: Alberto Bustamante Reyes
>Priority: Major
> Labels: pull-request-available
>
> This ticket is an improvement over GEODE-8231:
> {quote}If a C++ client connected to a cluster is sending operations to a
> partitioned region and one of the server goes down, the client keeps trying
> to send operations to the down server. This can be observed in the logs by a
> continuous flow of lines containing: "IO error in handshake with endpoint..."
> {quote}
> After that improvement, the c++ client removes the metadata info of the
> failing server once the "IO error in handshake" is received.
> But it has been observed that before that error is received, "timeout error"
> can be returned. So the client will try to reconnect until the "IO error in
> handshake" is received.
> This ticket aims to extend the GEODE-8231 solution so the client removes the
> server metadata information when a timeout is received.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-8480) Add tx manager check in geode-native transaction example
[ https://issues.apache.org/jira/browse/GEODE-8480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Bustamante Reyes resolved GEODE-8480. - Fix Version/s: 1.14.0 Resolution: Fixed > Add tx manager check in geode-native transaction example > > > Key: GEODE-8480 > URL: https://issues.apache.org/jira/browse/GEODE-8480 > Project: Geode > Issue Type: Improvement > Components: docs, native client >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Minor > Labels: pull-request-available > Fix For: 1.14.0 > > > Transactions documentation & example in the geode C++ client is not checking > if the transaction manager exists before calling to rollback, as it is done > in the transactions documentation and example in geode. > I have seen that depending on the exception, the rollback can generate an > error so I think its something that should be added to the example. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8578) Parse PartitionResolverName in RESPONSE_CLIENT_PARTITION_ATTRIBUTES
[ https://issues.apache.org/jira/browse/GEODE-8578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209172#comment-17209172 ] ASF GitHub Bot commented on GEODE-8578: --- pdxcodemonkey commented on a change in pull request #669: URL: https://github.com/apache/geode-native/pull/669#discussion_r500605057 ## File path: tools/gnmsg/server_messages.py ## @@ -36,16 +36,20 @@ def read_bucket_count(message_bytes, offset): def read_partition_attributes(properties, message_bytes, offset): -if properties["Parts"] != 2 and properties["Parts"] != 4: -raise Exception( -"Don't know how to parse a RESPONSE_CLIENT_PARTITION_ATTRIBUTES message with " -+ properties["Parts"] -+ " parts (should have 2 or 4 only)." -) - (properties["BucketCount"], offset) = read_bucket_count(message_bytes, offset) (properties["ColocatedWith"], offset) = parse_key_or_value(message_bytes, offset) -# TODO: parse parts 3 and 4 (partition resolver and list of partition attributes), if they exist +if properties["Parts"] == 4: +(properties["PartitionResolverName"], offset) = parse_key_or_value(message_bytes, offset) +# TODO: parse part 4 (list of partition attributes) +elif properties["Parts"] == 3: +try: +(properties["PartitionResolverName"], offset) = parse_key_or_value(message_bytes, offset) +except: +raise Exception( +"Don't know how to parse a RESPONSE_CLIENT_PARTITION_ATTRIBUTES message with " ++ "3 parts and fpa attribute." +) +# TODO: parse part 3 if it is not partition resolver but list of partition attributes Review comment: Is it possible for the server to send this message with 3 parts? And with part 3 being attributes, rather than the partition resolver name? Looking at the C++ code, it's clear geode-native could never parse such a message, so I wonder if we need to here... This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Parse PartitionResolverName in RESPONSE_CLIENT_PARTITION_ATTRIBUTES > --- > > Key: GEODE-8578 > URL: https://issues.apache.org/jira/browse/GEODE-8578 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Major > Labels: pull-request-available > > I tried the gnmsg tool with a client file connecting to a cluster that > contains a partition region with a partition resolver, which caused an > exception in the tool. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8578) Parse PartitionResolverName in RESPONSE_CLIENT_PARTITION_ATTRIBUTES
[ https://issues.apache.org/jira/browse/GEODE-8578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209175#comment-17209175 ] ASF GitHub Bot commented on GEODE-8578: --- pdxcodemonkey commented on a change in pull request #669: URL: https://github.com/apache/geode-native/pull/669#discussion_r500605057 ## File path: tools/gnmsg/server_messages.py ## @@ -36,16 +36,20 @@ def read_bucket_count(message_bytes, offset): def read_partition_attributes(properties, message_bytes, offset): -if properties["Parts"] != 2 and properties["Parts"] != 4: -raise Exception( -"Don't know how to parse a RESPONSE_CLIENT_PARTITION_ATTRIBUTES message with " -+ properties["Parts"] -+ " parts (should have 2 or 4 only)." -) - (properties["BucketCount"], offset) = read_bucket_count(message_bytes, offset) (properties["ColocatedWith"], offset) = parse_key_or_value(message_bytes, offset) -# TODO: parse parts 3 and 4 (partition resolver and list of partition attributes), if they exist +if properties["Parts"] == 4: +(properties["PartitionResolverName"], offset) = parse_key_or_value(message_bytes, offset) +# TODO: parse part 4 (list of partition attributes) +elif properties["Parts"] == 3: +try: +(properties["PartitionResolverName"], offset) = parse_key_or_value(message_bytes, offset) +except: +raise Exception( +"Don't know how to parse a RESPONSE_CLIENT_PARTITION_ATTRIBUTES message with " ++ "3 parts and fpa attribute." +) +# TODO: parse part 3 if it is not partition resolver but list of partition attributes Review comment: Thanks for adding this - I'm excited to see someone using the tool! Is it possible for the server to send this message with 3 parts? And with part 3 being attributes, rather than the partition resolver name? Looking at the C++ code, it's clear geode-native could never parse such a message, so I wonder if we need to here... This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Parse PartitionResolverName in RESPONSE_CLIENT_PARTITION_ATTRIBUTES > --- > > Key: GEODE-8578 > URL: https://issues.apache.org/jira/browse/GEODE-8578 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Major > Labels: pull-request-available > > I tried the gnmsg tool with a client file connecting to a cluster that > contains a partition region with a partition resolver, which caused an > exception in the tool. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8578) Parse PartitionResolverName in RESPONSE_CLIENT_PARTITION_ATTRIBUTES
[
https://issues.apache.org/jira/browse/GEODE-8578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209176#comment-17209176
]
ASF GitHub Bot commented on GEODE-8578:
---
alb3rtobr commented on a change in pull request #669:
URL: https://github.com/apache/geode-native/pull/669#discussion_r500607157
##
File path: tools/gnmsg/server_messages.py
##
@@ -36,16 +36,20 @@ def read_bucket_count(message_bytes, offset):
def read_partition_attributes(properties, message_bytes, offset):
-if properties["Parts"] != 2 and properties["Parts"] != 4:
-raise Exception(
-"Don't know how to parse a RESPONSE_CLIENT_PARTITION_ATTRIBUTES
message with "
-+ properties["Parts"]
-+ " parts (should have 2 or 4 only)."
-)
-
(properties["BucketCount"], offset) = read_bucket_count(message_bytes,
offset)
(properties["ColocatedWith"], offset) = parse_key_or_value(message_bytes,
offset)
-# TODO: parse parts 3 and 4 (partition resolver and list of partition
attributes), if they exist
+if properties["Parts"] == 4:
+(properties["PartitionResolverName"], offset) =
parse_key_or_value(message_bytes, offset)
+# TODO: parse part 4 (list of partition attributes)
+elif properties["Parts"] == 3:
+try:
+(properties["PartitionResolverName"], offset) =
parse_key_or_value(message_bytes, offset)
+except:
+raise Exception(
+"Don't know how to parse a
RESPONSE_CLIENT_PARTITION_ATTRIBUTES message with "
++ "3 parts and fpa attribute."
+)
+# TODO: parse part 3 if it is not partition resolver but list of
partition attributes
Review comment:
I used this code of `GetClientPartitionAttributesOp` Java class as
reference:
```
...
int bucketCount;
String colocatedWith;
String partitionResolverName = null;
Set fpaSet = null;
bucketCount = (Integer) msg.getPart(0).getObject();
colocatedWith = (String) msg.getPart(1).getObject();
if (msg.getNumberOfParts() == 4) {
partitionResolverName = (String) msg.getPart(2).getObject();
fpaSet = (Set) msg.getPart(3).getObject();
} else if (msg.getNumberOfParts() == 3) {
Object obj = msg.getPart(2).getObject();
if (obj instanceof String) {
partitionResolverName = (String) obj;
} else {
fpaSet = (Set) obj;
}
...
```
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Parse PartitionResolverName in RESPONSE_CLIENT_PARTITION_ATTRIBUTES
> ---
>
> Key: GEODE-8578
> URL: https://issues.apache.org/jira/browse/GEODE-8578
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Alberto Bustamante Reyes
>Assignee: Alberto Bustamante Reyes
>Priority: Major
> Labels: pull-request-available
>
> I tried the gnmsg tool with a client file connecting to a cluster that
> contains a partition region with a partition resolver, which caused an
> exception in the tool.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8572) LogExporter throws if a directory matches its file selector
[
https://issues.apache.org/jira/browse/GEODE-8572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209179#comment-17209179
]
ASF GitHub Bot commented on GEODE-8572:
---
demery-pivotal commented on a change in pull request #5595:
URL: https://github.com/apache/geode/pull/5595#discussion_r500610779
##
File path:
geode-gfsh/src/main/java/org/apache/geode/management/internal/cli/util/LogExporter.java
##
@@ -181,12 +180,13 @@ private long filterAndSize(Path originalLogFile) throws
IOException {
}
private List findFiles(Path workingDir, Predicate fileSelector)
throws IOException {
-Stream selectedFiles/* = null */;
if (!workingDir.toFile().isDirectory()) {
return Collections.emptyList();
}
-selectedFiles =
Files.list(workingDir).filter(fileSelector).filter(this.logFilter::acceptsFile);
-
-return selectedFiles.collect(toList());
+return Files.list(workingDir)
+.filter(Files::isRegularFile)
Review comment:
Here's a scenario: Let's say the path is a symbolic link, and it links
to a regular file.
My understanding is:
- If I use `NOFOLLOW_LINKS`, the exporter will skip the regular file.
- If I omit `NOFOLLOW_LINKS`, the exporter will export the regular file.
Is my understanding correct? If so, are you saying that it's best to ignore
the regular file if the path we're testing is a symbolic link?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> LogExporter throws if a directory matches its file selector
> ---
>
> Key: GEODE-8572
> URL: https://issues.apache.org/jira/browse/GEODE-8572
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Affects Versions: 1.13.0
>Reporter: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> {{LogExporter}} tries to read and export any directory entry whose name is
> accepted by its log file selector predicate. The predicate accepts any entry
> whose name, when converted to lower case, contains ".log". If one of those
> entries is directory, the predicate accepts it anyway. When {{LogExporter}}
> attempts to create a {{FileReader}} read it, the {{FileReader}} constructor
> throws {{FileNotFoundException}}.
> There is a stat file selector predicate that works similarly.
> {{LogExporter}}'s log and stat file selector predicates should accept only
> files, and not directories. And perhaps the should accept only files whose
> names _end_ in the appropriate extension, rather than _containing_ the
> characters. The predicates are defined in {{LogExporter}}'s
> {{findLogFiles()}} and {{findStatFiles()}} methods.
> I discovered this defect by running {{LogExporterIntegrationTest}} on macOS.
> Each test's preparation writes some to-be-exported files into a temporary
> directory that, on macOS, may contain numerous other files and directories.
> One of those directories (e.g.
> /var/folders/yz/6y59fxln38d7lf2jxng1zgg4gn/T/com.apple.LoginUserService),
> which matches the {{LogExporter}}'s predicate.
> These tests should also be changed to write their to-be-exported files to a
> directory that is known to be empty.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8578) Parse PartitionResolverName in RESPONSE_CLIENT_PARTITION_ATTRIBUTES
[ https://issues.apache.org/jira/browse/GEODE-8578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209180#comment-17209180 ] ASF GitHub Bot commented on GEODE-8578: --- alb3rtobr commented on a change in pull request #669: URL: https://github.com/apache/geode-native/pull/669#discussion_r500610925 ## File path: tools/gnmsg/server_messages.py ## @@ -36,16 +36,20 @@ def read_bucket_count(message_bytes, offset): def read_partition_attributes(properties, message_bytes, offset): -if properties["Parts"] != 2 and properties["Parts"] != 4: -raise Exception( -"Don't know how to parse a RESPONSE_CLIENT_PARTITION_ATTRIBUTES message with " -+ properties["Parts"] -+ " parts (should have 2 or 4 only)." -) - (properties["BucketCount"], offset) = read_bucket_count(message_bytes, offset) (properties["ColocatedWith"], offset) = parse_key_or_value(message_bytes, offset) -# TODO: parse parts 3 and 4 (partition resolver and list of partition attributes), if they exist +if properties["Parts"] == 4: +(properties["PartitionResolverName"], offset) = parse_key_or_value(message_bytes, offset) +# TODO: parse part 4 (list of partition attributes) +elif properties["Parts"] == 3: +try: +(properties["PartitionResolverName"], offset) = parse_key_or_value(message_bytes, offset) +except: +raise Exception( +"Don't know how to parse a RESPONSE_CLIENT_PARTITION_ATTRIBUTES message with " ++ "3 parts and fpa attribute." +) +# TODO: parse part 3 if it is not partition resolver but list of partition attributes Review comment: > Is it possible for the server to send this message with 3 parts? It seems so. In my example, I got this exception: `Exception: Don't know how to parse a RESPONSE_CLIENT_PARTITION_ATTRIBUTES message with 3 parts (should have 2 or 4 only).` Well, actually what I got first was a `TypeError: must be str, not int` exception because `properties["Parts"]` is not a string: ``` raise Exception( "Don't know how to parse a RESPONSE_CLIENT_PARTITION_ATTRIBUTES message with " + properties["Parts"] + " parts (should have 2 or 4 only)." ) ``` This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Parse PartitionResolverName in RESPONSE_CLIENT_PARTITION_ATTRIBUTES > --- > > Key: GEODE-8578 > URL: https://issues.apache.org/jira/browse/GEODE-8578 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Major > Labels: pull-request-available > > I tried the gnmsg tool with a client file connecting to a cluster that > contains a partition region with a partition resolver, which caused an > exception in the tool. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8578) Parse PartitionResolverName in RESPONSE_CLIENT_PARTITION_ATTRIBUTES
[ https://issues.apache.org/jira/browse/GEODE-8578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209181#comment-17209181 ] ASF GitHub Bot commented on GEODE-8578: --- pdxcodemonkey commented on a change in pull request #669: URL: https://github.com/apache/geode-native/pull/669#discussion_r500611285 ## File path: tools/gnmsg/server_messages.py ## @@ -36,16 +36,20 @@ def read_bucket_count(message_bytes, offset): def read_partition_attributes(properties, message_bytes, offset): -if properties["Parts"] != 2 and properties["Parts"] != 4: -raise Exception( -"Don't know how to parse a RESPONSE_CLIENT_PARTITION_ATTRIBUTES message with " -+ properties["Parts"] -+ " parts (should have 2 or 4 only)." -) - (properties["BucketCount"], offset) = read_bucket_count(message_bytes, offset) (properties["ColocatedWith"], offset) = parse_key_or_value(message_bytes, offset) -# TODO: parse parts 3 and 4 (partition resolver and list of partition attributes), if they exist +if properties["Parts"] == 4: +(properties["PartitionResolverName"], offset) = parse_key_or_value(message_bytes, offset) +# TODO: parse part 4 (list of partition attributes) +elif properties["Parts"] == 3: +try: +(properties["PartitionResolverName"], offset) = parse_key_or_value(message_bytes, offset) +except: +raise Exception( +"Don't know how to parse a RESPONSE_CLIENT_PARTITION_ATTRIBUTES message with " ++ "3 parts and fpa attribute." +) +# TODO: parse part 3 if it is not partition resolver but list of partition attributes Review comment: Okay, that's what I was wondering - does the Java code do it differently? And that's clearly a yes. For the record, the C++ code ignores the possibility of 3 parts entirely, so if this message ever comes back with 3 parts geode-native apparently will get no partition information. If we were to dig into it, we'd probably find that some version of the server in the dim past used to send the 3-part variant, and the Java parsing code is left for compatibility with that ancient version of the protocol. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Parse PartitionResolverName in RESPONSE_CLIENT_PARTITION_ATTRIBUTES > --- > > Key: GEODE-8578 > URL: https://issues.apache.org/jira/browse/GEODE-8578 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Major > Labels: pull-request-available > > I tried the gnmsg tool with a client file connecting to a cluster that > contains a partition region with a partition resolver, which caused an > exception in the tool. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8579) Locators should stop waiting for locator-wait-time if all locators contacted
[
https://issues.apache.org/jira/browse/GEODE-8579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209184#comment-17209184
]
ASF GitHub Bot commented on GEODE-8579:
---
aaronlindsey commented on a change in pull request #5598:
URL: https://github.com/apache/geode/pull/5598#discussion_r500614767
##
File path:
geode-membership/src/main/java/org/apache/geode/distributed/internal/membership/gms/membership/GMSJoinLeave.java
##
@@ -349,9 +349,9 @@ public boolean join() throws MemberStartupException {
&& state.possibleCoordinator.equals(this.localAddress)) {
// if we haven't contacted a member of a cluster maybe this node
should
// become the coordinator.
-if (state.joinedMembersContacted <= 0 && (now >=
locatorGiveUpTime) &&
-(tries >= minimumRetriesBeforeBecomingCoordinator ||
-state.locatorsContacted >= locators.size())) {
+if (state.joinedMembersContacted <= 0 && (now >= locatorGiveUpTime
&&
+tries >= minimumRetriesBeforeBecomingCoordinator) ||
+state.locatorsContacted >= locators.size()) {
Review comment:
The new logic in the latest commit makes sense to me.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Locators should stop waiting for locator-wait-time if all locators contacted
>
>
> Key: GEODE-8579
> URL: https://issues.apache.org/jira/browse/GEODE-8579
> Project: Geode
> Issue Type: Improvement
> Components: membership
>Reporter: Dan Smith
>Priority: Major
> Labels: pull-request-available
>
> If locator-wait-time is set on one or more locators, the locators can
> currently end up waiting for the entire locator-wait-time before starting up,
> even if all locators can contact each other.
> If the locators can all contact each other, they should start up right away
> and not wait any longer, even if locator-wait-time is set.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8578) Parse PartitionResolverName in RESPONSE_CLIENT_PARTITION_ATTRIBUTES
[ https://issues.apache.org/jira/browse/GEODE-8578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209183#comment-17209183 ] ASF GitHub Bot commented on GEODE-8578: --- pdxcodemonkey commented on a change in pull request #669: URL: https://github.com/apache/geode-native/pull/669#discussion_r500614661 ## File path: tools/gnmsg/server_messages.py ## @@ -36,16 +36,20 @@ def read_bucket_count(message_bytes, offset): def read_partition_attributes(properties, message_bytes, offset): -if properties["Parts"] != 2 and properties["Parts"] != 4: -raise Exception( -"Don't know how to parse a RESPONSE_CLIENT_PARTITION_ATTRIBUTES message with " -+ properties["Parts"] -+ " parts (should have 2 or 4 only)." -) - (properties["BucketCount"], offset) = read_bucket_count(message_bytes, offset) (properties["ColocatedWith"], offset) = parse_key_or_value(message_bytes, offset) -# TODO: parse parts 3 and 4 (partition resolver and list of partition attributes), if they exist +if properties["Parts"] == 4: +(properties["PartitionResolverName"], offset) = parse_key_or_value(message_bytes, offset) +# TODO: parse part 4 (list of partition attributes) +elif properties["Parts"] == 3: +try: +(properties["PartitionResolverName"], offset) = parse_key_or_value(message_bytes, offset) +except: +raise Exception( +"Don't know how to parse a RESPONSE_CLIENT_PARTITION_ATTRIBUTES message with " ++ "3 parts and fpa attribute." +) +# TODO: parse part 3 if it is not partition resolver but list of partition attributes Review comment: Oh interesting, so you've seen this in the wild. Let's file another Jira ticket to discuss - it seems to me this might be important for geode-native to handle, and PR comments aren't a great place to iron things out. Python changes look great, I'll go ahead and approve/merge this. Thanks again! This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Parse PartitionResolverName in RESPONSE_CLIENT_PARTITION_ATTRIBUTES > --- > > Key: GEODE-8578 > URL: https://issues.apache.org/jira/browse/GEODE-8578 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Major > Labels: pull-request-available > > I tried the gnmsg tool with a client file connecting to a cluster that > contains a partition region with a partition resolver, which caused an > exception in the tool. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8578) Parse PartitionResolverName in RESPONSE_CLIENT_PARTITION_ATTRIBUTES
[ https://issues.apache.org/jira/browse/GEODE-8578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209186#comment-17209186 ] ASF GitHub Bot commented on GEODE-8578: --- pdxcodemonkey merged pull request #669: URL: https://github.com/apache/geode-native/pull/669 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Parse PartitionResolverName in RESPONSE_CLIENT_PARTITION_ATTRIBUTES > --- > > Key: GEODE-8578 > URL: https://issues.apache.org/jira/browse/GEODE-8578 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Major > Labels: pull-request-available > > I tried the gnmsg tool with a client file connecting to a cluster that > contains a partition region with a partition resolver, which caused an > exception in the tool. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8578) Parse PartitionResolverName in RESPONSE_CLIENT_PARTITION_ATTRIBUTES
[ https://issues.apache.org/jira/browse/GEODE-8578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209185#comment-17209185 ] ASF subversion and git services commented on GEODE-8578: Commit 3ae0f3236f512af5c69a56bbdc38bf384ea8c096 in geode-native's branch refs/heads/develop from Alberto Bustamante Reyes [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=3ae0f32 ] GEODE-8578: Parse partition resolver in RESPONSE_CLIENT_PARTITION_ATTRIBUTES message (#669) > Parse PartitionResolverName in RESPONSE_CLIENT_PARTITION_ATTRIBUTES > --- > > Key: GEODE-8578 > URL: https://issues.apache.org/jira/browse/GEODE-8578 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Major > Labels: pull-request-available > > I tried the gnmsg tool with a client file connecting to a cluster that > contains a partition region with a partition resolver, which caused an > exception in the tool. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8578) Parse PartitionResolverName in RESPONSE_CLIENT_PARTITION_ATTRIBUTES
[ https://issues.apache.org/jira/browse/GEODE-8578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209188#comment-17209188 ] ASF GitHub Bot commented on GEODE-8578: --- alb3rtobr commented on a change in pull request #669: URL: https://github.com/apache/geode-native/pull/669#discussion_r500616849 ## File path: tools/gnmsg/server_messages.py ## @@ -36,16 +36,20 @@ def read_bucket_count(message_bytes, offset): def read_partition_attributes(properties, message_bytes, offset): -if properties["Parts"] != 2 and properties["Parts"] != 4: -raise Exception( -"Don't know how to parse a RESPONSE_CLIENT_PARTITION_ATTRIBUTES message with " -+ properties["Parts"] -+ " parts (should have 2 or 4 only)." -) - (properties["BucketCount"], offset) = read_bucket_count(message_bytes, offset) (properties["ColocatedWith"], offset) = parse_key_or_value(message_bytes, offset) -# TODO: parse parts 3 and 4 (partition resolver and list of partition attributes), if they exist +if properties["Parts"] == 4: +(properties["PartitionResolverName"], offset) = parse_key_or_value(message_bytes, offset) +# TODO: parse part 4 (list of partition attributes) +elif properties["Parts"] == 3: +try: +(properties["PartitionResolverName"], offset) = parse_key_or_value(message_bytes, offset) +except: +raise Exception( +"Don't know how to parse a RESPONSE_CLIENT_PARTITION_ATTRIBUTES message with " ++ "3 parts and fpa attribute." +) +# TODO: parse part 3 if it is not partition resolver but list of partition attributes Review comment: Thanks, you were too fast :) After your comment I was going to modify the function to leave it like: ``` def read_partition_attributes(properties, message_bytes, offset): (properties["BucketCount"], offset) = read_bucket_count(message_bytes, offset) (properties["ColocatedWith"], offset) = parse_key_or_value(message_bytes, offset) if properties["Parts"] >= 3: (properties["PartitionResolverName"], offset) = parse_key_or_value(message_bytes, offset) if properties["Parts"] == 4: # TODO: parse part 4 (list of partition attributes) raise Exception( "Don't know how to parse a RESPONSE_CLIENT_PARTITION_ATTRIBUTES message with " + "4 parts containing list of partition attributes." ) ``` This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Parse PartitionResolverName in RESPONSE_CLIENT_PARTITION_ATTRIBUTES > --- > > Key: GEODE-8578 > URL: https://issues.apache.org/jira/browse/GEODE-8578 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Major > Labels: pull-request-available > > I tried the gnmsg tool with a client file connecting to a cluster that > contains a partition region with a partition resolver, which caused an > exception in the tool. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8549) Remove use of junit EnvironmentVariables rule
[
https://issues.apache.org/jira/browse/GEODE-8549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe resolved GEODE-8549.
---
Fix Version/s: 1.14.0
Resolution: Fixed
> Remove use of junit EnvironmentVariables rule
> -
>
> Key: GEODE-8549
> URL: https://issues.apache.org/jira/browse/GEODE-8549
> Project: Geode
> Issue Type: Test
> Components: redis
>Reporter: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> The use of this rule causes build messages such as:
> {noformat}
> > Task :geode-redis:acceptanceTest
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by
> org.junit.contrib.java.lang.system.EnvironmentVariables
> (file:/home/geode/.gradle/caches/modules-2/files-2.1/com.github.stefanbirkner/system-rules/1.19.0/d541c9a1cff0dda32e2436c74562e2e4aa6c88cd/system-rules-1.19.0.jar)
> to field java.util.Collections$UnmodifiableMap.m
> WARNING: Please consider reporting this to the maintainers of
> org.junit.contrib.java.lang.system.EnvironmentVariables
> WARNING: Use --illegal-access=warn to enable warnings of further illegal
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> {noformat}
> We don't really need this unless we have a real concrete need to disable the
> Ryuk container.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-8566) Redis native tests should not also stand up a Geode server
[
https://issues.apache.org/jira/browse/GEODE-8566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe resolved GEODE-8566.
---
Resolution: Fixed
Fixed with https://github.com/apache/geode/pull/5597
> Redis native tests should not also stand up a Geode server
> --
>
> Key: GEODE-8566
> URL: https://issues.apache.org/jira/browse/GEODE-8566
> Project: Geode
> Issue Type: Test
> Components: redis
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> Our native acceptance tests currently extend from the integration tests and
> both classes have a {{@ClassRule}} that results in both a native (container)
> instance and a Geode instance starting up. Mostly not a problem except for
> {{PubSubNativeAcceptanceTest}} which was not testing against native redis.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-8577) PubSubNativeRedisAcceptanceTest is flaky
[ https://issues.apache.org/jira/browse/GEODE-8577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-8577. --- Fix Version/s: 1.14.0 Resolution: Fixed > PubSubNativeRedisAcceptanceTest is flaky > > > Key: GEODE-8577 > URL: https://issues.apache.org/jira/browse/GEODE-8577 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Jens Deppe >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > Going to disable this one test and work on fixing that. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8544) DUnit VM class has a bug when starting versioned VMs.
[
https://issues.apache.org/jira/browse/GEODE-8544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson resolved GEODE-8544.
Fix Version/s: 1.14.0
Resolution: Fixed
> DUnit VM class has a bug when starting versioned VMs.
> -
>
> Key: GEODE-8544
> URL: https://issues.apache.org/jira/browse/GEODE-8544
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.13.0
>Reporter: Mark Hanson
>Assignee: Mark Hanson
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> public static VM getVM(String version, int whichVM) {
> return Host.getHost(0).getVM(whichVM);
> }
> should be
> public static VM getVM(String version, int whichVM) {
> return Host.getHost(0).getVM(version, whichVM);
> }
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-8558) Pulse query is bypassing the QueryResultSetLimit MBean parameter if there is a newline after query or sql comments before the query line
[ https://issues.apache.org/jira/browse/GEODE-8558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-8558. Fix Version/s: 1.14.0 Resolution: Fixed > Pulse query is bypassing the QueryResultSetLimit MBean parameter if there is > a newline after query or sql comments before the query line > > > Key: GEODE-8558 > URL: https://issues.apache.org/jira/browse/GEODE-8558 > Project: Geode > Issue Type: Bug > Components: querying >Affects Versions: 1.13.0 >Reporter: Jinmei Liao >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > Setting the JVM MBean attribute QueryResultSetLimit to limit the query result > set (e.g. 2 here with my small local cluster) and it seems working, however, > in the pulse query textbox, if you have a carriage-return/newline after query > line or let's say a commented text/query before the actual query, it's > returning all the entries and the setting is not effective anymore. And if > this could also affect the queries running with commented text coming from > function execution. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8578) Parse PartitionResolverName in RESPONSE_CLIENT_PARTITION_ATTRIBUTES
[ https://issues.apache.org/jira/browse/GEODE-8578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209200#comment-17209200 ] ASF GitHub Bot commented on GEODE-8578: --- pdxcodemonkey commented on a change in pull request #669: URL: https://github.com/apache/geode-native/pull/669#discussion_r500626603 ## File path: tools/gnmsg/server_messages.py ## @@ -36,16 +36,20 @@ def read_bucket_count(message_bytes, offset): def read_partition_attributes(properties, message_bytes, offset): -if properties["Parts"] != 2 and properties["Parts"] != 4: -raise Exception( -"Don't know how to parse a RESPONSE_CLIENT_PARTITION_ATTRIBUTES message with " -+ properties["Parts"] -+ " parts (should have 2 or 4 only)." -) - (properties["BucketCount"], offset) = read_bucket_count(message_bytes, offset) (properties["ColocatedWith"], offset) = parse_key_or_value(message_bytes, offset) -# TODO: parse parts 3 and 4 (partition resolver and list of partition attributes), if they exist +if properties["Parts"] == 4: +(properties["PartitionResolverName"], offset) = parse_key_or_value(message_bytes, offset) +# TODO: parse part 4 (list of partition attributes) +elif properties["Parts"] == 3: +try: +(properties["PartitionResolverName"], offset) = parse_key_or_value(message_bytes, offset) +except: +raise Exception( +"Don't know how to parse a RESPONSE_CLIENT_PARTITION_ATTRIBUTES message with " ++ "3 parts and fpa attribute." +) +# TODO: parse part 3 if it is not partition resolver but list of partition attributes Review comment: lol no worries - there are a ton of things to add to gnmsg, you can add this refactor next time around :) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Parse PartitionResolverName in RESPONSE_CLIENT_PARTITION_ATTRIBUTES > --- > > Key: GEODE-8578 > URL: https://issues.apache.org/jira/browse/GEODE-8578 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Major > Labels: pull-request-available > > I tried the gnmsg tool with a client file connecting to a cluster that > contains a partition region with a partition resolver, which caused an > exception in the tool. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8579) Locators should stop waiting for locator-wait-time if all locators contacted
[
https://issues.apache.org/jira/browse/GEODE-8579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209201#comment-17209201
]
ASF GitHub Bot commented on GEODE-8579:
---
upthewaterspout commented on a change in pull request #5598:
URL: https://github.com/apache/geode/pull/5598#discussion_r500628520
##
File path:
geode-membership/src/integrationTest/java/org/apache/geode/distributed/internal/membership/gms/MembershipIntegrationTest.java
##
@@ -272,6 +276,65 @@ public void secondMembershipPausesForLocatorWaitTime()
stop(coordinatorLocator, lateJoiningLocator);
}
+ @Test
+ public void locatorsStopWaitingForLocatorWaitTimeIfAllLocatorsContacted()
+ throws IOException, MemberStartupException, InterruptedException,
TimeoutException,
+ ExecutionException {
+
+final Supplier executorServiceSupplier =
+() -> LoggingExecutors.newCachedThreadPool("membership", false);
+
+int[] locatorPorts = AvailablePortHelper.getRandomAvailableTCPPorts(2);
+
+int locatorWaitTime = (int) Duration.ofMinutes(5).getSeconds();
+final MembershipConfig config =
+createMembershipConfig(true, locatorWaitTime, locatorPorts[0],
locatorPorts[1]);
+
+CompletableFuture> createMembership0 =
+launchLocator(executorServiceSupplier, locatorPorts[0], config);
+
+// Assert that membership 0 is waiting for the other locator to start
+Thread.sleep(5000);
+assertThat(createMembership0.getNow(null)).isNull();
+
+CompletableFuture> createMembership1 =
+launchLocator(executorServiceSupplier, locatorPorts[1], config);
+
+// Make sure the members are created in less than the locator-wait-time
+Membership membership0 = createMembership0.get(2,
TimeUnit.MINUTES);
+Membership membership1 = createMembership1.get(2,
TimeUnit.MINUTES);
+
+// Make sure the members see each other in the view
+assertThat(membership0.getView().getMembers()).hasSize(2);
+assertThat(membership1.getView().getMembers()).hasSize(2);
+ }
Review comment:
Based on your comment I started down this road. But this is a test of
the whole membership system, so this will require injecting virtual time into a
whole lot of classes, including classes that are doing things like
`wait(sometimeout)` etc. I feel like this needs a little bit more time and
careful development to get right, and more than I want to shoehorn into this
PR.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Locators should stop waiting for locator-wait-time if all locators contacted
>
>
> Key: GEODE-8579
> URL: https://issues.apache.org/jira/browse/GEODE-8579
> Project: Geode
> Issue Type: Improvement
> Components: membership
>Reporter: Dan Smith
>Priority: Major
> Labels: pull-request-available
>
> If locator-wait-time is set on one or more locators, the locators can
> currently end up waiting for the entire locator-wait-time before starting up,
> even if all locators can contact each other.
> If the locators can all contact each other, they should start up right away
> and not wait any longer, even if locator-wait-time is set.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8202) New option for serial gw sender threads start when receivers share ip and port
[ https://issues.apache.org/jira/browse/GEODE-8202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8202: -- Labels: pull-request-available (was: ) > New option for serial gw sender threads start when receivers share ip and port > -- > > Key: GEODE-8202 > URL: https://issues.apache.org/jira/browse/GEODE-8202 > Project: Geode > Issue Type: Improvement >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Major > Labels: pull-request-available > > RFC: > [https://cwiki.apache.org/confluence/display/GEODE/New+option+for+serial+gw+sender+dispatcher+threads+start|https://cwiki.apache.org/confluence/display/GEODE/New+option+for+serial+gw+sender+dispatcher+threads+start] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8202) New option for serial gw sender threads start when receivers share ip and port
[ https://issues.apache.org/jira/browse/GEODE-8202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209202#comment-17209202 ] ASF GitHub Bot commented on GEODE-8202: --- alb3rtobr opened a new pull request #5600: URL: https://github.com/apache/geode/pull/5600 RFC: https://cwiki.apache.org/confluence/display/GEODE/New+option+for+serial+gw+sender+dispatcher+threads+start This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > New option for serial gw sender threads start when receivers share ip and port > -- > > Key: GEODE-8202 > URL: https://issues.apache.org/jira/browse/GEODE-8202 > Project: Geode > Issue Type: Improvement >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Major > > RFC: > [https://cwiki.apache.org/confluence/display/GEODE/New+option+for+serial+gw+sender+dispatcher+threads+start|https://cwiki.apache.org/confluence/display/GEODE/New+option+for+serial+gw+sender+dispatcher+threads+start] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8578) Parse PartitionResolverName in RESPONSE_CLIENT_PARTITION_ATTRIBUTES
[ https://issues.apache.org/jira/browse/GEODE-8578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Bustamante Reyes resolved GEODE-8578. - Fix Version/s: 1.14.0 Resolution: Fixed > Parse PartitionResolverName in RESPONSE_CLIENT_PARTITION_ATTRIBUTES > --- > > Key: GEODE-8578 > URL: https://issues.apache.org/jira/browse/GEODE-8578 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > I tried the gnmsg tool with a client file connecting to a cluster that > contains a partition region with a partition resolver, which caused an > exception in the tool. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8531) Coredump when removing an entry
[
https://issues.apache.org/jira/browse/GEODE-8531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209204#comment-17209204
]
ASF GitHub Bot commented on GEODE-8531:
---
gaussianrecurrence commented on a change in pull request #667:
URL: https://github.com/apache/geode-native/pull/667#discussion_r500553468
##
File path: cppcache/integration/test/RegisterKeysTest.cpp
##
@@ -112,6 +114,51 @@ TEST(RegisterKeysTest, RegisterAllWithCachingRegion) {
}
}
+TEST(RegisterKeysTest, RegisterAllWithConsistencyDisabled) {
+ Cluster cluster{LocatorCount{1}, ServerCount{1}};
+
+ cluster.start();
+
+ cluster.getGfsh()
+ .create()
+ .region()
+ .withName("region")
+ .withType("PARTITION")
+ .execute();
+
+ auto producer_cache = createTestCache();
+ auto listener_cache = createTestCache();
+
+ auto producer_region = [&cluster](Cache& cache) {
+auto poolFactory = cache.getPoolManager().createFactory();
+cluster.applyLocators(poolFactory);
+poolFactory.create("default");
+return setupProxyRegion(cache);
+ }(producer_cache);
+
+ auto listener_region = [&cluster](Cache& cache) {
+auto poolFactory =
+cache.getPoolManager().createFactory().setSubscriptionEnabled(true);
+cluster.applyLocators(poolFactory);
+poolFactory.create("default");
+auto region = setupCachingProxyRegion(cache, false);
+region->registerAllKeys();
+return region;
+ }(listener_cache);
+
+ ASSERT_FALSE(listener_region->containsValueForKey("one"));
+
+ producer_region->put("one", std::make_shared(1));
+ std::this_thread::sleep_for(std::chrono::seconds(5));
+
+ ASSERT_TRUE(listener_region->containsValueForKey("one"));
+
+ producer_region->destroy("one");
+ std::this_thread::sleep_for(std::chrono::seconds(5));
Review comment:
Thing to be tested here is that whenever MapSegment::remove is called
with consistency is disabled no coredump occurs. I reproduced the issue with
client notifications, that's why I created the test here. The delay is in order
to make sure that the listener cache has enough time to receive the destroy
event.
---
However I have to say I've suffered having to run testing pipelines for
hours for each change, so I was thinking on changing the test to remove the
delay and instead make it a timeout.
---
Other choice could be to just try remove without notifications, but I am not
sure about this. What do you think?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Coredump when removing an entry
> ---
>
> Key: GEODE-8531
> URL: https://issues.apache.org/jira/browse/GEODE-8531
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
> Labels: pull-request-available
> Attachments: notifications-no-massif.log
>
>
> The scenario is the following:
> *HAVING* a configured concurrency-checks-enabled=false in the
> client-cache.xml for a region
> *HAVING* a configured subscription-notification for the pool on which the
> region is defined
> *HAVING* regsitered interest on all the keys of this region, values included
> *WHEN* a LOCAL_DESTROY notification arrives and therefore
> {color:#4c9aff}MapSegment::remove{color}{color:#172b4d} is called{color}
> {color:#172b4d}*THEN* the application crashes, claiming that the variable
> entry is a nullptr.{color}
>
> This is the segmentation report:
> {code:java}
> [debug 2020/09/24 17:21:07.263036 CEST DESKTOP-3SQUK3P:586546
> 140013383710464] Region::destroy: region [/region] destroying key
> [entry-152150]
> Segmentation fault
> *** Segmentation fault
> Register dump: RAX: RBX: RCX:
>
> RDX: RSI: 7f57580008e0 RDI: 7f5767ffe670
> RBP: 7f5767ffe6c0 R8 : 7f5758000d70 R9 : 563da49f0ac0
> R10: 000c R11: 7f57815a2058 R12: 563da6971a48
> R13: 563da696dbd0 R14: R15: 7ffd06db85a0
> RSP: 7f5767ffe610 RIP: 7f578159ac47 EFLAGS: 00010202 CS: 0033
> FS: GS: Trap: 000e Error: 0004 OldMask:
> CR2: FPUCW: 037f FPUSW: TAG: 7f57
> RIP: 80b37f70 RDP: ST(0) ST(1)
>
> ST(2) ST(3)
> ST(4) ST(5) c000
> ST(6) c
[jira] [Commented] (GEODE-8419) SSL/TLS protocol and cipher suite configuration is ignored
[
https://issues.apache.org/jira/browse/GEODE-8419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209209#comment-17209209
]
ASF GitHub Bot commented on GEODE-8419:
---
Bill commented on pull request #5594:
URL: https://github.com/apache/geode/pull/5594#issuecomment-704594061
The only failure in CI was RedisTestOpenJDK11. That test runs in CI but the
test isn't present on support/1.13 so it's not a showstopper.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> SSL/TLS protocol and cipher suite configuration is ignored
> --
>
> Key: GEODE-8419
> URL: https://issues.apache.org/jira/browse/GEODE-8419
> Project: Geode
> Issue Type: Bug
> Components: client/server, membership, security
>Affects Versions: 1.10.0, 1.11.0, 1.12.0, 1.13.0, 1.14.0
>Reporter: Jacob Barrett
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> Configuring {{ssl-protocols}} or {{ssl-ciphers}} properties, or per-component
> ssl properties, have no effect. Configuring {{ssl-protocols}} may effect the
> {{SSLContext}} selected and limit some of the protocols allowed but does not
> restrict to just the set specified in the property. The {{ssl-ciphers}}
> property does not limit cipher selection at all.
> The result is that all ciphers allowed under the match {{SSLContext}} are
> allowed and negotiated. This can result in an unintended cipher being used in
> SSL/TLS communication.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8572) LogExporter throws if a directory matches its file selector
[
https://issues.apache.org/jira/browse/GEODE-8572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209212#comment-17209212
]
ASF GitHub Bot commented on GEODE-8572:
---
jchen21 commented on a change in pull request #5595:
URL: https://github.com/apache/geode/pull/5595#discussion_r500642988
##
File path:
geode-gfsh/src/main/java/org/apache/geode/management/internal/cli/util/LogExporter.java
##
@@ -181,12 +180,13 @@ private long filterAndSize(Path originalLogFile) throws
IOException {
}
private List findFiles(Path workingDir, Predicate fileSelector)
throws IOException {
-Stream selectedFiles/* = null */;
if (!workingDir.toFile().isDirectory()) {
return Collections.emptyList();
}
-selectedFiles =
Files.list(workingDir).filter(fileSelector).filter(this.logFilter::acceptsFile);
-
-return selectedFiles.collect(toList());
+return Files.list(workingDir)
+.filter(Files::isRegularFile)
Review comment:
If you use `NOFOLLOW_LINKS`, for the scenario, `Files::isRegularFile`
returns `false`.
If you omit `NOFOLLOW_LINKS`, `Files::isRegularFile` returns `true`.
I haven't tried it with the exporter though.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> LogExporter throws if a directory matches its file selector
> ---
>
> Key: GEODE-8572
> URL: https://issues.apache.org/jira/browse/GEODE-8572
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Affects Versions: 1.13.0
>Reporter: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> {{LogExporter}} tries to read and export any directory entry whose name is
> accepted by its log file selector predicate. The predicate accepts any entry
> whose name, when converted to lower case, contains ".log". If one of those
> entries is directory, the predicate accepts it anyway. When {{LogExporter}}
> attempts to create a {{FileReader}} read it, the {{FileReader}} constructor
> throws {{FileNotFoundException}}.
> There is a stat file selector predicate that works similarly.
> {{LogExporter}}'s log and stat file selector predicates should accept only
> files, and not directories. And perhaps the should accept only files whose
> names _end_ in the appropriate extension, rather than _containing_ the
> characters. The predicates are defined in {{LogExporter}}'s
> {{findLogFiles()}} and {{findStatFiles()}} methods.
> I discovered this defect by running {{LogExporterIntegrationTest}} on macOS.
> Each test's preparation writes some to-be-exported files into a temporary
> directory that, on macOS, may contain numerous other files and directories.
> One of those directories (e.g.
> /var/folders/yz/6y59fxln38d7lf2jxng1zgg4gn/T/com.apple.LoginUserService),
> which matches the {{LogExporter}}'s predicate.
> These tests should also be changed to write their to-be-exported files to a
> directory that is known to be empty.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8419) SSL/TLS protocol and cipher suite configuration is ignored
[
https://issues.apache.org/jira/browse/GEODE-8419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209213#comment-17209213
]
ASF GitHub Bot commented on GEODE-8419:
---
Bill merged pull request #5594:
URL: https://github.com/apache/geode/pull/5594
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> SSL/TLS protocol and cipher suite configuration is ignored
> --
>
> Key: GEODE-8419
> URL: https://issues.apache.org/jira/browse/GEODE-8419
> Project: Geode
> Issue Type: Bug
> Components: client/server, membership, security
>Affects Versions: 1.10.0, 1.11.0, 1.12.0, 1.13.0, 1.14.0
>Reporter: Jacob Barrett
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> Configuring {{ssl-protocols}} or {{ssl-ciphers}} properties, or per-component
> ssl properties, have no effect. Configuring {{ssl-protocols}} may effect the
> {{SSLContext}} selected and limit some of the protocols allowed but does not
> restrict to just the set specified in the property. The {{ssl-ciphers}}
> property does not limit cipher selection at all.
> The result is that all ciphers allowed under the match {{SSLContext}} are
> allowed and negotiated. This can result in an unintended cipher being used in
> SSL/TLS communication.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8419) SSL/TLS protocol and cipher suite configuration is ignored
[
https://issues.apache.org/jira/browse/GEODE-8419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209215#comment-17209215
]
ASF subversion and git services commented on GEODE-8419:
Commit cf7b9e33a16d2cd8e9883400b44b389833c623b6 in geode's branch
refs/heads/support/1.13 from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=cf7b9e3 ]
GEODE-8419: SSL/TLS protocol and cipher suite configuration is ignored (#5465)
* GEODE-8419: SSL/TLS protocol and cipher suite configuration is ignored
Configure cipher suites when creating an SSLEngine
* addressing test issues
* fixing error in SSLSocket endpoint validation
* addressing Jake's comments
* change test to use ArgumentCaptor - thanks Jake\!
* check captured argument content
(cherry picked from commit 537721ff815cf40eff85fde65db9b5e787471c89)
> SSL/TLS protocol and cipher suite configuration is ignored
> --
>
> Key: GEODE-8419
> URL: https://issues.apache.org/jira/browse/GEODE-8419
> Project: Geode
> Issue Type: Bug
> Components: client/server, membership, security
>Affects Versions: 1.10.0, 1.11.0, 1.12.0, 1.13.0, 1.14.0
>Reporter: Jacob Barrett
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> Configuring {{ssl-protocols}} or {{ssl-ciphers}} properties, or per-component
> ssl properties, have no effect. Configuring {{ssl-protocols}} may effect the
> {{SSLContext}} selected and limit some of the protocols allowed but does not
> restrict to just the set specified in the property. The {{ssl-ciphers}}
> property does not limit cipher selection at all.
> The result is that all ciphers allowed under the match {{SSLContext}} are
> allowed and negotiated. This can result in an unintended cipher being used in
> SSL/TLS communication.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8419) SSL/TLS protocol and cipher suite configuration is ignored
[
https://issues.apache.org/jira/browse/GEODE-8419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17209214#comment-17209214
]
ASF subversion and git services commented on GEODE-8419:
Commit cf7b9e33a16d2cd8e9883400b44b389833c623b6 in geode's branch
refs/heads/support/1.13 from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=cf7b9e3 ]
GEODE-8419: SSL/TLS protocol and cipher suite configuration is ignored (#5465)
* GEODE-8419: SSL/TLS protocol and cipher suite configuration is ignored
Configure cipher suites when creating an SSLEngine
* addressing test issues
* fixing error in SSLSocket endpoint validation
* addressing Jake's comments
* change test to use ArgumentCaptor - thanks Jake\!
* check captured argument content
(cherry picked from commit 537721ff815cf40eff85fde65db9b5e787471c89)
> SSL/TLS protocol and cipher suite configuration is ignored
> --
>
> Key: GEODE-8419
> URL: https://issues.apache.org/jira/browse/GEODE-8419
> Project: Geode
> Issue Type: Bug
> Components: client/server, membership, security
>Affects Versions: 1.10.0, 1.11.0, 1.12.0, 1.13.0, 1.14.0
>Reporter: Jacob Barrett
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> Configuring {{ssl-protocols}} or {{ssl-ciphers}} properties, or per-component
> ssl properties, have no effect. Configuring {{ssl-protocols}} may effect the
> {{SSLContext}} selected and limit some of the protocols allowed but does not
> restrict to just the set specified in the property. The {{ssl-ciphers}}
> property does not limit cipher selection at all.
> The result is that all ciphers allowed under the match {{SSLContext}} are
> allowed and negotiated. This can result in an unintended cipher being used in
> SSL/TLS communication.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
