[jira] [Commented] (GEODE-7803) provide a way to create an internal region without using deprecated classes
[ https://issues.apache.org/jira/browse/GEODE-7803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17044026#comment-17044026 ] ASF subversion and git services commented on GEODE-7803: Commit b082c0352b0a96c3dc1cf07caaf1f7f2e4fb8177 in geode's branch refs/heads/feature/GEODE-7109 from Darrel Schneider [ https://gitbox.apache.org/repos/asf?p=geode.git;h=b082c03 ] GEODE-7803: provide undeprecated internal region create (#4722) You can now use InternalRegionFactory to create a region configured with InternalRegionArguments. No need to use the deprecated AttributesFactory. InternalRegionFactory used to be named RegionFactoryImpl. > provide a way to create an internal region without using deprecated classes > --- > > Key: GEODE-7803 > URL: https://issues.apache.org/jira/browse/GEODE-7803 > Project: Geode > Issue Type: Improvement > Components: regions >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Fix For: 1.13.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Currently geode has some places that create internal regions (using > InternalRegionArguments) that use deprecated classes to do this. It would be > nice if an internal way was provided to do this that was not deprecated. > GEODE-7799 is doing this. Once that fix is merged in then the > RegionFactoryImpl enhancement it add could be used in the places that use > deprecated apis to specify InternalRegionArguments -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7109) Improve DUnit test coverage for Tomcat session state module
[ https://issues.apache.org/jira/browse/GEODE-7109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17044028#comment-17044028 ] ASF subversion and git services commented on GEODE-7109: Commit 5773592ab7dd7af643ee11484e68be88c4b3989d in geode's branch refs/heads/feature/GEODE-7109 from Eric Shu [ https://gitbox.apache.org/repos/asf?p=geode.git;h=5773592 ] Merge branch 'develop' into feature/GEODE-7109 > Improve DUnit test coverage for Tomcat session state module > --- > > Key: GEODE-7109 > URL: https://issues.apache.org/jira/browse/GEODE-7109 > Project: Geode > Issue Type: Improvement > Components: http session, tests >Reporter: Benjamin P Ross >Assignee: Eric Shu >Priority: Major > Labels: GeodeCommons > Time Spent: 1h 40m > Remaining Estimate: 0h > > Our DUnit test coverage is significantly lacking for the Tomcat session state > module. This story aims to improve test coverage of that module. > Write DUnit tests for the following classes: > * DeltaSessionAttributeEventBatch > * DeltaSessionDestroyAttributeEvent > * DeltaSessionStatistics > * DeltaSessionUpdateAttributeEvent > * AbstractSessionCache > * ClientServerSessionCache > * CommitSessionValve > * DeltaSession > * DeltaSessionFacade > * DeltaSessionManager > * JvmRouteBinderValve > * PeerToPeerSessionCache > * SessionExpirationCacheListener > * TouchReplicatedRegionEntriesFunction > * TouchPartitionedRegionEntriesFunction > Write DUnit tests to exercise all versions of Tomcat with client-server and > peer-to-peer topologies, with and without local caching enabled. We also > want to exercise rebalance, resource management (thresholds), and commit > behavior (CommitSessionValve) related configuration as described in the docs. > We should scale these tests and the system level tests to do a more > realistic workload. A lot of them add a single entry to the session store > with just one or two containers. > ([https://gemfire.docs.pivotal.io/98/geode/tools_modules/http_session_mgmt/tomcat_changing_gf_default_cfg.html]). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7774) Remove redundant addAll call in ReflectionLuceneSerializer
[ https://issues.apache.org/jira/browse/GEODE-7774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17044021#comment-17044021 ] ASF subversion and git services commented on GEODE-7774: Commit b3d4458b3e822e4ca385aad4d4583ffed25bfa60 in geode's branch refs/heads/feature/GEODE-7109 from mkevo [ https://gitbox.apache.org/repos/asf?p=geode.git;h=b3d4458 ] GEODE-7774: Remove addAll in ReflectionLuceneSerializer (#4718) > Remove redundant addAll call in ReflectionLuceneSerializer > -- > > Key: GEODE-7774 > URL: https://issues.apache.org/jira/browse/GEODE-7774 > Project: Geode > Issue Type: Task > Components: lucene >Reporter: Jason Huynh >Assignee: Mario Kevo >Priority: Major > Labels: beginner, newb, pull-request-available, starter > Fix For: 1.13.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > the variable fieldNames can be constructed with a parameterized constructor > instead of an empty constructor and having addAll() invoked. > https://github.com/apache/geode/blob/182de42d8e56a900f0d22793a440af72f62f09f4/geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/repository/serializer/ReflectionLuceneSerializer.java#L45 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7799) Rebalance state needs to be distributed to other locators
[
https://issues.apache.org/jira/browse/GEODE-7799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17044023#comment-17044023
]
ASF subversion and git services commented on GEODE-7799:
Commit 22403e00c2196ab9239569b82ed34a71af7a7b26 in geode's branch
refs/heads/feature/GEODE-7109 from Darrel Schneider
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=22403e0 ]
GEODE-7799: Distribute rebalance status to other locators (#4692)
Co-authored-by: Joris Melchior
Co-authored-by: Darrel Schneider
Co-authored-by: Dale Emery
> Rebalance state needs to be distributed to other locators
> -
>
> Key: GEODE-7799
> URL: https://issues.apache.org/jira/browse/GEODE-7799
> Project: Geode
> Issue Type: Improvement
> Components: management
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>Priority: Major
> Fix For: 1.13.0
>
> Time Spent: 4h
> Remaining Estimate: 0h
>
> Why
> Within certain environments, users could be connected to a singular locator
> point of contact which is then unintelligently routed to one of the locators.
> If I kick off an operation from one Locator, but then check on it using
> another locator I will get a missing operation message.
> Acceptance Criteria
> Operation in one read by another
> Scenario:
> Given a cluster is up with 2 locators (locater1,locater2) as well as 2 servers
> And a user submits a POST operation to
> locator1:7070/management/experimental/operations/rebalances
> And that rebalance is in progress
> When a user submits a get operation to
> locator2:7070/management/experimental/operations/reblances/{id}
> Then they would receive the status of the operation started on locator1
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7798) CI: org.apache.geode.redis.PubSubTest failed intermittently on Windows
[ https://issues.apache.org/jira/browse/GEODE-7798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17044020#comment-17044020 ] ASF subversion and git services commented on GEODE-7798: Commit 2dae3964e9132b5cda21e0e37b1686281e1fbffe in geode's branch refs/heads/feature/GEODE-7109 from Jens Deppe [ https://gitbox.apache.org/repos/asf?p=geode.git;h=2dae396 ] GEODE-7798: Ignore PubSubTest until the flakiness can be removed (#4721) > CI: org.apache.geode.redis.PubSubTest failed intermittently on Windows > > > Key: GEODE-7798 > URL: https://issues.apache.org/jira/browse/GEODE-7798 > Project: Geode > Issue Type: Bug >Reporter: Jinmei Liao >Assignee: Jens Deppe >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsIntegrationTestOpenJDK11/builds/1240 > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsIntegrationTestOpenJDK11/builds/1242 > org.apache.geode.redis.PubSubTest > testTwoSubscribersOneChannel FAILED > org.junit.ComparisonFailure: expected:<[2]L> but was:<[1]L> > at > jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.redis.PubSubTest.testTwoSubscribersOneChannel(PubSubTest.java:163) > org.apache.geode.redis.PubSubTest > testOneSubscriberSubscribingToTwoChannels > FAILED > org.junit.ComparisonFailure: expected:<[1]L> but was:<[2]L> > at > jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.redis.PubSubTest.testOneSubscriberSubscribingToTwoChannels(PubSubTest.java:124) > org.apache.geode.redis.PubSubTest > testDeadSubscriber FAILED > org.junit.ComparisonFailure: expected:<[0]L> but was:<[2]L> > at > jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.redis.PubSubTest.testDeadSubscriber(PubSubTest.java:250) > org.apache.geode.redis.PubSubTest > testOneSubscriberOneChannelTwoTimes FAILED > org.junit.ComparisonFailure: expected:<[1]L> but was:<[3]L> > at > jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.redis.PubSubTest.testOneSubscriberOneChannelTwoTimes(PubSubTest.java:210) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7768) Code clean up, remove redundant null check in BootstrappingFunction
[ https://issues.apache.org/jira/browse/GEODE-7768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17044019#comment-17044019 ] ASF subversion and git services commented on GEODE-7768: Commit bf3e2801e96b9fc15954d02e5a762ba89f3e4891 in geode's branch refs/heads/feature/GEODE-7109 from mkevo [ https://gitbox.apache.org/repos/asf?p=geode.git;h=bf3e280 ] GEODE-7768: remove redundant null checks (#4701) > Code clean up, remove redundant null check in BootstrappingFunction > --- > > Key: GEODE-7768 > URL: https://issues.apache.org/jira/browse/GEODE-7768 > Project: Geode > Issue Type: Task >Reporter: Jason Huynh >Assignee: Mario Kevo >Priority: Major > Labels: beginner, newb, starter > Fix For: 1.13.0 > > Time Spent: 10m > Remaining Estimate: 0h > > The null check in the equals method of BootstrappingFunction can be safely > removed. The instanceof check will return false if the object is null. > See here: > [https://github.com/apache/geode/blob/cee84bbc53c707b2ca13ca664fb3087fec1c71ed/extensions/geode-modules/src/main/java/org/apache/geode/modules/util/BootstrappingFunction.java#L194] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7513) PersistentColocatedPartitionedRegionDistributedTest.testFullTreeOfColocatedChildPRsWithMissingRegions fails with org.mockito.exceptions.verification.NoInteractionsWante
[
https://issues.apache.org/jira/browse/GEODE-7513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17044024#comment-17044024
]
ASF subversion and git services commented on GEODE-7513:
Commit b430b8b9ef70c1f463ae825ad9d23919939cfce7 in geode's branch
refs/heads/feature/GEODE-7109 from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=b430b8b ]
GEODE-7513: Fix PersistentColocatedPartitionedRegionDistributedTest (#4715)
Change from verify.times to verify.atLeast to be more forgiving.
> PersistentColocatedPartitionedRegionDistributedTest.testFullTreeOfColocatedChildPRsWithMissingRegions
> fails with org.mockito.exceptions.verification.NoInteractionsWanted
> -
>
> Key: GEODE-7513
> URL: https://issues.apache.org/jira/browse/GEODE-7513
> Project: Geode
> Issue Type: Bug
> Components: core, tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: flaky
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> Failed in CI
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/1330:
> {noformat}
> org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDistributedTest
> > testFullTreeOfColocatedChildPRsWithMissingRegions FAILED
> java.lang.AssertionError: An exception occurred during asynchronous
> invocation.
> at
> org.apache.geode.test.dunit.AsyncInvocation.checkException(AsyncInvocation.java:297)
> at
> org.apache.geode.test.dunit.AsyncInvocation.await(AsyncInvocation.java:448)
> at
> org.apache.geode.test.dunit.AsyncInvocation.await(AsyncInvocation.java:178)
> at
> org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDistributedTest.testFullTreeOfColocatedChildPRsWithMissingRegions(PersistentColocatedPartitionedRegionDistributedTest.java:767)
> Caused by:
> org.mockito.exceptions.verification.NoInteractionsWanted:
> No interactions wanted here:
> -> at
> org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDistributedTest.validateColocationLogger_withChildRegionTree(PersistentColocatedPartitionedRegionDistributedTest.java:1987)
> But found this interaction on mock 'consumer':
> -> at
> org.apache.geode.internal.cache.partitioned.colocation.SingleThreadColocationLogger.logMissingRegions(SingleThreadColocationLogger.java:216)
> ***
> For your reference, here is the list of all invocations ([?] - means
> unverified).
> 1. -> at
> org.apache.geode.internal.cache.partitioned.colocation.SingleThreadColocationLogger.logMissingRegions(SingleThreadColocationLogger.java:216)
> 2. [?]-> at
> org.apache.geode.internal.cache.partitioned.colocation.SingleThreadColocationLogger.logMissingRegions(SingleThreadColocationLogger.java:216)
> at
> org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDistributedTest.validateColocationLogger_withChildRegionTree(PersistentColocatedPartitionedRegionDistributedTest.java:1987)
> at
> org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDistributedTest.lambda$testFullTreeOfColocatedChildPRsWithMissingRegions$43440a96$1(PersistentColocatedPartitionedRegionDistributedTest.java:764)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7813) add Build-Java-Vendor to gfsh version --full
[ https://issues.apache.org/jira/browse/GEODE-7813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17044027#comment-17044027 ] ASF subversion and git services commented on GEODE-7813: Commit 56f51e8724b1644a2af6b1a8998f131c544725de in geode's branch refs/heads/feature/GEODE-7109 from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=56f51e8 ] GEODE-7813: add Build-Java-Vendor to gfsh version --full (#4729) > add Build-Java-Vendor to gfsh version --full > > > Key: GEODE-7813 > URL: https://issues.apache.org/jira/browse/GEODE-7813 > Project: Geode > Issue Type: Improvement > Components: gfsh >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Fix For: 1.13.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The version info already includes the version of the compiler in > Build-Java-Version. As there are now several java compiler vendors and a > multitude of ways Geode may get compiled (various pipeline jobs, by a release > manager, by users, etc) it makes sense to record the provider of that javac > version as well. This is also required to audit that only open-source tools > are being used to produce Geode artifacts. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7635) DistributedAckRegionDUnitTest. testNBRegionDestructionDuringGetInitialImage is failing in Mass Test Run
[
https://issues.apache.org/jira/browse/GEODE-7635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17044025#comment-17044025
]
ASF subversion and git services commented on GEODE-7635:
Commit aff15491df07ae067a03edcf3a1e797495ddbe02 in geode's branch
refs/heads/feature/GEODE-7109 from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=aff1549 ]
GEODE-7635: Create DestroyRegionDuringGIIDistributedTest
Extract and parameterize these tests from MultiVMRegionTestCase:
* testNBRegionDestructionDuringGetInitialImage
* testNBRegionInvalidationDuringGetInitialImage
> DistributedAckRegionDUnitTest. testNBRegionDestructionDuringGetInitialImage
> is failing in Mass Test Run
> ---
>
> Key: GEODE-7635
> URL: https://issues.apache.org/jira/browse/GEODE-7635
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Mark Hanson
>Assignee: Kirk Lund
>Priority: Major
> Labels: flaky
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/mhansonp-mhanson-mass-test-ru-main/jobs/DistributedTestOpenJDK8/builds/2396]
>
> {noformat}
> java.lang.AssertionError: java.lang.IllegalStateException: Exception status
> not available while thread is alive.
> at
> org.apache.geode.test.dunit.AsyncInvocation.getException(AsyncInvocation.java:272)
> at
> org.apache.geode.test.dunit.AsyncInvocation.exceptionOccurred(AsyncInvocation.java:256)
> at
> org.apache.geode.cache30.MultiVMRegionTestCase.testNBRegionDestructionDuringGetInitialImage(MultiVMRegionTestCase.java:4973)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> at
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
>
[jira] [Commented] (GEODE-7550) Add option to show only receivers or senders to "list gateways" gfsh command
[ https://issues.apache.org/jira/browse/GEODE-7550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17044022#comment-17044022 ] ASF subversion and git services commented on GEODE-7550: Commit d5d3c7822c6dcee4c32ded40fc99de44523155d6 in geode's branch refs/heads/feature/GEODE-7109 from Alberto Bustamante Reyes [ https://gitbox.apache.org/repos/asf?p=geode.git;h=d5d3c78 ] GEODE-7550: Param to only list gw receivers or senders (#4429) > Add option to show only receivers or senders to "list gateways" gfsh command > > > Key: GEODE-7550 > URL: https://issues.apache.org/jira/browse/GEODE-7550 > Project: Geode > Issue Type: Improvement > Components: docs, gfsh >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Major > Labels: pull-request-available > Fix For: 1.13.0 > > Time Spent: 8.5h > Remaining Estimate: 0h > > "list gateways" command shows info about gateway senders and receivers, but I > would like to have the possibility of showing info just from senders or > receivers. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7813) add Build-Java-Vendor to gfsh version --full
[ https://issues.apache.org/jira/browse/GEODE-7813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17044011#comment-17044011 ] ASF subversion and git services commented on GEODE-7813: Commit b9bfaa25124c2ea066743f6abe6f26cd700fe0f5 in geode's branch refs/heads/release/1.12.0 from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=b9bfaa2 ] GEODE-7813: add Build-Java-Vendor to gfsh version --full (#4729) (cherry picked from commit 56f51e8724b1644a2af6b1a8998f131c544725de) > add Build-Java-Vendor to gfsh version --full > > > Key: GEODE-7813 > URL: https://issues.apache.org/jira/browse/GEODE-7813 > Project: Geode > Issue Type: Improvement > Components: gfsh >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Fix For: 1.13.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The version info already includes the version of the compiler in > Build-Java-Version. As there are now several java compiler vendors and a > multitude of ways Geode may get compiled (various pipeline jobs, by a release > manager, by users, etc) it makes sense to record the provider of that javac > version as well. This is also required to audit that only open-source tools > are being used to produce Geode artifacts. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7813) add Build-Java-Vendor to gfsh version --full
[ https://issues.apache.org/jira/browse/GEODE-7813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols resolved GEODE-7813. - Fix Version/s: 1.13.0 Resolution: Fixed > add Build-Java-Vendor to gfsh version --full > > > Key: GEODE-7813 > URL: https://issues.apache.org/jira/browse/GEODE-7813 > Project: Geode > Issue Type: Improvement > Components: gfsh >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Fix For: 1.13.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The version info already includes the version of the compiler in > Build-Java-Version. As there are now several java compiler vendors and a > multitude of ways Geode may get compiled (various pipeline jobs, by a release > manager, by users, etc) it makes sense to record the provider of that javac > version as well. This is also required to audit that only open-source tools > are being used to produce Geode artifacts. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7813) add Build-Java-Vendor to gfsh version --full
[ https://issues.apache.org/jira/browse/GEODE-7813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17044007#comment-17044007 ] ASF subversion and git services commented on GEODE-7813: Commit 56f51e8724b1644a2af6b1a8998f131c544725de in geode's branch refs/heads/develop from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=56f51e8 ] GEODE-7813: add Build-Java-Vendor to gfsh version --full (#4729) > add Build-Java-Vendor to gfsh version --full > > > Key: GEODE-7813 > URL: https://issues.apache.org/jira/browse/GEODE-7813 > Project: Geode > Issue Type: Improvement > Components: gfsh >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Fix For: 1.13.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The version info already includes the version of the compiler in > Build-Java-Version. As there are now several java compiler vendors and a > multitude of ways Geode may get compiled (various pipeline jobs, by a release > manager, by users, etc) it makes sense to record the provider of that javac > version as well. This is also required to audit that only open-source tools > are being used to produce Geode artifacts. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-7813) add Build-Java-Vendor to gfsh version --full
[ https://issues.apache.org/jira/browse/GEODE-7813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols reassigned GEODE-7813: --- Assignee: Owen Nichols > add Build-Java-Vendor to gfsh version --full > > > Key: GEODE-7813 > URL: https://issues.apache.org/jira/browse/GEODE-7813 > Project: Geode > Issue Type: Improvement > Components: gfsh >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > > The version info already includes the version of the compiler in > Build-Java-Version. As there are now several java compiler vendors and a > multitude of ways Geode may get compiled (various pipeline jobs, by a release > manager, by users, etc) it makes sense to record the provider of that javac > version as well. This is also required to audit that only open-source tools > are being used to produce Geode artifacts. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7813) add Build-Java-Vendor to gfsh version --full
Owen Nichols created GEODE-7813: --- Summary: add Build-Java-Vendor to gfsh version --full Key: GEODE-7813 URL: https://issues.apache.org/jira/browse/GEODE-7813 Project: Geode Issue Type: Improvement Components: gfsh Reporter: Owen Nichols The version info already includes the version of the compiler in Build-Java-Version. As there are now several java compiler vendors and a multitude of ways Geode may get compiled (various pipeline jobs, by a release manager, by users, etc) it makes sense to record the provider of that javac version as well. This is also required to audit that only open-source tools are being used to produce Geode artifacts. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-7317) PartitionedRegionDelayedRecoveryDUnitTest.testStartupDelay failed with AssertionError: Create region should not have waited to recover redundancy
[ https://issues.apache.org/jira/browse/GEODE-7317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Godwin reassigned GEODE-7317: -- Assignee: Ivan Godwin > PartitionedRegionDelayedRecoveryDUnitTest.testStartupDelay failed with > AssertionError: Create region should not have waited to recover redundancy > - > > Key: GEODE-7317 > URL: https://issues.apache.org/jira/browse/GEODE-7317 > Project: Geode > Issue Type: Bug > Components: regions >Reporter: Eric Shu >Assignee: Ivan Godwin >Priority: Major > Labels: flaky > > org.apache.geode.internal.cache.PartitionedRegionDelayedRecoveryDUnitTest > > testStartupDelay FAILED > java.lang.AssertionError: Create region should not have waited to recover > redundancy. Elapsed=8026 > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.assertTrue(Assert.java:41) > at > org.apache.geode.internal.cache.PartitionedRegionDelayedRecoveryDUnitTest.testStartupDelay(PartitionedRegionDelayedRecoveryDUnitTest.java:261) > Test run location: > =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > http://files.apachegeode-ci.info/builds/apache-develop-main/1.11.0-SNAPSHOT.0221/test-results/distributedTest/1571334780/ > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7317) PartitionedRegionDelayedRecoveryDUnitTest.testStartupDelay failed with AssertionError: Create region should not have waited to recover redundancy
[ https://issues.apache.org/jira/browse/GEODE-7317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Godwin updated GEODE-7317: --- Labels: flaky (was: ) > PartitionedRegionDelayedRecoveryDUnitTest.testStartupDelay failed with > AssertionError: Create region should not have waited to recover redundancy > - > > Key: GEODE-7317 > URL: https://issues.apache.org/jira/browse/GEODE-7317 > Project: Geode > Issue Type: Bug > Components: regions >Reporter: Eric Shu >Priority: Major > Labels: flaky > > org.apache.geode.internal.cache.PartitionedRegionDelayedRecoveryDUnitTest > > testStartupDelay FAILED > java.lang.AssertionError: Create region should not have waited to recover > redundancy. Elapsed=8026 > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.assertTrue(Assert.java:41) > at > org.apache.geode.internal.cache.PartitionedRegionDelayedRecoveryDUnitTest.testStartupDelay(PartitionedRegionDelayedRecoveryDUnitTest.java:261) > Test run location: > =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > http://files.apachegeode-ci.info/builds/apache-develop-main/1.11.0-SNAPSHOT.0221/test-results/distributedTest/1571334780/ > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7812) PutAllClientServerDistributedTest.testEventIdMisorderInPRSingleHop is failing
[
https://issues.apache.org/jira/browse/GEODE-7812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17043963#comment-17043963
]
Mark Hanson commented on GEODE-7812:
{noformat}
testEventIdMisorderInPRSingleHop
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/702
testEventIdMisorderInPRSingleHop
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/695
testEventIdMisorderInPRSingleHop
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/681
testEventIdMisorderInPRSingleHop
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/647
testEventIdMisorderInPRSingleHop
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/630
testEventIdMisorderInPRSingleHop
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/610
testEventIdMisorderInPRSingleHop
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/602
testEventIdMisorderInPRSingleHop
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/600
testEventIdMisorderInPRSingleHop
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/596
testEventIdMisorderInPRSingleHop
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/595
testEventIdMisorderInPRSingleHop
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/587
testEventIdMisorderInPRSingleHop
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/569
{noformat}
> PutAllClientServerDistributedTest.testEventIdMisorderInPRSingleHop is failing
> -
>
> Key: GEODE-7812
> URL: https://issues.apache.org/jira/browse/GEODE-7812
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Mark Hanson
>Priority: Major
> Labels: flaky
>
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.PutAllClientServerDistributedTest$$Lambda$510/1407303081.run
> in VM 3 running on Host d8813bc515cd with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
> at
> org.apache.geode.internal.cache.PutAllClientServerDistributedTest.testEventIdMisorderInPRSingleHop(PutAllClientServerDistributedTest.java:2356)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at
> org.apache.geode.test.dunit.rules.AbstractDistributedRule$1.evaluate(AbstractDistributedRule.java:59)
> at
> org.apache.geode.test.dunit.rules.AbstractDistributedRule$1.evaluate(AbstractDistributedRule.java:59)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:449)
> at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:393)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at
[jira] [Assigned] (GEODE-7812) PutAllClientServerDistributedTest.testEventIdMisorderInPRSingleHop is failing
[
https://issues.apache.org/jira/browse/GEODE-7812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson reassigned GEODE-7812:
--
Assignee: Mark Hanson
> PutAllClientServerDistributedTest.testEventIdMisorderInPRSingleHop is failing
> -
>
> Key: GEODE-7812
> URL: https://issues.apache.org/jira/browse/GEODE-7812
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Mark Hanson
>Assignee: Mark Hanson
>Priority: Major
> Labels: flaky
>
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.PutAllClientServerDistributedTest$$Lambda$510/1407303081.run
> in VM 3 running on Host d8813bc515cd with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
> at
> org.apache.geode.internal.cache.PutAllClientServerDistributedTest.testEventIdMisorderInPRSingleHop(PutAllClientServerDistributedTest.java:2356)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at
> org.apache.geode.test.dunit.rules.AbstractDistributedRule$1.evaluate(AbstractDistributedRule.java:59)
> at
> org.apache.geode.test.dunit.rules.AbstractDistributedRule$1.evaluate(AbstractDistributedRule.java:59)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:449)
> at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:393)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> at
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
> at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
> at
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:118)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
>
[jira] [Updated] (GEODE-7812) PutAllClientServerDistributedTest.testEventIdMisorderInPRSingleHop is failing
[
https://issues.apache.org/jira/browse/GEODE-7812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson updated GEODE-7812:
---
Labels: flaky (was: )
> PutAllClientServerDistributedTest.testEventIdMisorderInPRSingleHop is failing
> -
>
> Key: GEODE-7812
> URL: https://issues.apache.org/jira/browse/GEODE-7812
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Mark Hanson
>Priority: Major
> Labels: flaky
>
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.PutAllClientServerDistributedTest$$Lambda$510/1407303081.run
> in VM 3 running on Host d8813bc515cd with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
> at
> org.apache.geode.internal.cache.PutAllClientServerDistributedTest.testEventIdMisorderInPRSingleHop(PutAllClientServerDistributedTest.java:2356)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at
> org.apache.geode.test.dunit.rules.AbstractDistributedRule$1.evaluate(AbstractDistributedRule.java:59)
> at
> org.apache.geode.test.dunit.rules.AbstractDistributedRule$1.evaluate(AbstractDistributedRule.java:59)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:449)
> at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:393)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> at
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
> at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
> at
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:118)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
>
[jira] [Created] (GEODE-7812) PutAllClientServerDistributedTest.testEventIdMisorderInPRSingleHop is failing
Mark Hanson created GEODE-7812:
--
Summary:
PutAllClientServerDistributedTest.testEventIdMisorderInPRSingleHop is failing
Key: GEODE-7812
URL: https://issues.apache.org/jira/browse/GEODE-7812
Project: Geode
Issue Type: Bug
Components: tests
Reporter: Mark Hanson
{noformat}
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.internal.cache.PutAllClientServerDistributedTest$$Lambda$510/1407303081.run
in VM 3 running on Host d8813bc515cd with 4 VMs
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
at
org.apache.geode.internal.cache.PutAllClientServerDistributedTest.testEventIdMisorderInPRSingleHop(PutAllClientServerDistributedTest.java:2356)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at
org.apache.geode.test.dunit.rules.AbstractDistributedRule$1.evaluate(AbstractDistributedRule.java:59)
at
org.apache.geode.test.dunit.rules.AbstractDistributedRule$1.evaluate(AbstractDistributedRule.java:59)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:449)
at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:393)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
at
org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
at
org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at
org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
at
org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
at
org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:118)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at
[jira] [Resolved] (GEODE-7803) provide a way to create an internal region without using deprecated classes
[ https://issues.apache.org/jira/browse/GEODE-7803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider resolved GEODE-7803. - Fix Version/s: 1.13.0 Resolution: Fixed > provide a way to create an internal region without using deprecated classes > --- > > Key: GEODE-7803 > URL: https://issues.apache.org/jira/browse/GEODE-7803 > Project: Geode > Issue Type: Improvement > Components: regions >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Fix For: 1.13.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Currently geode has some places that create internal regions (using > InternalRegionArguments) that use deprecated classes to do this. It would be > nice if an internal way was provided to do this that was not deprecated. > GEODE-7799 is doing this. Once that fix is merged in then the > RegionFactoryImpl enhancement it add could be used in the places that use > deprecated apis to specify InternalRegionArguments -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7803) provide a way to create an internal region without using deprecated classes
[ https://issues.apache.org/jira/browse/GEODE-7803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17043959#comment-17043959 ] ASF subversion and git services commented on GEODE-7803: Commit b082c0352b0a96c3dc1cf07caaf1f7f2e4fb8177 in geode's branch refs/heads/develop from Darrel Schneider [ https://gitbox.apache.org/repos/asf?p=geode.git;h=b082c03 ] GEODE-7803: provide undeprecated internal region create (#4722) You can now use InternalRegionFactory to create a region configured with InternalRegionArguments. No need to use the deprecated AttributesFactory. InternalRegionFactory used to be named RegionFactoryImpl. > provide a way to create an internal region without using deprecated classes > --- > > Key: GEODE-7803 > URL: https://issues.apache.org/jira/browse/GEODE-7803 > Project: Geode > Issue Type: Improvement > Components: regions >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > Currently geode has some places that create internal regions (using > InternalRegionArguments) that use deprecated classes to do this. It would be > nice if an internal way was provided to do this that was not deprecated. > GEODE-7799 is doing this. Once that fix is merged in then the > RegionFactoryImpl enhancement it add could be used in the places that use > deprecated apis to specify InternalRegionArguments -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-6532) Convert compile dependencies to implementation/api dependencies
[
https://issues.apache.org/jira/browse/GEODE-6532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17043902#comment-17043902
]
ASF subversion and git services commented on GEODE-6532:
Commit e974408674428770c35be3b444e022d2b9f1973e in geode-examples's branch
refs/heads/master from Robert Houghton
[ https://gitbox.apache.org/repos/asf?p=geode-examples.git;h=e974408 ]
GEODE-6532: Dependency changes to examples related to the Geode fix. (#92)
Several transitive dependencies will be marked 'runtime' not 'compile'
in the POM from geode, causing examples to not miss symbols. Declare
those dependencies outright.
> Convert compile dependencies to implementation/api dependencies
> ---
>
> Key: GEODE-6532
> URL: https://issues.apache.org/jira/browse/GEODE-6532
> Project: Geode
> Issue Type: Improvement
> Components: build, docs
>Reporter: Patrick Rhomberg
>Assignee: Dan Smith
>Priority: Major
> Fix For: 1.9.0
>
> Time Spent: 4h
> Remaining Estimate: 0h
>
> The {{compile}} configuration has been deprecated for some time. {{api}}
> will behave similarly, whereas {{implementation}} will appear to be a
> {{runtime}} dependency to consumers.
> This will require examining our public API so that we may correctly declare
> which dependencies are {{api}}. When a PR is made, an email should be sent
> to the dev@ and/or user@ lists warning that those consuming internal APIs
> (against best practice) may experience breakages if their own dependencies
> are not properly declared. Similarly, a release note on this topic could be
> helpful to those upgrading.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-7811) CI Failure: FunctionOnServersRetryDUnitTest hung during tearDown
Eric Shu created GEODE-7811:
---
Summary: CI Failure: FunctionOnServersRetryDUnitTest hung during
tearDown
Key: GEODE-7811
URL: https://issues.apache.org/jira/browse/GEODE-7811
Project: Geode
Issue Type: Bug
Components: ci
Reporter: Eric Shu
Test hung during tearDown:
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/1589
{noformat}
"Test worker" #25 prio=5 os_prio=0 tid=0x7fe980a3d000 nid=0x5e runnable
[0x7fe946fba000]
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
at java.net.SocketInputStream.read(SocketInputStream.java:171)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
at java.io.BufferedInputStream.read(BufferedInputStream.java:265)
- locked <0xd0922a30> (a java.io.BufferedInputStream)
at java.io.DataInputStream.readByte(DataInputStream.java:265)
at
sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:240)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:161)
at
java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:227)
at
java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:179)
at com.sun.proxy.$Proxy58.executeMethodOnObject(Unknown Source)
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:607)
at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
at org.apache.geode.test.dunit.Invoke.invokeInEveryVM(Invoke.java:59)
at org.apache.geode.test.dunit.Invoke.invokeInEveryVM(Invoke.java:48)
at
org.apache.geode.test.dunit.rules.DistributedRule$TearDown.doTearDown(DistributedRule.java:214)
at
org.apache.geode.test.dunit.rules.DistributedRule.after(DistributedRule.java:149)
at
org.apache.geode.test.dunit.rules.AbstractDistributedRule.afterDistributedTest(AbstractDistributedRule.java:81)
at
org.apache.geode.test.dunit.rules.AbstractDistributedRule$1.evaluate(AbstractDistributedRule.java:61)
at
org.apache.geode.test.dunit.rules.AbstractDistributedRule$1.evaluate(AbstractDistributedRule.java:59)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at
junitparams.internal.ParameterisedTestMethodRunner.runMethodInvoker(ParameterisedTestMethodRunner.java:47)
at
junitparams.internal.ParameterisedTestMethodRunner.runTestMethod(ParameterisedTestMethodRunner.java:40)
at
junitparams.internal.ParameterisedTestClassRunner.runParameterisedTest(ParameterisedTestClassRunner.java:146)
at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:446)
at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:393)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at
org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:138)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
at
org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
at
org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at
org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
at
[jira] [Assigned] (GEODE-7810) Cannot form connection to alert listener should be logged at WARNING level
[
https://issues.apache.org/jira/browse/GEODE-7810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund reassigned GEODE-7810:
Assignee: Kirk Lund
> Cannot form connection to alert listener should be logged at WARNING level
> --
>
> Key: GEODE-7810
> URL: https://issues.apache.org/jira/browse/GEODE-7810
> Project: Geode
> Issue Type: Bug
> Components: logging, management
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
>
> The Cannot form connection to alert listener log message is currently being
> logged at FATAL level. This should be logged as a WARNING (or ERROR) instead.
> {noformat}
> java.io.IOException: Cannot form connection to alert listener
> 172.17.0.7(locator2:1:locator):41002
> at
> org.apache.geode.internal.tcp.Connection.createSender(Connection.java:998)
> at
> org.apache.geode.internal.tcp.ConnectionTable.handleNewPendingConnection(ConnectionTable.java:288)
> at
> org.apache.geode.internal.tcp.ConnectionTable.getSharedConnection(ConnectionTable.java:392)
> at
> org.apache.geode.internal.tcp.ConnectionTable.get(ConnectionTable.java:567)
> at
> org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:782)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.getConnections(DirectChannel.java:545)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:334)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:248)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:604)
> at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:348)
> at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:293)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2061)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1988)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2025)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1085)
> at
> org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$null$0(ClusterAlertMessaging.java:92)
> at
> org.apache.geode.alerting.internal.spi.AlertingAction.execute(AlertingAction.java:34)
> at
> org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$sendAlert$1(ClusterAlertMessaging.java:70)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-7810) Cannot form connection to alert listener should be logged at WARNING level
Kirk Lund created GEODE-7810:
Summary: Cannot form connection to alert listener should be logged
at WARNING level
Key: GEODE-7810
URL: https://issues.apache.org/jira/browse/GEODE-7810
Project: Geode
Issue Type: Bug
Components: logging, management
Reporter: Kirk Lund
The Cannot form connection to alert listener log message is currently being
logged at FATAL level. This should be logged as a WARNING (or ERROR) instead.
{noformat}
java.io.IOException: Cannot form connection to alert listener
172.17.0.7(locator2:1:locator):41002
at
org.apache.geode.internal.tcp.Connection.createSender(Connection.java:998)
at
org.apache.geode.internal.tcp.ConnectionTable.handleNewPendingConnection(ConnectionTable.java:288)
at
org.apache.geode.internal.tcp.ConnectionTable.getSharedConnection(ConnectionTable.java:392)
at
org.apache.geode.internal.tcp.ConnectionTable.get(ConnectionTable.java:567)
at
org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:782)
at
org.apache.geode.distributed.internal.direct.DirectChannel.getConnections(DirectChannel.java:545)
at
org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:334)
at
org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:248)
at
org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:604)
at
org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:348)
at
org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:293)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2061)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1988)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2025)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1085)
at
org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$null$0(ClusterAlertMessaging.java:92)
at
org.apache.geode.alerting.internal.spi.AlertingAction.execute(AlertingAction.java:34)
at
org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$sendAlert$1(ClusterAlertMessaging.java:70)
at
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[
https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17031164#comment-17031164
]
John Blum edited comment on GEODE-7763 at 2/24/20 7:37 PM:
---
Seems that with quite a bit of additional memory (much more than was required
with Apache Geode 1.9) I am able to get the test to pass running Apache Geode
1.11 and the SSDG test class with 180 Threads and 8000 Operations. I set both
the client and server JVMs to 4g of Heap. Of course, I wonder if even more
efficient tuning of the JVM (i.e. individual Heap memory regions, e.g. old gen
vs. young gen (eden + survivor space)) would have an effect without having to
double the Heap size for increasingly larger Operation and Thread counts.
Other factors might be different garbage collectors or even different JVMs.
I started considering this more once I consistently got more OOME errors.
However, (more than) doubling the memory size (up from the increase to 2 GB,
which was unnecessary under 1.9) is not really practical given the test
execution time is exponentially longer (~15 min) than it was when running under
Apache Geode 1.9 (~30-45 seconds).
Seemingly, the GC is hard at work with cleaning up all the non-apparent
garbage, which hopefully the stats files will reveal.
I should also note that I am running with JDK 1.8.2_192...
{code:java}
$ java -version
java version "1.8.0_192"
Java(TM) SE Runtime Environment (build 1.8.0_192-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.192-b12, mixed mode)
jblum-mbpro-2:spring-session-data-geode jblum$
{code}
However, I not able to get the test to run with 180 Threads and 10,000
Operations with 4g of Heap on both the client and server.
was (Author: jblum):
Seems that with quite a bit of additional memory (much more than was required
with Apache Geode 1.9) I am able to get the test to pass running Apache Geode
1.11 and the SSDG test class with 180 Threads and 8000 Operations. I set both
the client and server JVMs to 4g of Heap. Of course, I wonder if more
efficient tuning the JVM (i.e. individual Heap memory regions, e.g. old gen vs.
young gen (eden + survivor space)) would have an effect without having to
double the Heap size for increasingly larger Operation and Thread counts.
Other factors might be different garbage collectors or even different JVMs.
I started considering this more once I consistently got more OOME errors.
However, (more than) doubling the memory size (up from the increase to 2 GB,
which was unnecessary under 1.9) is not really practical given the test
execution time is exponentially longer (~15 min) than it was when running under
Apache Geode 1.9 (~30-45 seconds).
Seemingly, the GC is hard at work with cleaning up all the non-apparent
garbage, which hopefully the stats files will reveal.
I should also note that I am running with JDK 1.8.2_192...
{code:java}
$ java -version
java version "1.8.0_192"
Java(TM) SE Runtime Environment (build 1.8.0_192-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.192-b12, mixed mode)
jblum-mbpro-2:spring-session-data-geode jblum$
{code}
However, I not able to get the test to run with 180 Threads and 10,000
Operations with 4g of Heap on both the client and server.
> Apache Geode 1.11 severely and negatively impacts performance and resource
> utilization
> --
>
> Key: GEODE-7763
> URL: https://issues.apache.org/jira/browse/GEODE-7763
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.10.0, 1.11.0
>Reporter: John Blum
>Priority: Critical
> Labels: performance
> Attachments: 1.11-client-stats.gfs, 1.11-server-stats.gfs,
> 1.11_thread_dumps.rtf, 1.9-client-stats.gfs, 1.9-server-stats.gfs, 1.9.log,
> apache-geode-1.10-client-server-interaction-output.txt,
> apache-geode-1.10-client-server-startup-output.txt,
> apache-geode-1.11-client-server-interaction-output.txt,
> apache-geode-1.11-client-server-startup-output.txt,
> geode-7763-geode-changes.diff, geode-7763-ssdg-changes.diff
>
>
> This problem was first observed in Apache Geode 1.11.0. The problem was not
> present in Apache Geode 1.9.2. This problem is an issue for Apache Geode
> 1.10 as well!
> After upgrading _Spring Session for Apache Geode_ (SSDG) 2.3 to _Spring Data
> for Apache Geode_ (SDG) Neumann/2.3, which is based on Apache Geode 1.11,
> this problem with SSDG's test suite started occurring.
> _Spring Session for Apache Geode_ (SSDG) 2.2, which is based on _Spring Data
> for Apache Geode_ (SDG) Moore/2.2, pulls in Apache Geode 1.9.2. This problem
> did not occur in SSDG 2.2. with Apache Geode 1.9.2.
> Out of curiosity, I wondered whether this problem affects (i.e. was actually
> introduced in)
[jira] [Updated] (GEODE-7796) CI: org.apache.geode.distributed.LocatorDUnitTest testCrashLocatorMultipleTimes hung
[ https://issues.apache.org/jira/browse/GEODE-7796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Burcham updated GEODE-7796: Fix Version/s: (was: 1.13.0) 1.12.0 > CI: org.apache.geode.distributed.LocatorDUnitTest > testCrashLocatorMultipleTimes hung > > > Key: GEODE-7796 > URL: https://issues.apache.org/jira/browse/GEODE-7796 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Jinmei Liao >Priority: Major > Fix For: 1.12.0 > > Time Spent: 20m > Remaining Estimate: 0h > > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/1563 > in the artifacts callbacks/dunit-hang.txt, > Started @ 2020-02-11 00:30:32.499 + > 2020-02-11 01:07:59.054 + org.apache.geode.distributed.LocatorDUnitTest > testCrashLocatorMultipleTimes > Ended @ 2020-02-11 02:05:31.891 + > and the stacktraces shows thread gets blocked for a long time. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-7783) Introduce dispersion on connections expiration
[ https://issues.apache.org/jira/browse/GEODE-7783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Bender closed GEODE-7783. --- > Introduce dispersion on connections expiration > -- > > Key: GEODE-7783 > URL: https://issues.apache.org/jira/browse/GEODE-7783 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Major > Labels: pull-request-available > Time Spent: 1h 20m > Remaining Estimate: 0h > > We are suffering performance issues due to c++ native client connections > expiration. > It would be convenient to introduce some dispersion so not all connections > are closed and open at the same time. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7783) Introduce dispersion on connections expiration
[ https://issues.apache.org/jira/browse/GEODE-7783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Bender resolved GEODE-7783. - Resolution: Fixed > Introduce dispersion on connections expiration > -- > > Key: GEODE-7783 > URL: https://issues.apache.org/jira/browse/GEODE-7783 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Major > Labels: pull-request-available > Time Spent: 1h 20m > Remaining Estimate: 0h > > We are suffering performance issues due to c++ native client connections > expiration. > It would be convenient to introduce some dispersion so not all connections > are closed and open at the same time. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7783) Introduce dispersion on connections expiration
[ https://issues.apache.org/jira/browse/GEODE-7783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17043661#comment-17043661 ] ASF subversion and git services commented on GEODE-7783: Commit 0d9955fc23b40fca47c31359b9082d9d19e59499 in geode-native's branch refs/heads/develop from Alberto Bustamante Reyes [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=0d9955f ] GEODE-7783: Introduce dispersion in connection expiration (#577) * We are suffering performance issues due to c++ native client connections expiration. * Introducing some dispersion so not all connections are closed and open at the same time. > Introduce dispersion on connections expiration > -- > > Key: GEODE-7783 > URL: https://issues.apache.org/jira/browse/GEODE-7783 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Major > Labels: pull-request-available > Time Spent: 1h 20m > Remaining Estimate: 0h > > We are suffering performance issues due to c++ native client connections > expiration. > It would be convenient to introduce some dispersion so not all connections > are closed and open at the same time. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7809) Distributed management operation enhancements
Joris Melchior created GEODE-7809: - Summary: Distributed management operation enhancements Key: GEODE-7809 URL: https://issues.apache.org/jira/browse/GEODE-7809 Project: Geode Issue Type: Improvement Components: management Reporter: Joris Melchior Fix For: 1.13.0 Distributed management operations need the following improvements: * Operations that have no end-date will currently be cleaned up. We should pick a set time after the start of an operation that the record will have to live in the Region of record. This way even operations without and end-date will get cleaned up at some point. * Currently operations will be cleaned out of the Region of record 2 hours after completion. This is considered too quick so we need to pick a longer time period and change it to that. We can also consider making this time configurable. * When the locator on which the operation is started disappears for any reason before the distributed operation has finished the end of the operation will not be recorded. We should find a way to make sure that we can record an end of an operation even if the original request locator disappears before the operation completion. (this assumes that the cluster has more than one locator running) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7809) Distributed management operation enhancements
[ https://issues.apache.org/jira/browse/GEODE-7809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joris Melchior updated GEODE-7809: -- Priority: Minor (was: Major) > Distributed management operation enhancements > - > > Key: GEODE-7809 > URL: https://issues.apache.org/jira/browse/GEODE-7809 > Project: Geode > Issue Type: Improvement > Components: management >Reporter: Joris Melchior >Priority: Minor > Fix For: 1.13.0 > > > Distributed management operations need the following improvements: > * Operations that have no end-date will currently be cleaned up. We should > pick a set time after the start of an operation that the record will have to > live in the Region of record. This way even operations without and end-date > will get cleaned up at some point. > * Currently operations will be cleaned out of the Region of record 2 hours > after completion. This is considered too quick so we need to pick a longer > time period and change it to that. We can also consider making this time > configurable. > * When the locator on which the operation is started disappears for any > reason before the distributed operation has finished the end of the operation > will not be recorded. We should find a way to make sure that we can record an > end of an operation even if the original request locator disappears before > the operation completion. (this assumes that the cluster has more than one > locator running) -- This message was sent by Atlassian Jira (v8.3.4#803005)
