[jira] [Resolved] (GEODE-5838) Suppress javadoc generation warnings
[
https://issues.apache.org/jira/browse/GEODE-5838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella resolved GEODE-5838.
-
Resolution: Fixed
Fix Version/s: 1.8.0
Changes merged into {{develop}} through
[4025ebf|https://github.com/apache/geode/commit/4025ebfd3396d4dda5f7c1d90540266aeed8c448].
> Suppress javadoc generation warnings
>
>
> Key: GEODE-5838
> URL: https://issues.apache.org/jira/browse/GEODE-5838
> Project: Geode
> Issue Type: Improvement
> Components: build
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>Priority: Trivial
> Labels: pull-request-available
> Fix For: 1.8.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> When compiling the project, the task {{geode-dunit:javadoc}} task generates
> the following warnings, polluting the build output:
> {noformat}
> > Task :geode-dunit:javadoc
> /Users/jramos/git/geode/geode-dunit/src/main/java/org/apache/geode/security/templates/SimpleAccessController.java:32:
> warning - Tag @link: reference not found:
> org.apache.geode.examples.SimpleSecurityManager
> /Users/jramos/git/geode/geode-dunit/src/main/java/org/apache/geode/security/templates/SimpleAuthenticator.java:34:
> warning - Tag @link: reference not found:
> org.apache.geode.examples.SimpleSecurityManager
> /Users/jramos/git/geode/geode-dunit/src/main/java/org/apache/geode/security/templates/SimpleAccessController.java:32:
> warning - Tag @link: reference not found:
> org.apache.geode.examples.SimpleSecurityManager
> /Users/jramos/git/geode/geode-dunit/src/main/java/org/apache/geode/security/templates/SimpleAuthenticator.java:34:
> warning - Tag @link: reference not found:
> org.apache.geode.examples.SimpleSecurityManager
> /Users/jramos/git/geode/geode-dunit/src/main/java/org/apache/geode/security/templates/SimpleAccessController.java:32:
> warning - Tag @link: reference not found:
> org.apache.geode.examples.SimpleSecurityManager
> /Users/jramos/git/geode/geode-dunit/src/main/java/org/apache/geode/security/templates/SimpleAuthenticator.java:34:
> warning - Tag @link: reference not found:
> org.apache.geode.examples.SimpleSecurityManager
> {noformat}
> The {{@link}} tag incorrectly references a test class (it should reference
> the production interface), which is not part of the build class path when
> generating the {{javadocs}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5830) ssl-enabled-components does not actually support "none"
[
https://issues.apache.org/jira/browse/GEODE-5830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella resolved GEODE-5830.
-
Resolution: Fixed
Fix Version/s: 1.8.0
Merged into {{develop}} through commit
[16cd4ae|https://github.com/apache/geode/commit/16cd4ae114db101d6030bdbeecdd09b4f932a61e].
> ssl-enabled-components does not actually support "none"
> ---
>
> Key: GEODE-5830
> URL: https://issues.apache.org/jira/browse/GEODE-5830
> Project: Geode
> Issue Type: Bug
> Components: configuration, docs, messaging
>Reporter: Galen O'Sullivan
>Assignee: Juan José Ramos Cassella
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.8.0
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> ConfigurationProperties.ssl-enabled-components says in its docs that "none"
> is a valid setting, but actually that throws an error when the Cache is
> created. This could be made a valid option or the docs just corrected.
> Docs:
> {code}
> /**
>* Options: "all","server","cluster","gateway","web","jmx","none" --
> As described
>* {@link org.apache.geode.security.SecurableCommunicationChannels}
> Since: Geode 1.0
>*/
> String SSL_ENABLED_COMPONENTS = "ssl-enabled-components";
> {code}
> This test fails with the exception that follows it:
> {code}
> @Test
> public void test() {
> final Properties properties = new Properties();
> properties.setProperty(ConfigurationProperties.SSL_ENABLED_COMPONENTS,
> "none");
> try (final Cache cache = new CacheFactory(properties).create()) {
> }
> }
> {code}
> {noformat}
> java.lang.IllegalArgumentException: org.apache.geode.GemFireConfigException:
> There is no registered component for the name: none
> at
> org.apache.geode.internal.AbstractConfig.commaDelimitedStringToSecurableCommunicationChannels(AbstractConfig.java:403)
> at
> org.apache.geode.internal.AbstractConfig.setAttribute(AbstractConfig.java:275)
> at
> org.apache.geode.distributed.internal.DistributionConfigImpl.initialize(DistributionConfigImpl.java:1623)
> at
> org.apache.geode.distributed.internal.DistributionConfigImpl.(DistributionConfigImpl.java:984)
> at
> org.apache.geode.distributed.internal.DistributionConfigImpl.(DistributionConfigImpl.java:893)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.(InternalDistributedSystem.java:530)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:354)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:343)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:335)
> at
> org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:211)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:219)
> at
> org.apache.geode.distributed.ConfigurationPropertiesTest.test(ConfigurationPropertiesTest.java:18)
> 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.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWith
[jira] [Commented] (GEODE-5821) Authentication tests fail with client version 1.4: sun.misc.ObjectInputFilter is not available
[
https://issues.apache.org/jira/browse/GEODE-5821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16648029#comment-16648029
]
ASF subversion and git services commented on GEODE-5821:
Commit 2667fb48fc02b702d5b26e35525acd1c4e1a98e3 in geode's branch
refs/heads/develop from jinmeiliao
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=2667fb4 ]
GEODE-5821: exclude geode 1.4 when testing with java 9+ (#2576)
> Authentication tests fail with client version 1.4: sun.misc.ObjectInputFilter
> is not available
> --
>
> Key: GEODE-5821
> URL: https://issues.apache.org/jira/browse/GEODE-5821
> Project: Geode
> Issue Type: Sub-task
>Reporter: Jinmei Liao
>Assignee: Jinmei Liao
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1h
> Remaining Estimate: 0h
>
> ClientAuthDUnitTest. authWithCorrectPasswordShouldPass[140]
> ClientAuthDUnitTest. authWithIncorrectPasswordWithSubscriptionEnabled[140]
> ClientAuthDUnitTest. authWithIncorrectPasswordWithSubscriptionNotEnabled[140]
> ClientAuthenticationDUnitTest. testCredentialsForNotifications[140]
> ClientAuthenticationDUnitTest. testCredentialsWithFailover[140]
> ClientAuthenticationDUnitTest. testInvalidAuthInit[140]
> ClientAuthenticationDUnitTest. testInvalidCredentials[140]
> ClientAuthenticationDUnitTest. testNoAuthInitWithCredentials[140]
> ClientAuthenticationDUnitTest. testNoAuthenticatorWithCredentials[140]
> ClientAuthenticationDUnitTest. testNoCredentials[140]
> ClientAuthenticationDUnitTest. testValidCredentials[140]
> ClientAuthenticationPart2DUnitTest. testInvalidAuthInitForMultipleUsers[6]
> ClientAuthenticationPart2DUnitTest. testInvalidCredentialsForMultipleUsers[6]
> ClientAuthenticationPart2DUnitTest.
> testNoAuthInitWithCredentialsForMultipleUsers[6]
> ClientAuthenticationPart2DUnitTest.
> testNoAuthenticatorWithCredentialsForMultipleUsers[6]
> ClientAuthenticationPart2DUnitTest.
> testNoCredentialsForMultipleUsersCantRegisterMetadata[6]
> ClientAuthenticationPart2DUnitTest. testNoCredentialsForMultipleUsers[6]
> ClientAuthorizationLegacyConfigurationDUnitTest.
> everythingFailsWithInvalidAccessor[clientVersion=140]
> ClientAuthorizationLegacyConfigurationDUnitTest.
> everythingFailsWithInvalidAuthenticator[clientVersion=140]
> ClientDataAuthorizationUsingLegacySecurityDUnitTest.
> dataReadCannotPut[clientVersion=140]
> ClientDataAuthorizationUsingLegacySecurityDUnitTest.
> dataReadClientCanGet[clientVersion=140]
> ClientDataAuthorizationUsingLegacySecurityDUnitTest.
> dataWriteCannotGet[clientVersion=140]
> ClientDataAuthorizationUsingLegacySecurityDUnitTest.
> dataWriteClientCanPut[clientVersion=140]
> ClientDataAuthorizationUsingLegacySecurityWithFailoverDUnitTest.
> dataReaderCanRegisterAndUnregisterAcrossFailover[clientVersion=140]
> ClientDataAuthorizationUsingLegacySecurityWithFailoverDUnitTest.
> dataReaderCanStillOnlyReadAfterFailover[clientVersion=140]
> ClientDataAuthorizationUsingLegacySecurityWithFailoverDUnitTest.
> dataWriterCanStillOnlyWriteAfterFailover[clientVersion=140]
> ClientDataAuthorizationUsingLegacySecurityWithFailoverDUnitTest.
> dataWriterCannotRegisterInterestAcrossFailover[clientVersion=140]
> ClusterStartupRuleCanSpecifyOlderVersionsDUnitTest.
> clientVersioningTest[version=140]
> ClusterStartupRuleCanSpecifyOlderVersionsDUnitTest.
> locatorVersioningTest[version=140]
> ClusterStartupRuleCanSpecifyOlderVersionsDUnitTest.
> serverVersioningTest[version=140]
> ClusterStartupRuleCanSpecifyOlderVersionsDUnitTest.
> serverWithEmbeddedLocatorVersioningTest[version=140]
>
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.security.ClientAuthenticationTestCase$$Lambda$160/1869841081.run
> in VM 2 running on Host 08cf4958ddd8 with 4 VMs with version 140
> at org.apache.geode.test.dunit.VM.invoke(VM.java:450)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:419)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:362)
> at
> org.apache.geode.security.ClientAuthenticationTestCase.createClient1NoException(ClientAuthenticationTestCase.java:710)
> at
> org.apache.geode.security.ClientAuthenticationTestCase.doTestCredentialsForNotifications(ClientAuthenticationTestCase.java:580)
> at
> org.apache.geode.security.ClientAuthenticationDUnitTest.testCredentialsForNotifications(ClientAuthenticationDUnitTest.java:99)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
[jira] [Commented] (GEODE-5846) Add pipeline jobs for testing on Java 11
[ https://issues.apache.org/jira/browse/GEODE-5846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16648036#comment-16648036 ] ASF subversion and git services commented on GEODE-5846: Commit 385f5556f4d2f115edeae1d022fff3deb9098499 in geode's branch refs/heads/develop from Jacob Barrett [ https://gitbox.apache.org/repos/asf?p=geode.git;h=385f555 ] GEODE-5846: Override timeout on JDK11 > Add pipeline jobs for testing on Java 11 > > > Key: GEODE-5846 > URL: https://issues.apache.org/jira/browse/GEODE-5846 > Project: Geode > Issue Type: Sub-task > Components: ci >Reporter: Dick Cavender >Priority: Major > Fix For: 1.8.0 > > > Duplicate test jobs to cover permutations of compile JVM and test JVM. At > minimum, need to test OpenJdk8-compiled geode on both OpenJdk8 and OpenJdk11. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5858) flaky DurableClientTestCase.testDurableClientPrimaryUpdate on Windows
[
https://issues.apache.org/jira/browse/GEODE-5858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16648046#comment-16648046
]
ASF subversion and git services commented on GEODE-5858:
Commit f8750125a6fd5f65c5a400e20af1483f4734addb in geode's branch
refs/heads/develop from [~sai.boorlaga...@gmail.com]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=f875012 ]
GEODE-5858: fix failing DurableClientTestCase on Windows (#2602)
On windows it is observed that asserting the queue size to be 1
fails sometimes as it can be 2. So a wait is added to make sure
the queue sz becomes zero before a durable client is restarted.
> flaky DurableClientTestCase.testDurableClientPrimaryUpdate on Windows
> -
>
> Key: GEODE-5858
> URL: https://issues.apache.org/jira/browse/GEODE-5858
> Project: Geode
> Issue Type: Bug
> Components: ci
>Reporter: Sai Boorlagadda
>Assignee: Sai Boorlagadda
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {code}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase$2.run in
> VM 0 running on Host
> c9e2363b-e155-4e72-bc44-9145659760b4.windows-worker-debug-tests.private.concourse.bosh
> with 4 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:433)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:402)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:361)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.testDurableClientPrimaryUpdate(DurableClientTestCase.java:260)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:106)
> 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:66)
> 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)
>
[jira] [Commented] (GEODE-5846) Add pipeline jobs for testing on Java 11
[ https://issues.apache.org/jira/browse/GEODE-5846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16648058#comment-16648058 ] ASF subversion and git services commented on GEODE-5846: Commit 687bfb163b2e6a1ec0b29ea81fa9532c659f7c02 in geode's branch refs/heads/develop from Jacob Barrett [ https://gitbox.apache.org/repos/asf?p=geode.git;h=687bfb1 ] GEODE-5846: Fixes override of JDK 8 parameters > Add pipeline jobs for testing on Java 11 > > > Key: GEODE-5846 > URL: https://issues.apache.org/jira/browse/GEODE-5846 > Project: Geode > Issue Type: Sub-task > Components: ci >Reporter: Dick Cavender >Priority: Major > Fix For: 1.8.0 > > > Duplicate test jobs to cover permutations of compile JVM and test JVM. At > minimum, need to test OpenJdk8-compiled geode on both OpenJdk8 and OpenJdk11. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5846) Add pipeline jobs for testing on Java 11
[ https://issues.apache.org/jira/browse/GEODE-5846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16648064#comment-16648064 ] ASF subversion and git services commented on GEODE-5846: Commit bed907afef7225552cd0f908d54edf7c1e869cd8 in geode's branch refs/heads/develop from Jacob Barrett [ https://gitbox.apache.org/repos/asf?p=geode.git;h=bed907a ] GEODE-5846: Fixes extra character in template. > Add pipeline jobs for testing on Java 11 > > > Key: GEODE-5846 > URL: https://issues.apache.org/jira/browse/GEODE-5846 > Project: Geode > Issue Type: Sub-task > Components: ci >Reporter: Dick Cavender >Priority: Major > Fix For: 1.8.0 > > > Duplicate test jobs to cover permutations of compile JVM and test JVM. At > minimum, need to test OpenJdk8-compiled geode on both OpenJdk8 and OpenJdk11. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-5859) Extract String code from test classes
Patrick Rhomberg created GEODE-5859:
---
Summary: Extract String code from test classes
Key: GEODE-5859
URL: https://issues.apache.org/jira/browse/GEODE-5859
Project: Geode
Issue Type: Improvement
Components: tests
Reporter: Patrick Rhomberg
In several Acceptance and DUnit tests, in particular in tests dealing with
{{deploy jar}}, we commonly have code blocks like the following:
{noformat}
private File createJar() throws IOException {
File jarToDeploy = new File(gfsh.getTemporaryFolder().getRoot(),
"ourJar.jar");
String classContents =
"import org.apache.geode.cache.util.ObjectSizer; import
org.apache.geode.cache.Declarable;public class MySizer implements ObjectSizer,
Declarable { public int sizeof(Object o) { return 10; } }";
JarBuilder jarBuilder = new JarBuilder();
jarBuilder.buildJar(jarToDeploy, classContents);
return jarToDeploy;
}
{noformat}
This causes tests to fail when run in Java11, as code compiled in the Java11
test VM cannot execute on the Java8-compiled server VMs.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5859) Java11 testing fails due to String 'code' compiled in test VM
[
https://issues.apache.org/jira/browse/GEODE-5859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg updated GEODE-5859:
Summary: Java11 testing fails due to String 'code' compiled in test VM
(was: Extract String code from test classes)
> Java11 testing fails due to String 'code' compiled in test VM
> -
>
> Key: GEODE-5859
> URL: https://issues.apache.org/jira/browse/GEODE-5859
> Project: Geode
> Issue Type: Improvement
> Components: tests
>Reporter: Patrick Rhomberg
>Priority: Major
>
> In several Acceptance and DUnit tests, in particular in tests dealing with
> {{deploy jar}}, we commonly have code blocks like the following:
> {noformat}
> private File createJar() throws IOException {
> File jarToDeploy = new File(gfsh.getTemporaryFolder().getRoot(),
> "ourJar.jar");
> String classContents =
> "import org.apache.geode.cache.util.ObjectSizer; import
> org.apache.geode.cache.Declarable;public class MySizer implements
> ObjectSizer, Declarable { public int sizeof(Object o) { return 10; } }";
> JarBuilder jarBuilder = new JarBuilder();
> jarBuilder.buildJar(jarToDeploy, classContents);
> return jarToDeploy;
> }
> {noformat}
> This causes tests to fail when run in Java11, as code compiled in the Java11
> test VM cannot execute on the Java8-compiled server VMs.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-5860) Extract String code from ConfigureEvictionThroughGfsh
Patrick Rhomberg created GEODE-5860: --- Summary: Extract String code from ConfigureEvictionThroughGfsh Key: GEODE-5860 URL: https://issues.apache.org/jira/browse/GEODE-5860 Project: Geode Issue Type: Sub-task Reporter: Patrick Rhomberg -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5228) ServerLauncherRemoteFileIntegrationTest fails intermittently with IllegalStateException vf.gf.server.status is blank
[
https://issues.apache.org/jira/browse/GEODE-5228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith updated GEODE-5228:
-
Labels: ServerLauncher ci flaky swat (was: ServerLauncher ci flaky)
> ServerLauncherRemoteFileIntegrationTest fails intermittently with
> IllegalStateException vf.gf.server.status is blank
>
>
> Key: GEODE-5228
> URL: https://issues.apache.org/jira/browse/GEODE-5228
> Project: Geode
> Issue Type: Bug
> Components: management, tests
>Reporter: Kirk Lund
>Priority: Minor
> Labels: ServerLauncher, ci, flaky, swat
>
> {noformat}
> java.lang.IllegalStateException: Status file
> '/tmp/build/ae3c03f4/built-geode/tmp/junit5775773082469887234/vf.gf.server.status'
> is blank
> at
> org.apache.geode.internal.process.FileProcessController.status(FileProcessController.java:152)
> at
> org.apache.geode.internal.process.FileProcessController.status(FileProcessController.java:89)
> at
> org.apache.geode.distributed.ServerLauncher.statusWithWorkingDirectory(ServerLauncher.java:1102)
> at
> org.apache.geode.distributed.ServerLauncher.status(ServerLauncher.java:1050)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.lambda$awaitStart$1(ServerLauncherRemoteIntegrationTestCase.java:198)
> at
> org.awaitility.core.AssertionCondition$1.eval(AssertionCondition.java:55)
> at
> org.awaitility.core.ConditionAwaiter$ConditionPoller.run(ConditionAwaiter.java:215)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5860) Extract String code from ConfigureEvictionThroughGfsh
[ https://issues.apache.org/jira/browse/GEODE-5860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-5860: -- Labels: pull-request-available (was: ) > Extract String code from ConfigureEvictionThroughGfsh > - > > Key: GEODE-5860 > URL: https://issues.apache.org/jira/browse/GEODE-5860 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Rhomberg >Priority: Major > Labels: pull-request-available > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (GEODE-5711) create jndi-binding gfsh command does not hide password
[
https://issues.apache.org/jira/browse/GEODE-5711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karen Smoler Miller reopened GEODE-5711:
Assignee: Karen Smoler Miller
Re-opening this ticket, as there is a documentation task that still needs to be
completed before the ticket is ready to resolve.
> create jndi-binding gfsh command does not hide password
> ---
>
> Key: GEODE-5711
> URL: https://issues.apache.org/jira/browse/GEODE-5711
> Project: Geode
> Issue Type: Bug
> Components: docs, gfsh
>Reporter: Swapnil Bawaskar
>Assignee: Karen Smoler Miller
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.8.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The {{create jndi-binding}} gfsh command currently accepts {{--username-}}
> and {{-password}} options, but the content text of these options is visible.
> In oder to hide the content, we should model this behavior after gfsh
> {{connect}} command. When the user does not enter {{–username}} then the user
> should be prompted for a username and password. If they enter a --username
> then they should be only prompted for a password.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-5861) JDBC Connector should use gfsh jndi-binding instead of jdbc-connection
Jianxia Chen created GEODE-5861:
---
Summary: JDBC Connector should use gfsh jndi-binding instead of
jdbc-connection
Key: GEODE-5861
URL: https://issues.apache.org/jira/browse/GEODE-5861
Project: Geode
Issue Type: Improvement
Components: extensions
Reporter: Jianxia Chen
Fix For: 1.8.0
In Geode there are two {{gfsh}} commands {{create jndi-binding}} and {{create
jdbc-connection}} which try to accomplish the same goal. We should:
* Change JDBC Connector to use the JNDI binding, instead of the JDBC Connection
* Remove the {{create jdbc-connection}} command.
* Remove the {{destroy jdbc-connection}} command
* Remove the {{list jdbc-connection}} command.
* Remove the {{describe jdbc-connection}} command
* Remove the {{alter jdbc-connnection}} command
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5826) java.lang.OutOfMemoryError: Java heap space when running DUnit tests using java10
[ https://issues.apache.org/jira/browse/GEODE-5826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16648271#comment-16648271 ] Owen Nichols commented on GEODE-5826: - I think we are no longer seeing this in recent builds e.g. https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTestOpenJDK11/builds/12 > java.lang.OutOfMemoryError: Java heap space when running DUnit tests using > java10 > - > > Key: GEODE-5826 > URL: https://issues.apache.org/jira/browse/GEODE-5826 > Project: Geode > Issue Type: Sub-task >Reporter: Jinmei Liao >Priority: Major > > The OOME errors seem to happen after executing these tests: > org.apache.geode.internal.cache.wan.offheap.SerialGatewaySenderQueueOffHeapDUnitTest > > testCreateMaximumSenders > testCreateMaximumPlusOneSenders -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-5848) conditionally add --add-opens to test.gradle if testing on Java 11
[
https://issues.apache.org/jira/browse/GEODE-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols resolved GEODE-5848.
-
Resolution: Fixed
> conditionally add --add-opens to test.gradle if testing on Java 11
> --
>
> Key: GEODE-5848
> URL: https://issues.apache.org/jira/browse/GEODE-5848
> Project: Geode
> Issue Type: Sub-task
> Components: ci
>Reporter: Owen Nichols
>Priority: Major
> Labels: pull-request-available
> Time Spent: 40m
> Remaining Estimate: 0h
>
> While we continue to discuss possible ways to make this unnecessary, for now
> this is the shortest path to getting the Java 11 jobs in the pipeline green.
> Need to add the following around line 225 of grade/test.gradle:
> {quote}jvmArgs += ["--add-opens", "java.xml/jdk.xml.internal=ALL-UNNAMED"]
> jvmArgs += ["--add-opens", "java.base/jdk.internal.module=ALL-UNNAMED"]
> jvmArgs += ["--add-opens", "java.base/java.lang.module=ALL-UNNAMED"]
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-5862) configureEvictionByObjectSizer fails in AcceptanceTestOpenJDK11
Owen Nichols created GEODE-5862: --- Summary: configureEvictionByObjectSizer fails in AcceptanceTestOpenJDK11 Key: GEODE-5862 URL: https://issues.apache.org/jira/browse/GEODE-5862 Project: Geode Issue Type: Sub-task Reporter: Owen Nichols Example of this failure: [https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/AcceptanceTestOpenJDK11/builds/10] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5862) configureEvictionByObjectSizer fails in AcceptanceTestOpenJDK11
[ https://issues.apache.org/jira/browse/GEODE-5862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16648305#comment-16648305 ] Owen Nichols commented on GEODE-5862: - this is a duplicate of GEODE-5860 > configureEvictionByObjectSizer fails in AcceptanceTestOpenJDK11 > --- > > Key: GEODE-5862 > URL: https://issues.apache.org/jira/browse/GEODE-5862 > Project: Geode > Issue Type: Sub-task >Reporter: Owen Nichols >Priority: Major > > Example of this failure: > [https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/AcceptanceTestOpenJDK11/builds/10] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5851) update dockerized gradle plugin to version supporting both Java 8 and 11
[ https://issues.apache.org/jira/browse/GEODE-5851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16648309#comment-16648309 ] ASF subversion and git services commented on GEODE-5851: Commit 4e8ea1c5fabfa8d18d2d113e5aba5ccb06b5562d in geode's branch refs/heads/develop from [~onichols-pivotal] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=4e8ea1c ] GEODE-5851 use gradle-dockerized-test-plugin compiled with Java 8 that supports Java 11 > update dockerized gradle plugin to version supporting both Java 8 and 11 > > > Key: GEODE-5851 > URL: https://issues.apache.org/jira/browse/GEODE-5851 > Project: Geode > Issue Type: Sub-task > Components: ci >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-5851) update dockerized gradle plugin to version supporting both Java 8 and 11
[ https://issues.apache.org/jira/browse/GEODE-5851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols resolved GEODE-5851. - Resolution: Fixed fixed by [https://github.com/apache/geode/pull/2592] > update dockerized gradle plugin to version supporting both Java 8 and 11 > > > Key: GEODE-5851 > URL: https://issues.apache.org/jira/browse/GEODE-5851 > Project: Geode > Issue Type: Sub-task > Components: ci >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5863) CqDataDUnitTest.testMultipleExecuteWithInitialResults ignores assertion failures
[
https://issues.apache.org/jira/browse/GEODE-5863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith updated GEODE-5863:
-
Labels: swat (was: )
> CqDataDUnitTest.testMultipleExecuteWithInitialResults ignores assertion
> failures
>
>
> Key: GEODE-5863
> URL: https://issues.apache.org/jira/browse/GEODE-5863
> Project: Geode
> Issue Type: Improvement
>Reporter: Dan Smith
>Priority: Major
> Labels: swat
>
> This test has assertions in an asynchronous thread. However, it never
> actually checks the results from that thread, it just asserts that the thread
> finishes. In practice, processCqs always throws an Awaitility exception,
> which is ignored and the test passes.
> This is the problematic code. ThreadUtils.join does not check the result of
> the async invocation:
> {code}
> ThreadUtils.join(processCqs, 60 * 1000);
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-5863) CqDataDUnitTest.testMultipleExecuteWithInitialResults ignores assertion failures
Dan Smith created GEODE-5863:
Summary: CqDataDUnitTest.testMultipleExecuteWithInitialResults
ignores assertion failures
Key: GEODE-5863
URL: https://issues.apache.org/jira/browse/GEODE-5863
Project: Geode
Issue Type: Improvement
Reporter: Dan Smith
This test has assertions in an asynchronous thread. However, it never actually
checks the results from that thread, it just asserts that the thread finishes.
In practice, processCqs always throws an Awaitility exception, which is ignored
and the test passes.
This is the problematic code. ThreadUtils.join does not check the result of the
async invocation:
{code}
ThreadUtils.join(processCqs, 60 * 1000);
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5228) ServerLauncherRemoteFileIntegrationTest fails intermittently with IllegalStateException vf.gf.server.status is blank
[
https://issues.apache.org/jira/browse/GEODE-5228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16648382#comment-16648382
]
Dan Smith commented on GEODE-5228:
--
I changed the pollDelay for the await() calls in this test to zero as part of
GEODE-5424, which seems to make this failure more likely.
It looks like this is a race in the status() method - it can read an empty file
before it is written. If that happens, it fails with this error instead of
retrying in the await().
> ServerLauncherRemoteFileIntegrationTest fails intermittently with
> IllegalStateException vf.gf.server.status is blank
>
>
> Key: GEODE-5228
> URL: https://issues.apache.org/jira/browse/GEODE-5228
> Project: Geode
> Issue Type: Bug
> Components: management, tests
>Reporter: Kirk Lund
>Priority: Minor
> Labels: ServerLauncher, ci, flaky, swat
>
> {noformat}
> java.lang.IllegalStateException: Status file
> '/tmp/build/ae3c03f4/built-geode/tmp/junit5775773082469887234/vf.gf.server.status'
> is blank
> at
> org.apache.geode.internal.process.FileProcessController.status(FileProcessController.java:152)
> at
> org.apache.geode.internal.process.FileProcessController.status(FileProcessController.java:89)
> at
> org.apache.geode.distributed.ServerLauncher.statusWithWorkingDirectory(ServerLauncher.java:1102)
> at
> org.apache.geode.distributed.ServerLauncher.status(ServerLauncher.java:1050)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.lambda$awaitStart$1(ServerLauncherRemoteIntegrationTestCase.java:198)
> at
> org.awaitility.core.AssertionCondition$1.eval(AssertionCondition.java:55)
> at
> org.awaitility.core.ConditionAwaiter$ConditionPoller.run(ConditionAwaiter.java:215)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-5864) Streamline and parameterize concourse environment
Sean Goller created GEODE-5864: -- Summary: Streamline and parameterize concourse environment Key: GEODE-5864 URL: https://issues.apache.org/jira/browse/GEODE-5864 Project: Geode Issue Type: Improvement Components: ci Reporter: Sean Goller In order to simplify stamping out multiple CI environments such as for developer use, parameterize infrastructure-specific variables and remove unnecessary vault usage. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-5865) CI Failure: ClientServerJTAFailoverDistributedTest.jtaCanFailoverWithRollbackAfterDoneBeforeCompletion
Helena Bales created GEODE-5865:
---
Summary: CI Failure:
ClientServerJTAFailoverDistributedTest.jtaCanFailoverWithRollbackAfterDoneBeforeCompletion
Key: GEODE-5865
URL: https://issues.apache.org/jira/browse/GEODE-5865
Project: Geode
Issue Type: Bug
Reporter: Helena Bales
Failed on CI:
https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTestOpenJDK8/builds/13
With Stack Trace:
{code}
org.apache.geode.internal.jta.ClientServerJTAFailoverDistributedTest >
jtaCanFailoverWithRollbackAfterDoneBeforeCompletion FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.internal.jta.ClientServerJTAFailoverDistributedTest$$Lambda$30/2023750391.run
in VM 3 running on Host 4e78b9219055 with 4 VMs
at org.apache.geode.test.dunit.VM.invoke(VM.java:433)
at org.apache.geode.test.dunit.VM.invoke(VM.java:402)
at org.apache.geode.test.dunit.VM.invoke(VM.java:361)
at
org.apache.geode.internal.jta.ClientServerJTAFailoverDistributedTest.jtaCanFailoverWithRollbackAfterDoneBeforeCompletion(ClientServerJTAFailoverDistributedTest.java:268)
Caused by:
org.apache.geode.cache.TransactionDataNodeHasDepartedException: no
return value received, caused by
org.apache.geode.internal.cache.ForceReattemptException: no return value
received
Caused by:
org.apache.geode.internal.cache.ForceReattemptException: no return
value received
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5865) CI Failure: ClientServerJTAFailoverDistributedTest.jtaCanFailoverWithRollbackAfterDoneBeforeCompletion
[
https://issues.apache.org/jira/browse/GEODE-5865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Helena Bales updated GEODE-5865:
Labels: swat (was: )
> CI Failure:
> ClientServerJTAFailoverDistributedTest.jtaCanFailoverWithRollbackAfterDoneBeforeCompletion
> --
>
> Key: GEODE-5865
> URL: https://issues.apache.org/jira/browse/GEODE-5865
> Project: Geode
> Issue Type: Bug
>Reporter: Helena Bales
>Priority: Major
> Labels: swat
>
> Failed on CI:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTestOpenJDK8/builds/13
> With Stack Trace:
> {code}
> org.apache.geode.internal.jta.ClientServerJTAFailoverDistributedTest >
> jtaCanFailoverWithRollbackAfterDoneBeforeCompletion FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.jta.ClientServerJTAFailoverDistributedTest$$Lambda$30/2023750391.run
> in VM 3 running on Host 4e78b9219055 with 4 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:433)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:402)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:361)
> at
> org.apache.geode.internal.jta.ClientServerJTAFailoverDistributedTest.jtaCanFailoverWithRollbackAfterDoneBeforeCompletion(ClientServerJTAFailoverDistributedTest.java:268)
> Caused by:
> org.apache.geode.cache.TransactionDataNodeHasDepartedException: no
> return value received, caused by
> org.apache.geode.internal.cache.ForceReattemptException: no return value
> received
> Caused by:
> org.apache.geode.internal.cache.ForceReattemptException: no
> return value received
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5821) Authentication tests fail with client version 1.4: sun.misc.ObjectInputFilter is not available
[
https://issues.apache.org/jira/browse/GEODE-5821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg resolved GEODE-5821.
-
Resolution: Fixed
> Authentication tests fail with client version 1.4: sun.misc.ObjectInputFilter
> is not available
> --
>
> Key: GEODE-5821
> URL: https://issues.apache.org/jira/browse/GEODE-5821
> Project: Geode
> Issue Type: Sub-task
>Reporter: Jinmei Liao
>Assignee: Jinmei Liao
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1h
> Remaining Estimate: 0h
>
> ClientAuthDUnitTest. authWithCorrectPasswordShouldPass[140]
> ClientAuthDUnitTest. authWithIncorrectPasswordWithSubscriptionEnabled[140]
> ClientAuthDUnitTest. authWithIncorrectPasswordWithSubscriptionNotEnabled[140]
> ClientAuthenticationDUnitTest. testCredentialsForNotifications[140]
> ClientAuthenticationDUnitTest. testCredentialsWithFailover[140]
> ClientAuthenticationDUnitTest. testInvalidAuthInit[140]
> ClientAuthenticationDUnitTest. testInvalidCredentials[140]
> ClientAuthenticationDUnitTest. testNoAuthInitWithCredentials[140]
> ClientAuthenticationDUnitTest. testNoAuthenticatorWithCredentials[140]
> ClientAuthenticationDUnitTest. testNoCredentials[140]
> ClientAuthenticationDUnitTest. testValidCredentials[140]
> ClientAuthenticationPart2DUnitTest. testInvalidAuthInitForMultipleUsers[6]
> ClientAuthenticationPart2DUnitTest. testInvalidCredentialsForMultipleUsers[6]
> ClientAuthenticationPart2DUnitTest.
> testNoAuthInitWithCredentialsForMultipleUsers[6]
> ClientAuthenticationPart2DUnitTest.
> testNoAuthenticatorWithCredentialsForMultipleUsers[6]
> ClientAuthenticationPart2DUnitTest.
> testNoCredentialsForMultipleUsersCantRegisterMetadata[6]
> ClientAuthenticationPart2DUnitTest. testNoCredentialsForMultipleUsers[6]
> ClientAuthorizationLegacyConfigurationDUnitTest.
> everythingFailsWithInvalidAccessor[clientVersion=140]
> ClientAuthorizationLegacyConfigurationDUnitTest.
> everythingFailsWithInvalidAuthenticator[clientVersion=140]
> ClientDataAuthorizationUsingLegacySecurityDUnitTest.
> dataReadCannotPut[clientVersion=140]
> ClientDataAuthorizationUsingLegacySecurityDUnitTest.
> dataReadClientCanGet[clientVersion=140]
> ClientDataAuthorizationUsingLegacySecurityDUnitTest.
> dataWriteCannotGet[clientVersion=140]
> ClientDataAuthorizationUsingLegacySecurityDUnitTest.
> dataWriteClientCanPut[clientVersion=140]
> ClientDataAuthorizationUsingLegacySecurityWithFailoverDUnitTest.
> dataReaderCanRegisterAndUnregisterAcrossFailover[clientVersion=140]
> ClientDataAuthorizationUsingLegacySecurityWithFailoverDUnitTest.
> dataReaderCanStillOnlyReadAfterFailover[clientVersion=140]
> ClientDataAuthorizationUsingLegacySecurityWithFailoverDUnitTest.
> dataWriterCanStillOnlyWriteAfterFailover[clientVersion=140]
> ClientDataAuthorizationUsingLegacySecurityWithFailoverDUnitTest.
> dataWriterCannotRegisterInterestAcrossFailover[clientVersion=140]
> ClusterStartupRuleCanSpecifyOlderVersionsDUnitTest.
> clientVersioningTest[version=140]
> ClusterStartupRuleCanSpecifyOlderVersionsDUnitTest.
> locatorVersioningTest[version=140]
> ClusterStartupRuleCanSpecifyOlderVersionsDUnitTest.
> serverVersioningTest[version=140]
> ClusterStartupRuleCanSpecifyOlderVersionsDUnitTest.
> serverWithEmbeddedLocatorVersioningTest[version=140]
>
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.security.ClientAuthenticationTestCase$$Lambda$160/1869841081.run
> in VM 2 running on Host 08cf4958ddd8 with 4 VMs with version 140
> at org.apache.geode.test.dunit.VM.invoke(VM.java:450)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:419)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:362)
> at
> org.apache.geode.security.ClientAuthenticationTestCase.createClient1NoException(ClientAuthenticationTestCase.java:710)
> at
> org.apache.geode.security.ClientAuthenticationTestCase.doTestCredentialsForNotifications(ClientAuthenticationTestCase.java:580)
> at
> org.apache.geode.security.ClientAuthenticationDUnitTest.testCredentialsForNotifications(ClientAuthenticationDUnitTest.java:99)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
>
[jira] [Updated] (GEODE-5857) Race conditions during JMX registration and cleanup
[ https://issues.apache.org/jira/browse/GEODE-5857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon updated GEODE-5857: Description: Unregistering an MBean twice results in an InstanceNotFoundException, which gets wrapped in a ManagementException and logged as a warning. This should not be a warning as an InstanceNotFoundException implies the MBean has already been unregistered, and a second unregistration is basically a no-op. The same logic applies to registration of an MBean (was: Unregistering an MBean twice results in an InstanceNotFoundException, which gets wrapped in a ManagementException and logged as a warning. This should not be a warning as an InstanceNotFoundException implies the MBean has already been unregistered, and a second unregistration is basically a no-op.) Summary: Race conditions during JMX registration and cleanup (was: Unregistering MBean twice results in unnecessary warning message) > Race conditions during JMX registration and cleanup > --- > > Key: GEODE-5857 > URL: https://issues.apache.org/jira/browse/GEODE-5857 > Project: Geode > Issue Type: Bug > Components: jmx, management >Reporter: Ryan McMahon >Assignee: Ryan McMahon >Priority: Major > Labels: pull-request-available > Fix For: 1.8.0 > > Time Spent: 40m > Remaining Estimate: 0h > > Unregistering an MBean twice results in an InstanceNotFoundException, which > gets wrapped in a ManagementException and logged as a warning. This should > not be a warning as an InstanceNotFoundException implies the MBean has > already been unregistered, and a second unregistration is basically a no-op. > The same logic applies to registration of an MBean -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-5871) TransactionUtils should be replaced by a static Logger
Jianxia Chen created GEODE-5871: --- Summary: TransactionUtils should be replaced by a static Logger Key: GEODE-5871 URL: https://issues.apache.org/jira/browse/GEODE-5871 Project: Geode Issue Type: Improvement Components: logging Reporter: Jianxia Chen TransactionUtils existed back when loggers only existed when the distributed system was connected. Now that each class can have its own static logger that will exist for the lifetime of that class, TransactionUtils can be removed and any code that uses it can use a static logger created by calling LogService.getLogger()�. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5871) TransactionUtils should be replaced by a static Logger
[ https://issues.apache.org/jira/browse/GEODE-5871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jianxia Chen updated GEODE-5871: Description: TransactionUtils existed back when loggers only existed when the distributed system was connected. Now that each class can have its own static logger that will exist for the lifetime of that class, TransactionUtils can be removed and any code that uses it can use a static logger created by calling LogService.getLogger(). (was: TransactionUtils existed back when loggers only existed when the distributed system was connected. Now that each class can have its own static logger that will exist for the lifetime of that class, TransactionUtils can be removed and any code that uses it can use a static logger created by calling LogService.getLogger()�.) > TransactionUtils should be replaced by a static Logger > -- > > Key: GEODE-5871 > URL: https://issues.apache.org/jira/browse/GEODE-5871 > Project: Geode > Issue Type: Improvement > Components: logging >Reporter: Jianxia Chen >Priority: Major > > TransactionUtils existed back when loggers only existed when the distributed > system was connected. Now that each class can have its own static logger that > will exist for the lifetime of that class, TransactionUtils can be removed > and any code that uses it can use a static logger created by calling > LogService.getLogger(). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5871) TransactionUtils should be replaced by a static Logger
[ https://issues.apache.org/jira/browse/GEODE-5871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jianxia Chen updated GEODE-5871: Priority: Minor (was: Major) > TransactionUtils should be replaced by a static Logger > -- > > Key: GEODE-5871 > URL: https://issues.apache.org/jira/browse/GEODE-5871 > Project: Geode > Issue Type: Improvement > Components: logging >Reporter: Jianxia Chen >Priority: Minor > > TransactionUtils existed back when loggers only existed when the distributed > system was connected. Now that each class can have its own static logger that > will exist for the lifetime of that class, TransactionUtils can be removed > and any code that uses it can use a static logger created by calling > LogService.getLogger(). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5871) TransactionUtils should be replaced by a static Logger
[ https://issues.apache.org/jira/browse/GEODE-5871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jianxia Chen updated GEODE-5871: Priority: Trivial (was: Minor) > TransactionUtils should be replaced by a static Logger > -- > > Key: GEODE-5871 > URL: https://issues.apache.org/jira/browse/GEODE-5871 > Project: Geode > Issue Type: Improvement > Components: logging >Reporter: Jianxia Chen >Priority: Trivial > > TransactionUtils existed back when loggers only existed when the distributed > system was connected. Now that each class can have its own static logger that > will exist for the lifetime of that class, TransactionUtils can be removed > and any code that uses it can use a static logger created by calling > LogService.getLogger(). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-5872) Tests in PersistentColocatedPartitionedRegionDUnitTest are ignoring assertions
[ https://issues.apache.org/jira/browse/GEODE-5872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith reassigned GEODE-5872: Assignee: Dan Smith > Tests in PersistentColocatedPartitionedRegionDUnitTest are ignoring assertions > -- > > Key: GEODE-5872 > URL: https://issues.apache.org/jira/browse/GEODE-5872 > Project: Geode > Issue Type: Improvement >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Labels: swat > > There are several tests in PersistentColocatedPartitionedRegionDUnitTest that > are have returns inside finally blocks. The effect of this is that the tests > are actually ignoring any assertion failures. > In practice, these tests fail with Awailility timeouts all the time. With my > changes for GEODE-5424, the tests now timeout because I increased the > awailitity timeout. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-5872) Tests in PersistentColocatedPartitionedRegionDUnitTest are ignoring assertions
Dan Smith created GEODE-5872: Summary: Tests in PersistentColocatedPartitionedRegionDUnitTest are ignoring assertions Key: GEODE-5872 URL: https://issues.apache.org/jira/browse/GEODE-5872 Project: Geode Issue Type: Improvement Reporter: Dan Smith There are several tests in PersistentColocatedPartitionedRegionDUnitTest that are have returns inside finally blocks. The effect of this is that the tests are actually ignoring any assertion failures. In practice, these tests fail with Awailility timeouts all the time. With my changes for GEODE-5424, the tests now timeout because I increased the awailitity timeout. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5872) Tests in PersistentColocatedPartitionedRegionDUnitTest are ignoring assertions
[ https://issues.apache.org/jira/browse/GEODE-5872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith updated GEODE-5872: - Labels: swat (was: ) > Tests in PersistentColocatedPartitionedRegionDUnitTest are ignoring assertions > -- > > Key: GEODE-5872 > URL: https://issues.apache.org/jira/browse/GEODE-5872 > Project: Geode > Issue Type: Improvement >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Labels: swat > > There are several tests in PersistentColocatedPartitionedRegionDUnitTest that > are have returns inside finally blocks. The effect of this is that the tests > are actually ignoring any assertion failures. > In practice, these tests fail with Awailility timeouts all the time. With my > changes for GEODE-5424, the tests now timeout because I increased the > awailitity timeout. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5872) Tests in PersistentColocatedPartitionedRegionDUnitTest are ignoring assertions
[
https://issues.apache.org/jira/browse/GEODE-5872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16648587#comment-16648587
]
Dan Smith commented on GEODE-5872:
--
These are the tests that fail with GEODE-5424
{noformat}
org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDUnitTest
> testMissingColocatedChildPRDueToDelayedStart FAILED
java.util.concurrent.TimeoutException: Timed out waiting 6 milliseconds
for AsyncInvocation to complete.
at
org.apache.geode.test.dunit.AsyncInvocation.timeoutIfAlive(AsyncInvocation.java:462)
at
org.apache.geode.test.dunit.AsyncInvocation.get(AsyncInvocation.java:412)
at
org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDUnitTest.testMissingColocatedChildPRDueToDelayedStart(PersistentColocatedPartitionedRegionDUnitTest.java:867)
org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDUnitTest
> testHierarchyOfColocatedChildPRsMissing FAILED
java.util.concurrent.TimeoutException: Timed out waiting 6 milliseconds
for AsyncInvocation to complete.
at
org.apache.geode.test.dunit.AsyncInvocation.timeoutIfAlive(AsyncInvocation.java:462)
at
org.apache.geode.test.dunit.AsyncInvocation.get(AsyncInvocation.java:412)
at
org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDUnitTest.testHierarchyOfColocatedChildPRsMissing(PersistentColocatedPartitionedRegionDUnitTest.java:1078)
org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDUnitTest
> testMissingColocatedChildPR FAILED
java.util.concurrent.TimeoutException: Timed out waiting 6 milliseconds
for AsyncInvocation to complete.
at
org.apache.geode.test.dunit.AsyncInvocation.timeoutIfAlive(AsyncInvocation.java:462)
at
org.apache.geode.test.dunit.AsyncInvocation.get(AsyncInvocation.java:412)
at
org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDUnitTest.testMissingColocatedChildPR(PersistentColocatedPartitionedRegionDUnitTest.java:912)
org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDUnitTest
> testHierarchyOfColocatedChildPRsMissingGrandchild FAILED
java.util.concurrent.TimeoutException: Timed out waiting 6 milliseconds
for AsyncInvocation to complete.
at
org.apache.geode.test.dunit.AsyncInvocation.timeoutIfAlive(AsyncInvocation.java:462)
at
org.apache.geode.test.dunit.AsyncInvocation.get(AsyncInvocation.java:412)
at
org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDUnitTest.testHierarchyOfColocatedChildPRsMissingGrandchild(PersistentColocatedPartitionedRegionDUnitTest.java:1137)
org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDUnitTest
> testMultipleColocatedChildPRsMissingWithSequencedStart FAILED
java.util.concurrent.TimeoutException: Timed out waiting 6 milliseconds
for AsyncInvocation to complete.
at
org.apache.geode.test.dunit.AsyncInvocation.timeoutIfAlive(AsyncInvocation.java:462)
at
org.apache.geode.test.dunit.AsyncInvocation.get(AsyncInvocation.java:412)
at
org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDUnitTest.testMultipleColocatedChildPRsMissingWithSequencedStart(PersistentColocatedPartitionedRegionDUnitTest.java:1023)
{noformat}
> Tests in PersistentColocatedPartitionedRegionDUnitTest are ignoring assertions
> --
>
> Key: GEODE-5872
> URL: https://issues.apache.org/jira/browse/GEODE-5872
> Project: Geode
> Issue Type: Improvement
>Reporter: Dan Smith
>Assignee: Dan Smith
>Priority: Major
> Labels: swat
>
> There are several tests in PersistentColocatedPartitionedRegionDUnitTest that
> are have returns inside finally blocks. The effect of this is that the tests
> are actually ignoring any assertion failures.
> In practice, these tests fail with Awailility timeouts all the time. With my
> changes for GEODE-5424, the tests now timeout because I increased the
> awailitity timeout.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5873) Some DUnitTest calls VMProvider.invokeInEveryMember without member arguments
[
https://issues.apache.org/jira/browse/GEODE-5873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jianxia Chen updated GEODE-5873:
Priority: Trivial (was: Major)
> Some DUnitTest calls VMProvider.invokeInEveryMember without member arguments
> -
>
> Key: GEODE-5873
> URL: https://issues.apache.org/jira/browse/GEODE-5873
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Jianxia Chen
>Priority: Trivial
> Labels: beginner
> Fix For: 1.8.0
>
>
> In some of the DUnitTest, when it calls {{VMProvider.invokeInEveryMember}}
> without providing the member argument. And the result is an no-op, because
> there is no member to execute the {{SerializableRunnableIF}}. e.g. in
> {{CreateJndiBindingCommandDUnitTest}} and
> {{DestroyJndiBindingCommandDUnitTest}}, {{VMProvider.invokeInEveryMember}} is
> called without any member. It probably should be passed {{server1, server2.}}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5873) Some DUnitTest calls VMProvider.invokeInEveryMember without member arguments
[
https://issues.apache.org/jira/browse/GEODE-5873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jianxia Chen updated GEODE-5873:
Labels: beginner (was: )
> Some DUnitTest calls VMProvider.invokeInEveryMember without member arguments
> -
>
> Key: GEODE-5873
> URL: https://issues.apache.org/jira/browse/GEODE-5873
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Jianxia Chen
>Priority: Trivial
> Labels: beginner
> Fix For: 1.8.0
>
>
> In some of the DUnitTest, when it calls {{VMProvider.invokeInEveryMember}}
> without providing the member argument. And the result is an no-op, because
> there is no member to execute the {{SerializableRunnableIF}}. e.g. in
> {{CreateJndiBindingCommandDUnitTest}} and
> {{DestroyJndiBindingCommandDUnitTest}}, {{VMProvider.invokeInEveryMember}} is
> called without any member. It probably should be passed {{server1, server2.}}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-5873) Some DUnitTest calls VMProvider.invokeInEveryMember without member arguments
Jianxia Chen created GEODE-5873:
---
Summary: Some DUnitTest calls VMProvider.invokeInEveryMember
without member arguments
Key: GEODE-5873
URL: https://issues.apache.org/jira/browse/GEODE-5873
Project: Geode
Issue Type: Bug
Components: tests
Reporter: Jianxia Chen
Fix For: 1.8.0
In some of the DUnitTest, when it calls {{VMProvider.invokeInEveryMember}}
without providing the member argument. And the result is an no-op, because
there is no member to execute the {{SerializableRunnableIF}}. e.g. in
{{CreateJndiBindingCommandDUnitTest}} and
{{DestroyJndiBindingCommandDUnitTest}}, {{VMProvider.invokeInEveryMember}} is
called without any member. It probably should be passed {{server1, server2.}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5874) Query test data classes cause tests to depend on run order
[
https://issues.apache.org/jira/browse/GEODE-5874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery updated GEODE-5874:
--
Labels: swat (was: )
> Query test data classes cause tests to depend on run order
> --
>
> Key: GEODE-5874
> URL: https://issues.apache.org/jira/browse/GEODE-5874
> Project: Geode
> Issue Type: Test
> Components: tests
>Reporter: Dale Emery
>Priority: Major
> Labels: swat
>
> The {{org.apache.geode.cache.query.data.Position}} class uses a static
> counter to supply unique identifiers to distinguish instances. One of the
> class’s constructors increments the counter each time it is invoked.
> Because the counter is declared {{static}}, its value persists from one test
> method to the next. This causes some tests to depend on being run in a
> specific order. It also causes some tests fail when run multiple times, such
> as when run as part the stress test job triggered by pull request pre-checkin.
> Other data classes in the {{org.apache.geode.cache.query.data}} amplify the
> problem by relying on {{Position}}'s static counter. For example, the
> {{Portfolio}} class in the same package uses {{Position}}’s static counter to
> select which data to construct.
> Given that some tests depend on the {{Portfolio}} constructor’s choice of
> data, this makes many uses of {{Portfolio}} dependent on the order in which
> tests are run.
> For example: {{QueryJUnitTest.test008NullCollectionField()}} failed 38 out of
> 50 times in a recent stress test, because on many runs, {{Portfolio}} created
> an unexpected set of data:
> http://files.apachegeode-ci.info/builds/geode-pr-2601/test-results/repeatTest/1539309680/
> Though {{QueryJunitTest}} has been fixed to prevent this problem, other tests
> remain susceptible to the problem, and will fail the next time they are run
> repeatedly.
> I recommend implementing a better means to create {{Position}} instances with
> unique identifiers, without making tests dependent on the order in which they
> are run.
>
> A Builder might be an appropriate pattern to use. Or something simpler:
> Changing the {{Position}} constructor to take a unique identifier as a
> parameter, as the {{Portfolio}} constructor does.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-5874) Query test data classes cause tests to depend on run order
Dale Emery created GEODE-5874:
-
Summary: Query test data classes cause tests to depend on run order
Key: GEODE-5874
URL: https://issues.apache.org/jira/browse/GEODE-5874
Project: Geode
Issue Type: Test
Components: tests
Reporter: Dale Emery
The {{org.apache.geode.cache.query.data.Position}} class uses a static counter
to supply unique identifiers to distinguish instances. One of the class’s
constructors increments the counter each time it is invoked.
Because the counter is declared {{static}}, its value persists from one test
method to the next. This causes some tests to depend on being run in a specific
order. It also causes some tests fail when run multiple times, such as when run
as part the stress test job triggered by pull request pre-checkin.
Other data classes in the {{org.apache.geode.cache.query.data}} amplify the
problem by relying on {{Position}}'s static counter. For example, the
{{Portfolio}} class in the same package uses {{Position}}’s static counter to
select which data to construct.
Given that some tests depend on the {{Portfolio}} constructor’s choice of data,
this makes many uses of {{Portfolio}} dependent on the order in which tests are
run.
For example: {{QueryJUnitTest.test008NullCollectionField()}} failed 38 out of
50 times in a recent stress test, because on many runs, {{Portfolio}} created
an unexpected set of data:
http://files.apachegeode-ci.info/builds/geode-pr-2601/test-results/repeatTest/1539309680/
Though {{QueryJunitTest}} has been fixed to prevent this problem, other tests
remain susceptible to the problem, and will fail the next time they are run
repeatedly.
I recommend implementing a better means to create {{Position}} instances with
unique identifiers, without making tests dependent on the order in which they
are run.
A Builder might be an appropriate pattern to use. Or something simpler:
Changing the {{Position}} constructor to take a unique identifier as a
parameter, as the {{Portfolio}} constructor does.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5874) Query test data classes cause tests to depend on run order
[
https://issues.apache.org/jira/browse/GEODE-5874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery updated GEODE-5874:
--
Description:
The {{org.apache.geode.cache.query.data.Position}} class uses a static counter
to supply unique identifiers to distinguish instances. One of the class’s
constructors increments the counter each time it is invoked.
Because the counter is declared {{static}}, its value persists from one test
method to the next. This causes some tests to depend on being run in a specific
order. It also causes some tests fail when run multiple times, such as when run
as part the stress test job triggered by pull request pre-checkin.
Other data classes in the {{org.apache.geode.cache.query.data}} package amplify
the problem by relying on {{Position}}'s static counter. For example, the
{{Portfolio}} class in the same package uses {{Position}}’s static counter to
select which data to construct.
Given that some tests depend on the {{Portfolio}} constructor’s choice of data,
this makes many uses of {{Portfolio}} dependent on the order in which tests are
run.
For example: {{QueryJUnitTest.test008NullCollectionField()}} failed 38 out of
50 times in a recent stress test, because on many runs, {{Portfolio}} created
an unexpected set of data:
http://files.apachegeode-ci.info/builds/geode-pr-2601/test-results/repeatTest/1539309680/
Though {{QueryJunitTest}} has been fixed to prevent this problem, other tests
remain susceptible to the problem, and will fail the next time they are run
repeatedly.
I recommend implementing a better means to create {{Position}} instances with
unique identifiers, without making tests dependent on the order in which they
are run.
A Builder might be an appropriate pattern to use. Or something simpler:
Changing the {{Position}} constructor to take a unique identifier as a
parameter, as the {{Portfolio}} constructor does.
was:
The {{org.apache.geode.cache.query.data.Position}} class uses a static counter
to supply unique identifiers to distinguish instances. One of the class’s
constructors increments the counter each time it is invoked.
Because the counter is declared {{static}}, its value persists from one test
method to the next. This causes some tests to depend on being run in a specific
order. It also causes some tests fail when run multiple times, such as when run
as part the stress test job triggered by pull request pre-checkin.
Other data classes in the {{org.apache.geode.cache.query.data}} amplify the
problem by relying on {{Position}}'s static counter. For example, the
{{Portfolio}} class in the same package uses {{Position}}’s static counter to
select which data to construct.
Given that some tests depend on the {{Portfolio}} constructor’s choice of data,
this makes many uses of {{Portfolio}} dependent on the order in which tests are
run.
For example: {{QueryJUnitTest.test008NullCollectionField()}} failed 38 out of
50 times in a recent stress test, because on many runs, {{Portfolio}} created
an unexpected set of data:
http://files.apachegeode-ci.info/builds/geode-pr-2601/test-results/repeatTest/1539309680/
Though {{QueryJunitTest}} has been fixed to prevent this problem, other tests
remain susceptible to the problem, and will fail the next time they are run
repeatedly.
I recommend implementing a better means to create {{Position}} instances with
unique identifiers, without making tests dependent on the order in which they
are run.
A Builder might be an appropriate pattern to use. Or something simpler:
Changing the {{Position}} constructor to take a unique identifier as a
parameter, as the {{Portfolio}} constructor does.
> Query test data classes cause tests to depend on run order
> --
>
> Key: GEODE-5874
> URL: https://issues.apache.org/jira/browse/GEODE-5874
> Project: Geode
> Issue Type: Test
> Components: tests
>Reporter: Dale Emery
>Priority: Major
> Labels: swat
>
> The {{org.apache.geode.cache.query.data.Position}} class uses a static
> counter to supply unique identifiers to distinguish instances. One of the
> class’s constructors increments the counter each time it is invoked.
> Because the counter is declared {{static}}, its value persists from one test
> method to the next. This causes some tests to depend on being run in a
> specific order. It also causes some tests fail when run multiple times, such
> as when run as part the stress test job triggered by pull request pre-checkin.
> Other data classes in the {{org.apache.geode.cache.query.data}} package
> amplify the problem by relying on {{Position}}'s static counter. For example,
> the {{Portfolio}} class in the same package uses {{Position}}’s static
> counter to select which data to construct.
> Given that some tests d
[jira] [Updated] (GEODE-5874) Query test data classes cause tests to depend on run order
[
https://issues.apache.org/jira/browse/GEODE-5874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery updated GEODE-5874:
--
Description:
The {{org.apache.geode.cache.query.data.Position}} class uses a static counter
to supply unique identifiers to distinguish instances. One of the class’s
constructors increments the counter each time it is invoked.
Because the counter is declared {{static}}, its value persists from one test
method to the next. This causes some tests to depend on being run in a specific
order. It also causes some tests fail when run multiple times, such as when run
as part the stress test job triggered by pull request pre-checkin.
Other data classes in the {{org.apache.geode.cache.query.data}} package amplify
the problem by relying on {{Position}}'s static counter. For example, the
{{Portfolio}} class in the same package uses {{Position}}’s static counter to
select which data to construct.
Given that some tests depend on the {{Portfolio}} constructor’s choice of data,
this makes many uses of {{Portfolio}} dependent on the order in which tests are
run.
For example: {{QueryJUnitTest.test008NullCollectionField()}} failed 38 out of
50 times in a recent stress test, because on many runs, {{Portfolio}} created
an unexpected set of data:
http://files.apachegeode-ci.info/builds/geode-pr-2601/test-results/repeatTest/1539309680/
Though {{QueryJunitTest}} has been fixed to prevent this problem, other tests
remain susceptible to the problem, and will fail the next time they are run
repeatedly.
I recommend implementing a better means to create {{Position}} instances with
unique identifiers, without making tests depend on the order in which they are
run.
A Builder might be an appropriate pattern to use. Or something simpler:
Changing the {{Position}} constructor to take a unique identifier as a
parameter, as the {{Portfolio}} constructor does.
was:
The {{org.apache.geode.cache.query.data.Position}} class uses a static counter
to supply unique identifiers to distinguish instances. One of the class’s
constructors increments the counter each time it is invoked.
Because the counter is declared {{static}}, its value persists from one test
method to the next. This causes some tests to depend on being run in a specific
order. It also causes some tests fail when run multiple times, such as when run
as part the stress test job triggered by pull request pre-checkin.
Other data classes in the {{org.apache.geode.cache.query.data}} package amplify
the problem by relying on {{Position}}'s static counter. For example, the
{{Portfolio}} class in the same package uses {{Position}}’s static counter to
select which data to construct.
Given that some tests depend on the {{Portfolio}} constructor’s choice of data,
this makes many uses of {{Portfolio}} dependent on the order in which tests are
run.
For example: {{QueryJUnitTest.test008NullCollectionField()}} failed 38 out of
50 times in a recent stress test, because on many runs, {{Portfolio}} created
an unexpected set of data:
http://files.apachegeode-ci.info/builds/geode-pr-2601/test-results/repeatTest/1539309680/
Though {{QueryJunitTest}} has been fixed to prevent this problem, other tests
remain susceptible to the problem, and will fail the next time they are run
repeatedly.
I recommend implementing a better means to create {{Position}} instances with
unique identifiers, without making tests dependent on the order in which they
are run.
A Builder might be an appropriate pattern to use. Or something simpler:
Changing the {{Position}} constructor to take a unique identifier as a
parameter, as the {{Portfolio}} constructor does.
> Query test data classes cause tests to depend on run order
> --
>
> Key: GEODE-5874
> URL: https://issues.apache.org/jira/browse/GEODE-5874
> Project: Geode
> Issue Type: Test
> Components: tests
>Reporter: Dale Emery
>Priority: Major
> Labels: swat
>
> The {{org.apache.geode.cache.query.data.Position}} class uses a static
> counter to supply unique identifiers to distinguish instances. One of the
> class’s constructors increments the counter each time it is invoked.
> Because the counter is declared {{static}}, its value persists from one test
> method to the next. This causes some tests to depend on being run in a
> specific order. It also causes some tests fail when run multiple times, such
> as when run as part the stress test job triggered by pull request pre-checkin.
> Other data classes in the {{org.apache.geode.cache.query.data}} package
> amplify the problem by relying on {{Position}}'s static counter. For example,
> the {{Portfolio}} class in the same package uses {{Position}}’s static
> counter to select which data to construct.
> Given that some te
[jira] [Assigned] (GEODE-5875) gfsh destroy jndi-binding command actually removes all data sources
[
https://issues.apache.org/jira/browse/GEODE-5875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jianxia Chen reassigned GEODE-5875:
---
Assignee: Jianxia Chen
> gfsh destroy jndi-binding command actually removes all data sources
> ---
>
> Key: GEODE-5875
> URL: https://issues.apache.org/jira/browse/GEODE-5875
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Jianxia Chen
>Assignee: Jianxia Chen
>Priority: Major
> Fix For: 1.8.0
>
>
> When executing gfsh command {{destroy jndi-binding}}, besides the targeted
> data source, the other data sources will be partially released early.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-5875) gfsh destroy jndi-binding command actually removes all data sources
Jianxia Chen created GEODE-5875:
---
Summary: gfsh destroy jndi-binding command actually removes all
data sources
Key: GEODE-5875
URL: https://issues.apache.org/jira/browse/GEODE-5875
Project: Geode
Issue Type: Bug
Components: gfsh
Reporter: Jianxia Chen
Fix For: 1.8.0
When executing gfsh command {{destroy jndi-binding}}, besides the targeted data
source, the other data sources will be partially released early.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5875) gfsh destroy jndi-binding command actually removes all data sources
[
https://issues.apache.org/jira/browse/GEODE-5875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16648647#comment-16648647
]
ASF subversion and git services commented on GEODE-5875:
Commit 6a53cc1098c925e757af619dcaa3c5f0a25c3bb3 in geode's branch
refs/heads/feature/GEODE-5875 from [~jchen21]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=6a53cc1 ]
GEODE-5875: Add a DUnitTest to reproduce the bug
Co-authored-by: Darrel Schneider
Co-authored-by: Jianxia Chen
> gfsh destroy jndi-binding command actually removes all data sources
> ---
>
> Key: GEODE-5875
> URL: https://issues.apache.org/jira/browse/GEODE-5875
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Jianxia Chen
>Assignee: Jianxia Chen
>Priority: Major
> Fix For: 1.8.0
>
>
> When executing gfsh command {{destroy jndi-binding}}, besides the targeted
> data source, the other data sources will be partially released early.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
