[jira] [Commented] (GEODE-3095) MethodArgumentTypeMismatchException for default values over HTTP
[
https://issues.apache.org/jira/browse/GEODE-3095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16052202#comment-16052202
]
Patrick Rhomberg commented on GEODE-3095:
-
Refer to `GfshCommandsOverHttpSecurityTest`, specifically the invocation of
`create disk-store --name=foo --dir=bar`.
Test will fail with expected error code 510 (unauthorized) producing instead
error code 415 (Could not read command response).
The MethodArgumentTypeMismatchException causes the following response: "Could
not read command response. Error occurred while executing "create disk-store
--name=foo --dir=bar" on manager. Please check manager logs for error."
> MethodArgumentTypeMismatchException for default values over HTTP
>
>
> Key: GEODE-3095
> URL: https://issues.apache.org/jira/browse/GEODE-3095
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Emily Yeh
>
> When running {{GfshCommandsOverHttpSecurityTest.java}}, the following
> exception is getting thrown in {{RestTemplate.doExecute:644}} (the actual
> error is in {{652: response = request.execute();}}). The cause appears to be
> that some default values are getting expanded, which causes them to be parsed
> incorrectly. In particular, the values {{90}} and {{99}} are becoming
> expanded to Strings {{90.0}} and {{99.0}}, which causes problems when these
> Strings are parsed to Integers (even though they were converted to floats
> earlier).
> {noformat}
> Processing unauthorized command: create disk-store --name=foo --dir=bar
> java.lang.RuntimeException: The HTTP request failed with: 500 -
> org.springframework.web.method.annotation.MethodArgumentTypeMismatchException:
> Failed to convert value of type 'java.lang.String' to required type
> 'java.lang.Integer'; nested exception is java.lang.NumberFormatException: For
> input string: "99.0"
> at
> org.springframework.web.method.annotation.AbstractNamedValueMethodArgumentResolver.resolveArgument(AbstractNamedValueMethodArgumentResolver.java:128)
> at
> org.springframework.web.method.support.HandlerMethodArgumentResolverComposite.resolveArgument(HandlerMethodArgumentResolverComposite.java:121)
> at
> org.springframework.web.method.support.InvocableHandlerMethod.getMethodArgumentValues(InvocableHandlerMethod.java:158)
> at
> org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:128)
> at
> org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:116)
> at
> org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandlerMethod(RequestMappingHandlerAdapter.java:827)
> at
> org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:738)
> at
> org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapter.handle(AbstractHandlerMethodAdapter.java:85)
> at
> org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:963)
> at
> org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:897)
> at
> org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:970)
> at
> org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:872)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
> at
> org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:846)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:845)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1689)
> at
> org.springframework.web.filter.HttpPutFormContentFilter.doFilterInternal(HttpPutFormContentFilter.java:105)
> at
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1676)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
>
[jira] [Commented] (GEODE-2969) Meaningful exception information is stripped during exception handling
[
https://issues.apache.org/jira/browse/GEODE-2969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16061209#comment-16061209
]
Patrick Rhomberg commented on GEODE-2969:
-
This regex will catch many potential instances of this issue.
{noformat}
ResultBuilder\.create\w+\(\w+\.getMessage\(\)\);
{noformat}
> Meaningful exception information is stripped during exception handling
> --
>
> Key: GEODE-2969
> URL: https://issues.apache.org/jira/browse/GEODE-2969
> Project: Geode
> Issue Type: Bug
> Components: logging
>Reporter: Patrick Rhomberg
>
> A number of contexts result in a less-than-meaningful message to log or
> console of simply `null`. For instance, running `gfsh status locator` prints
> only `null`.
> This may be the result of exceptions being converted to exceptions of another
> type or to error results, but in the process losing important information by
> only passing `e.getMessage()` to the new type. For instance, the above `gfsh
> status locator` is failing with a `java.lang.NumberFormatException: null`,
> but this exception is converted to `return
> ResultBuilder.createUserErrorResult(e.getMessage());` In this case,
> `e.getMessage()` is `null`, where the more meaningful result is the type of
> exception.
> A fix to this will likely close GEODE-2569
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (GEODE-5125) Document internal use of "cluster" group
Patrick Rhomberg created GEODE-5125: --- Summary: Document internal use of "cluster" group Key: GEODE-5125 URL: https://issues.apache.org/jira/browse/GEODE-5125 Project: Geode Issue Type: Task Reporter: Patrick Rhomberg Internally, we use the implicit member group "cluster" for any configuration elements that apply to every member. While it might seem nonsensical for a user to name a group "cluster" that contains only some and not all of the cluster, this should discouraged in the documentation, as its use will result in unexpected behavior. Primary locations for this note could be: https://geode.apache.org/docs/guide/15/configuring/cluster_config/using_member_groups.html and/or the linked pages at the bottom of that page: https://geode.apache.org/docs/guide/15/topologies_and_comm/p2p_configuration/configuring_peer_member_groups.html https://geode.apache.org/docs/guide/15/topologies_and_comm/cs_configuration/configure_servers_into_logical_groups.html As an aside, the linked pages are inconsistent on the capitalization of "into." -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-5149) CommandManager should enfore SingleGfshCommand having exactly one method annotated with @CliCommand
Patrick Rhomberg created GEODE-5149:
---
Summary: CommandManager should enfore SingleGfshCommand having
exactly one method annotated with @CliCommand
Key: GEODE-5149
URL: https://issues.apache.org/jira/browse/GEODE-5149
Project: Geode
Issue Type: Sub-task
Reporter: Patrick Rhomberg
To avoid accidental misuse, the restriction mentioned in the javadoc of
{{SingleGfshCommand}} should be explicitly enforced.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-5163) Tests extending PulseAcceptanceTestBase are flaky
Patrick Rhomberg created GEODE-5163: --- Summary: Tests extending PulseAcceptanceTestBase are flaky Key: GEODE-5163 URL: https://issues.apache.org/jira/browse/GEODE-5163 Project: Geode Issue Type: Bug Components: pulse Reporter: Patrick Rhomberg See these Concourse runs for more context: https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/UITests/builds/208 org.apache.geode.tools.pulse.ui.PulseAcceptanceAuthTest > testDataViewTreeMapPopUpData https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/UITests/builds/217 org.apache.geode.tools.pulse.ui.PulseAcceptanceAuthTest > testClusterDetailsAndWidgets https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/UITests/builds/231 org.apache.geode.tools.pulse.ui.PulseAcceptanceAuthTest > testClusterDetailsAndWidgets https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/UITests/builds/249 org.apache.geode.tools.pulse.ui.PulseAcceptanceAuthTest > testClusterDetailsAndWidgets https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/UITests/builds/256 org.apache.geode.tools.pulse.ui.PulseAcceptanceAuthTest > testClusterDetailsAndWidgets https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/UITests/builds/258 org.apache.geode.tools.pulse.ui.PulseAcceptanceNoAuthTest > testClusterDetailsAndWidgets -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-5167) Improve robustness of DUnit Testing by decreasing likelihood of port conflicts
Patrick Rhomberg created GEODE-5167:
---
Summary: Improve robustness of DUnit Testing by decreasing
likelihood of port conflicts
Key: GEODE-5167
URL: https://issues.apache.org/jira/browse/GEODE-5167
Project: Geode
Issue Type: Bug
Reporter: Patrick Rhomberg
Much of our DUnit framework begins members that ultimately reaches
{{o.a.g.internal.AvailablePort}} to choose a port on which the locator and
members will communicate. This class is naive and can return the same
randomly-chosen port across multiple requests. Though statistically rare, this
has proven not infrequent with our current rate of testing.
Possible amelioration: The possibility of collision could be reduced
significantly if the {{AvailablePort}} class retains the previous [N=20] ports
it has offered as available, refusing to offer as available a port it has
offered recently.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5165) Avoid OOME when scanning for annotated classes
[ https://issues.apache.org/jira/browse/GEODE-5165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg updated GEODE-5165: Component/s: docs > Avoid OOME when scanning for annotated classes > -- > > Key: GEODE-5165 > URL: https://issues.apache.org/jira/browse/GEODE-5165 > Project: Geode > Issue Type: Bug > Components: configuration, docs >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > > when we scan the entire classpath for a certain annotated class, we ran into > OOME in our test environment. Need to add a capability to limit the packages > to scan if geode.packagesToScan system property is set. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-2953) Code Cleanup: Replace wildcard imports with explicit imports
[ https://issues.apache.org/jira/browse/GEODE-2953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg resolved GEODE-2953. - Resolution: Fixed > Code Cleanup: Replace wildcard imports with explicit imports > > > Key: GEODE-2953 > URL: https://issues.apache.org/jira/browse/GEODE-2953 > Project: Geode > Issue Type: Sub-task > Components: general >Reporter: Patrick Rhomberg >Assignee: Patrick Rhomberg >Priority: Minor > Labels: pull-request-available > Time Spent: 9h 40m > Remaining Estimate: 0h > > While optimal import order may be a matter of debate, all style guides seem > to agree that wildcard imports should be avoided for improved readability and > namespace cleanliness. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-5185) Correct recent backward-compatibility violation in 'create gateway-receiver' command.
Patrick Rhomberg created GEODE-5185:
---
Summary: Correct recent backward-compatibility violation in
'create gateway-receiver' command.
Key: GEODE-5185
URL: https://issues.apache.org/jira/browse/GEODE-5185
Project: Geode
Issue Type: Bug
Reporter: Patrick Rhomberg
Commit {{4dff0cde9c3abca2dad03897c055e9c443a81b60}} changed {{create
gateway-receiver}} to fail if any server fails to create the gateway receiver
when the {{if-not-exists}} command is not given. This is inconsistent with the
expected behavior of previous minor releases.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-5185) Correct recent backward-compatibility violation in 'create gateway-receiver' command.
[
https://issues.apache.org/jira/browse/GEODE-5185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg reassigned GEODE-5185:
---
Assignee: Patrick Rhomberg
> Correct recent backward-compatibility violation in 'create gateway-receiver'
> command.
> -
>
> Key: GEODE-5185
> URL: https://issues.apache.org/jira/browse/GEODE-5185
> Project: Geode
> Issue Type: Bug
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
>
> Commit {{4dff0cde9c3abca2dad03897c055e9c443a81b60}} changed {{create
> gateway-receiver}} to fail if any server fails to create the gateway receiver
> when the {{if-not-exists}} command is not given. This is inconsistent with
> the expected behavior of previous minor releases.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5185) Correct recent backward-compatibility violation in 'create gateway-receiver' command.
[
https://issues.apache.org/jira/browse/GEODE-5185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg updated GEODE-5185:
Labels: pull-request-available (was: )
> Correct recent backward-compatibility violation in 'create gateway-receiver'
> command.
> -
>
> Key: GEODE-5185
> URL: https://issues.apache.org/jira/browse/GEODE-5185
> Project: Geode
> Issue Type: Bug
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
>
> Commit {{4dff0cde9c3abca2dad03897c055e9c443a81b60}} changed {{create
> gateway-receiver}} to fail if any server fails to create the gateway receiver
> when the {{if-not-exists}} command is not given. This is inconsistent with
> the expected behavior of previous minor releases.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5001) Update logj4 dependency to better integrate with Spring
[
https://issues.apache.org/jira/browse/GEODE-5001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16466607#comment-16466607
]
Patrick Rhomberg commented on GEODE-5001:
-
[~jblum] Regarding the relevance of the LOG4J2-2152, it seemed to be the cause
some failing tests during a previous attempt to bump versions. I vaguely
remember the pressure being on Jackson, Jetty, and Spring, so not a great deal
of effort was given to resolving the Log4j conflicts at the time.
For context, I believe GEODE-4030 was the ticket then, with
[PR#1199|https://github.com/apache/geode/pull/1199] addressing that ticket and
mentioning the failures in {{SessionReplicationIntegrationJUnitTest}} at either
bump to 2.9.x or 2.10.x.
I've begun a precheckin based off PR#1741 (merged with develop), which uses
2.11.0. Run locally, {{SessionReplicationIntegrationJUnitTest}} doesn't appear
to fail. If it clears precheckin, this should be able to be resolved directly,
and if not, I can dig deeper into the conflicts.
> Update logj4 dependency to better integrate with Spring
> ---
>
> Key: GEODE-5001
> URL: https://issues.apache.org/jira/browse/GEODE-5001
> Project: Geode
> Issue Type: Improvement
> Components: build, logging
>Reporter: Anthony Baker
>Assignee: Barbara Pruijn
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The current geode log4j dependency is v2.8.2. Spring (Boot, Data, etc) use
> log4j v2.11.0. This make integration challenging. We should upgrade our
> dependency to match Spring. This will make it easier for our users to write
> geode applications.
> Checking for other updates using
> {noformat}
> gradle dependencyUpdates
> find . -name report.txt | xargs grep -e "\]$" | grep -v "org.apache.geode" |
> tr -s " " | cut -d' ' -f3- | sort | uniq | less
> {noformat}
> show that we have some other libraries that can be updated as well:
> {noformat}
> com.fasterxml.jackson.core:jackson-annotations [2.9.4 -> 2.9.5]
> com.fasterxml.jackson.core:jackson-core [2.9.4 -> 2.9.5]
> com.fasterxml.jackson.core:jackson-databind [2.9.4 -> 2.9.5]
> com.fasterxml.jackson.module:jackson-module-scala_2.10 [2.9.4 -> 2.9.5]
> com.google.guava:guava [24.0-jre -> 24.1-jre]
> com.google.protobuf:protoc [3.5.1 -> 3.5.1-1]
> com.zaxxer:HikariCP [2.7.6 -> 3.0.0]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-5189) Refactor SessionReplicationIntegrationJUnitTest to not require PerTestClassLoaderRunner
Patrick Rhomberg created GEODE-5189: --- Summary: Refactor SessionReplicationIntegrationJUnitTest to not require PerTestClassLoaderRunner Key: GEODE-5189 URL: https://issues.apache.org/jira/browse/GEODE-5189 Project: Geode Issue Type: Bug Reporter: Patrick Rhomberg Log4j2 versions 2.8 and higher will error when classloaders are split as they are in the PerTestClassLoaderRunner. This runner class should be removed, with the single test class consuming it refactored to not require it. This may require conversion to a DUnit test rather than an Integration test. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5189) Refactor SessionReplicationIntegrationJUnitTest to not require PerTestClassLoaderRunner
[ https://issues.apache.org/jira/browse/GEODE-5189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg updated GEODE-5189: Component/s: rest (dev) logging > Refactor SessionReplicationIntegrationJUnitTest to not require > PerTestClassLoaderRunner > --- > > Key: GEODE-5189 > URL: https://issues.apache.org/jira/browse/GEODE-5189 > Project: Geode > Issue Type: Bug > Components: logging, rest (dev) >Reporter: Patrick Rhomberg >Priority: Major > > Log4j2 versions 2.8 and higher will error when classloaders are split as they > are in the PerTestClassLoaderRunner. This runner class should be removed, > with the single test class consuming it refactored to not require it. This > may require conversion to a DUnit test rather than an Integration test. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5001) Update logj4 dependency to better integrate with Spring
[
https://issues.apache.org/jira/browse/GEODE-5001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16467892#comment-16467892
]
Patrick Rhomberg commented on GEODE-5001:
-
Copying my comment from PR#1741:
{quote}I've run a precheckin based off (a merge-resolved copy of) this PR. As
per the previous attempt, the {{SessionReplicationIntegrationJUnitTest}} blows
up badly. Originally, the error appeared to be
[JOG4J2-2152|https://issues.apache.org/jira/browse/LOG4J2-2152]. In the
discussion of the related ticket
[LOG4J2-2266|https://issues.apache.org/jira/browse/LOG4J2-2266], it looks like
the true error stems from how Log4j2 interacts with the class loader, which in
turn causes tests run with the {{PerTestClassLoaderRunner}} to fail. I've
opened GEODE-5189 to address the test refactoring. Updating Log4j will be
blocked until this can be addressed.{quote}
> Update logj4 dependency to better integrate with Spring
> ---
>
> Key: GEODE-5001
> URL: https://issues.apache.org/jira/browse/GEODE-5001
> Project: Geode
> Issue Type: Improvement
> Components: build, logging
>Reporter: Anthony Baker
>Assignee: Barbara Pruijn
>Priority: Major
> Labels: pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The current geode log4j dependency is v2.8.2. Spring (Boot, Data, etc) use
> log4j v2.11.0. This make integration challenging. We should upgrade our
> dependency to match Spring. This will make it easier for our users to write
> geode applications.
> Checking for other updates using
> {noformat}
> gradle dependencyUpdates
> find . -name report.txt | xargs grep -e "\]$" | grep -v "org.apache.geode" |
> tr -s " " | cut -d' ' -f3- | sort | uniq | less
> {noformat}
> show that we have some other libraries that can be updated as well:
> {noformat}
> com.fasterxml.jackson.core:jackson-annotations [2.9.4 -> 2.9.5]
> com.fasterxml.jackson.core:jackson-core [2.9.4 -> 2.9.5]
> com.fasterxml.jackson.core:jackson-databind [2.9.4 -> 2.9.5]
> com.fasterxml.jackson.module:jackson-module-scala_2.10 [2.9.4 -> 2.9.5]
> com.google.guava:guava [24.0-jre -> 24.1-jre]
> com.google.protobuf:protoc [3.5.1 -> 3.5.1-1]
> com.zaxxer:HikariCP [2.7.6 -> 3.0.0]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-5212) Address Java-structural issues surrounding Windows deployment.
Patrick Rhomberg created GEODE-5212: --- Summary: Address Java-structural issues surrounding Windows deployment. Key: GEODE-5212 URL: https://issues.apache.org/jira/browse/GEODE-5212 Project: Geode Issue Type: Bug Reporter: Patrick Rhomberg Windows regressions currently fail spectacularly. The primary culprits appear to be based around filesystem I/O and passing the current working directory to members started by our testing framework. The scope of this ticket will be defined by "refactors" as children tickets. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-5213) Convert directory traversal to be OS-agnostic
Patrick Rhomberg created GEODE-5213:
---
Summary: Convert directory traversal to be OS-agnostic
Key: GEODE-5213
URL: https://issues.apache.org/jira/browse/GEODE-5213
Project: Geode
Issue Type: Sub-task
Reporter: Patrick Rhomberg
Many paths are hard-coded to the Unix style of {{/to/my/file}}, which is
incompatable with Windows. These should be converted to use the OS-agnostic
{{Path(to).resolve(my).resolve(file)}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-5214) New-lines should be OS-agnostic
Patrick Rhomberg created GEODE-5214:
---
Summary: New-lines should be OS-agnostic
Key: GEODE-5214
URL: https://issues.apache.org/jira/browse/GEODE-5214
Project: Geode
Issue Type: Sub-task
Reporter: Patrick Rhomberg
There exist many explicit {{\n}} newlines. These should use
{{System.lineSeparator()}} or one of the utils that refers to it instead.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-5215) Investigate member launcher failures on Windows
Patrick Rhomberg created GEODE-5215:
---
Summary: Investigate member launcher failures on Windows
Key: GEODE-5215
URL: https://issues.apache.org/jira/browse/GEODE-5215
Project: Geode
Issue Type: Sub-task
Reporter: Patrick Rhomberg
Much of the distributed testing framework fails on Windows with an error like
the below, awaiting the starting member and eventually timing out.
This in turn could potentially be the fault of GEODE-5213's interaction with
the filesystem, or may be due to the "user.dir" working directory not passing
correctly to the started VM.
{noformat}
org.awaitility.core.ConditionTimeoutException: Condition defined as a lambda
expression in
org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase that uses
org.apache.geode.distributed.ServerLauncher expected:<[online]> but was:<[not
responding]> within 2 minutes.
at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:104)
at
org.awaitility.core.AssertionCondition.await(AssertionCondition.java:117)
at
org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:809)
at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:648)
at
org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.awaitStart(ServerLauncherRemoteIntegrationTestCase.java:198)
at
org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.awaitStart(ServerLauncherRemoteIntegrationTestCase.java:177)
at
org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.startServer(ServerLauncherRemoteIntegrationTestCase.java:134)
at
org.apache.geode.distributed.ServerLauncherRemoteWithCustomLoggingIntegrationTest.startWithCustomLoggingConfiguration(ServerLauncherRemoteWithCustomLoggingIntegrationTest.java:55)
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.contrib.java.lang.system.internal.LogPrintStream$1$1.evaluate(LogPrintStream.java:30)
at
org.junit.contrib.java.lang.system.internal.PrintStreamHandler$3.evaluate(PrintStreamHandler.java:48)
at
org.junit.contrib.java.lang.system.internal.LogPrintStream$1.evaluate(LogPrintStream.java:26)
at org.junit.rules.Verifier$1.evaluate(Verifier.java:35)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.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.i
[jira] [Created] (GEODE-5216) Spring Shell errors are swallowed by Powershell
Patrick Rhomberg created GEODE-5216:
---
Summary: Spring Shell errors are swallowed by Powershell
Key: GEODE-5216
URL: https://issues.apache.org/jira/browse/GEODE-5216
Project: Geode
Issue Type: Sub-task
Reporter: Patrick Rhomberg
It appears that powershell does not display error input commands from gfsh,
making development on Windows difficult.
Executing via {{cmd}} does appear to behave as expected.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5212) Address Java-structural issues surrounding Windows deployment.
[ https://issues.apache.org/jira/browse/GEODE-5212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg updated GEODE-5212: Component/s: gfsh general > Address Java-structural issues surrounding Windows deployment. > -- > > Key: GEODE-5212 > URL: https://issues.apache.org/jira/browse/GEODE-5212 > Project: Geode > Issue Type: Bug > Components: general, gfsh >Reporter: Patrick Rhomberg >Priority: Major > Labels: windows > > Windows regressions currently fail spectacularly. The primary culprits > appear to be based around filesystem I/O and passing the current working > directory to members started by our testing framework. > > The scope of this ticket will be defined by "refactors" as children tickets. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5213) Convert directory traversal to be OS-agnostic
[
https://issues.apache.org/jira/browse/GEODE-5213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg updated GEODE-5213:
Labels: windows (was: )
> Convert directory traversal to be OS-agnostic
> -
>
> Key: GEODE-5213
> URL: https://issues.apache.org/jira/browse/GEODE-5213
> Project: Geode
> Issue Type: Sub-task
> Components: general, gfsh
>Reporter: Patrick Rhomberg
>Priority: Major
> Labels: windows
>
> Many paths are hard-coded to the Unix style of {{/to/my/file}}, which is
> incompatable with Windows. These should be converted to use the OS-agnostic
> {{Path(to).resolve(my).resolve(file)}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5213) Convert directory traversal to be OS-agnostic
[
https://issues.apache.org/jira/browse/GEODE-5213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg updated GEODE-5213:
Component/s: gfsh
general
> Convert directory traversal to be OS-agnostic
> -
>
> Key: GEODE-5213
> URL: https://issues.apache.org/jira/browse/GEODE-5213
> Project: Geode
> Issue Type: Sub-task
> Components: general, gfsh
>Reporter: Patrick Rhomberg
>Priority: Major
> Labels: windows
>
> Many paths are hard-coded to the Unix style of {{/to/my/file}}, which is
> incompatable with Windows. These should be converted to use the OS-agnostic
> {{Path(to).resolve(my).resolve(file)}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5214) New-lines should be OS-agnostic
[
https://issues.apache.org/jira/browse/GEODE-5214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg updated GEODE-5214:
Component/s: gfsh
general
> New-lines should be OS-agnostic
> ---
>
> Key: GEODE-5214
> URL: https://issues.apache.org/jira/browse/GEODE-5214
> Project: Geode
> Issue Type: Sub-task
> Components: general, gfsh
>Reporter: Patrick Rhomberg
>Priority: Major
>
> There exist many explicit {{\n}} newlines. These should use
> {{System.lineSeparator()}} or one of the utils that refers to it instead.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5216) Spring Shell errors are swallowed by Powershell
[
https://issues.apache.org/jira/browse/GEODE-5216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg updated GEODE-5216:
Labels: windows (was: )
> Spring Shell errors are swallowed by Powershell
> ---
>
> Key: GEODE-5216
> URL: https://issues.apache.org/jira/browse/GEODE-5216
> Project: Geode
> Issue Type: Sub-task
> Components: general, gfsh
>Reporter: Patrick Rhomberg
>Priority: Major
> Labels: SpringShell, windows
>
> It appears that powershell does not display error input commands from gfsh,
> making development on Windows difficult.
> Executing via {{cmd}} does appear to behave as expected.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5215) Investigate member launcher failures on Windows
[
https://issues.apache.org/jira/browse/GEODE-5215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg updated GEODE-5215:
Component/s: tests
gfsh
general
> Investigate member launcher failures on Windows
> ---
>
> Key: GEODE-5215
> URL: https://issues.apache.org/jira/browse/GEODE-5215
> Project: Geode
> Issue Type: Sub-task
> Components: general, gfsh, tests
>Reporter: Patrick Rhomberg
>Priority: Major
>
> Much of the distributed testing framework fails on Windows with an error like
> the below, awaiting the starting member and eventually timing out.
> This in turn could potentially be the fault of GEODE-5213's interaction with
> the filesystem, or may be due to the "user.dir" working directory not passing
> correctly to the started VM.
>
> {noformat}
> org.awaitility.core.ConditionTimeoutException: Condition defined as a lambda
> expression in
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase that
> uses org.apache.geode.distributed.ServerLauncher expected:<[online]> but
> was:<[not responding]> within 2 minutes.
> at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:104)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:117)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
> at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:809)
> at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:648)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.awaitStart(ServerLauncherRemoteIntegrationTestCase.java:198)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.awaitStart(ServerLauncherRemoteIntegrationTestCase.java:177)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.startServer(ServerLauncherRemoteIntegrationTestCase.java:134)
> at
> org.apache.geode.distributed.ServerLauncherRemoteWithCustomLoggingIntegrationTest.startWithCustomLoggingConfiguration(ServerLauncherRemoteWithCustomLoggingIntegrationTest.java:55)
> 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.contrib.java.lang.system.internal.LogPrintStream$1$1.evaluate(LogPrintStream.java:30)
> at
> org.junit.contrib.java.lang.system.internal.PrintStreamHandler$3.evaluate(PrintStreamHandler.java:48)
> at
> org.junit.contrib.java.lang.system.internal.LogPrintStream$1.evaluate(LogPrintStream.java:26)
> at org.junit.rules.Verifier$1.evaluate(Verifier.java:35)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(
[jira] [Updated] (GEODE-5214) New-lines should be OS-agnostic
[
https://issues.apache.org/jira/browse/GEODE-5214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg updated GEODE-5214:
Labels: windows (was: )
> New-lines should be OS-agnostic
> ---
>
> Key: GEODE-5214
> URL: https://issues.apache.org/jira/browse/GEODE-5214
> Project: Geode
> Issue Type: Sub-task
> Components: general, gfsh
>Reporter: Patrick Rhomberg
>Priority: Major
> Labels: windows
>
> There exist many explicit {{\n}} newlines. These should use
> {{System.lineSeparator()}} or one of the utils that refers to it instead.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5216) Spring Shell errors are swallowed by Powershell
[
https://issues.apache.org/jira/browse/GEODE-5216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg updated GEODE-5216:
Labels: SpringShell windows (was: windows)
> Spring Shell errors are swallowed by Powershell
> ---
>
> Key: GEODE-5216
> URL: https://issues.apache.org/jira/browse/GEODE-5216
> Project: Geode
> Issue Type: Sub-task
> Components: general, gfsh
>Reporter: Patrick Rhomberg
>Priority: Major
> Labels: SpringShell, windows
>
> It appears that powershell does not display error input commands from gfsh,
> making development on Windows difficult.
> Executing via {{cmd}} does appear to behave as expected.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5216) Spring Shell errors are swallowed by Powershell
[
https://issues.apache.org/jira/browse/GEODE-5216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg updated GEODE-5216:
Component/s: gfsh
general
> Spring Shell errors are swallowed by Powershell
> ---
>
> Key: GEODE-5216
> URL: https://issues.apache.org/jira/browse/GEODE-5216
> Project: Geode
> Issue Type: Sub-task
> Components: general, gfsh
>Reporter: Patrick Rhomberg
>Priority: Major
> Labels: SpringShell, windows
>
> It appears that powershell does not display error input commands from gfsh,
> making development on Windows difficult.
> Executing via {{cmd}} does appear to behave as expected.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-5217) Reconsile support of deprecated gemfire.* properties with current geode.* property specification
Patrick Rhomberg created GEODE-5217:
---
Summary: Reconsile support of deprecated gemfire.* properties with
current geode.* property specification
Key: GEODE-5217
URL: https://issues.apache.org/jira/browse/GEODE-5217
Project: Geode
Issue Type: Bug
Components: configuration
Reporter: Patrick Rhomberg
By way of intent, properties historically stored as {{gemfire.my-property}}
should now be stored as {{geode.my-property}}. To support pre-open-source
implementations, we support (as deprecated) the {{gemfire}} property prefix as
though it were a {{geode}} prefix.
By way of intent, the {{SystemPropertyHelper}} class wraps environment property
calls to abstract this dual-prefix support.
Problematically, the {{DistributionConfig}} class specifies its own
{{GEMFIRE_PREFIX}}, with extending classes calling {{System.getProperty}} and
its proxies (e.g., {{Integer.getInteger}}) directly, rather that using the
{{SystemPropertyHelper}}.
As a result, some properties (e.g., cluster-ssl) cannot be provided on the
command-line using the intuitive "geode.cluster-ssl" and must use
"gemfire.cluster-ssl".
The {{DistributionConfig}} and affiliate classes should be refactor to support
the modern, open-source project naming.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5217) Reconcile support of deprecated gemfire.* properties with current geode.* property specification
[
https://issues.apache.org/jira/browse/GEODE-5217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg updated GEODE-5217:
Description:
By way of intent, properties historically stored as {{gemfire.my-property}}
should now be stored as {{geode.my-property}}. To support pre-open-source
implementations, we support (as deprecated) the {{gemfire}} property prefix as
though it were a {{geode}} prefix.
By way of intent, the {{SystemPropertyHelper}} class wraps environment property
calls to abstract this dual-prefix support.
Problematically, the {{DistributionConfig}} class specifies its own
{{GEMFIRE_PREFIX}}, with extending classes calling {{System.getProperty}} and
its proxies (e.g., {{Integer.getInteger}}) directly, rather that using the
{{SystemPropertyHelper}}.
When properties are injected into the system environment from a properties
file, it appears to use the {{gemfire.}} prefix for compatibility with existing
implementations.
As a result however, some properties (e.g., cluster-ssl) cannot be provided on
the command-line using the intuitive "geode.cluster-ssl" and must use
"gemfire.cluster-ssl".
The {{DistributionConfig}} and affiliate classes should be refactor to support
the modern, open-source project naming.
To reproduce, observe that the following correctly enforces peer-to-peer SSL
{noformat}
start locator --name=GemfireLocator --http-service-port=0
--bind-address=localhost --enable-cluster-configuration=true\
--J=-Dgemfire.jmx-manager-hostname-for-clients=localhost
--J=-Dgemfire.feature-protobuf-protocol=false
--J=-Dgemfire.ssl-enabled-components=locator\
--J=-Dgemfire.ssl-keystore=myKeystore.jsk
--J=-Dgemfire.ssl-keystore-password=secret\
--J=-Dgemfire.ssl-truststore=myTruststore.jks
--J=-Dgemfire.ssl-truststore-password=alsoSecret
{noformat}
while this does not
{noformat}
start locator --name=GeodeLocator --http-service-port=0
--bind-address=localhost --enable-cluster-configuration=true\
--J=-Dgeode.jmx-manager-hostname-for-clients=localhost
--J=-Dgeode.feature-protobuf-protocol=false
--J=-Dgeode.ssl-enabled-components=locator\
--J=-Dgeode.ssl-keystore=myKeystore.jsk
--J=-Dgeode.ssl-keystore-password=secret\
--J=-Dgeode.ssl-truststore=myTruststore.jks
--J=-Dgeode.ssl-truststore-password=alsoSecret
{noformat}
was:
By way of intent, properties historically stored as {{gemfire.my-property}}
should now be stored as {{geode.my-property}}. To support pre-open-source
implementations, we support (as deprecated) the {{gemfire}} property prefix as
though it were a {{geode}} prefix.
By way of intent, the {{SystemPropertyHelper}} class wraps environment property
calls to abstract this dual-prefix support.
Problematically, the {{DistributionConfig}} class specifies its own
{{GEMFIRE_PREFIX}}, with extending classes calling {{System.getProperty}} and
its proxies (e.g., {{Integer.getInteger}}) directly, rather that using the
{{SystemPropertyHelper}}.
As a result, some properties (e.g., cluster-ssl) cannot be provided on the
command-line using the intuitive "geode.cluster-ssl" and must use
"gemfire.cluster-ssl".
The {{DistributionConfig}} and affiliate classes should be refactor to support
the modern, open-source project naming.
> Reconcile support of deprecated gemfire.* properties with current geode.*
> property specification
>
>
> Key: GEODE-5217
> URL: https://issues.apache.org/jira/browse/GEODE-5217
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Reporter: Patrick Rhomberg
>Priority: Major
>
> By way of intent, properties historically stored as {{gemfire.my-property}}
> should now be stored as {{geode.my-property}}. To support pre-open-source
> implementations, we support (as deprecated) the {{gemfire}} property prefix
> as though it were a {{geode}} prefix.
> By way of intent, the {{SystemPropertyHelper}} class wraps environment
> property calls to abstract this dual-prefix support.
> Problematically, the {{DistributionConfig}} class specifies its own
> {{GEMFIRE_PREFIX}}, with extending classes calling {{System.getProperty}} and
> its proxies (e.g., {{Integer.getInteger}}) directly, rather that using the
> {{SystemPropertyHelper}}.
> When properties are injected into the system environment from a properties
> file, it appears to use the {{gemfire.}} prefix for compatibility with
> existing implementations.
> As a result however, some properties (e.g., cluster-ssl) cannot be provided
> on the command-line using the intuitive "geode.cluster-ssl" and must use
> "gemfire.cluster-ssl".
> The {{DistributionConfig}} and affiliate classes should be refactor to
> support the modern, open-source project naming.
>
> To reproduce, observe that the following
[jira] [Updated] (GEODE-5212) Many distributedTest and integrationTest failures on windows
[ https://issues.apache.org/jira/browse/GEODE-5212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg updated GEODE-5212: Issue Type: Task (was: Bug) > Many distributedTest and integrationTest failures on windows > > > Key: GEODE-5212 > URL: https://issues.apache.org/jira/browse/GEODE-5212 > Project: Geode > Issue Type: Task > Components: general, gfsh >Reporter: Patrick Rhomberg >Priority: Major > Labels: windows > > Windows regressions currently fail spectacularly. The primary culprits > appear to be based around filesystem I/O and passing the current working > directory to members started by our testing framework. > > The scope of this ticket will be defined by "refactors" as children tickets. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5214) New-lines should be OS-agnostic
[
https://issues.apache.org/jira/browse/GEODE-5214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg updated GEODE-5214:
Description:
There exist many explicit {{\n}} newlines. These should use
{{System.lineSeparator()}} or one of the utils that refers to it instead.
Because many tests search output for explicit strings, hard-coding one type of
line separator could cause some tests to fail.
was:There exist many explicit {{\n}} newlines. These should use
{{System.lineSeparator()}} or one of the utils that refers to it instead.
> New-lines should be OS-agnostic
> ---
>
> Key: GEODE-5214
> URL: https://issues.apache.org/jira/browse/GEODE-5214
> Project: Geode
> Issue Type: Sub-task
> Components: general, gfsh
>Reporter: Patrick Rhomberg
>Priority: Major
> Labels: windows
>
> There exist many explicit {{\n}} newlines. These should use
> {{System.lineSeparator()}} or one of the utils that refers to it instead.
> Because many tests search output for explicit strings, hard-coding one type
> of line separator could cause some tests to fail.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5215) Investigate member launcher failures on Windows
[
https://issues.apache.org/jira/browse/GEODE-5215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg updated GEODE-5215:
Labels: windows (was: )
> Investigate member launcher failures on Windows
> ---
>
> Key: GEODE-5215
> URL: https://issues.apache.org/jira/browse/GEODE-5215
> Project: Geode
> Issue Type: Sub-task
> Components: general, gfsh, tests
>Reporter: Patrick Rhomberg
>Priority: Major
> Labels: windows
>
> Much of the distributed testing framework fails on Windows with an error like
> the below, awaiting the starting member and eventually timing out.
> This in turn could potentially be the fault of GEODE-5213's interaction with
> the filesystem, or may be due to the "user.dir" working directory not passing
> correctly to the started VM.
>
> {noformat}
> org.awaitility.core.ConditionTimeoutException: Condition defined as a lambda
> expression in
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase that
> uses org.apache.geode.distributed.ServerLauncher expected:<[online]> but
> was:<[not responding]> within 2 minutes.
> at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:104)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:117)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
> at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:809)
> at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:648)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.awaitStart(ServerLauncherRemoteIntegrationTestCase.java:198)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.awaitStart(ServerLauncherRemoteIntegrationTestCase.java:177)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.startServer(ServerLauncherRemoteIntegrationTestCase.java:134)
> at
> org.apache.geode.distributed.ServerLauncherRemoteWithCustomLoggingIntegrationTest.startWithCustomLoggingConfiguration(ServerLauncherRemoteWithCustomLoggingIntegrationTest.java:55)
> 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.contrib.java.lang.system.internal.LogPrintStream$1$1.evaluate(LogPrintStream.java:30)
> at
> org.junit.contrib.java.lang.system.internal.PrintStreamHandler$3.evaluate(PrintStreamHandler.java:48)
> at
> org.junit.contrib.java.lang.system.internal.LogPrintStream$1.evaluate(LogPrintStream.java:26)
> at org.junit.rules.Verifier$1.evaluate(Verifier.java:35)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestC
[jira] [Updated] (GEODE-5217) Some configuration properties passed on the command-line must be passed with the gemfire.* prefix rather than the geode.* prefix.
[
https://issues.apache.org/jira/browse/GEODE-5217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg updated GEODE-5217:
Summary: Some configuration properties passed on the command-line must be
passed with the gemfire.* prefix rather than the geode.* prefix. (was:
Reconcile support of deprecated gemfire.* properties with current geode.*
property specification)
> Some configuration properties passed on the command-line must be passed with
> the gemfire.* prefix rather than the geode.* prefix.
> -
>
> Key: GEODE-5217
> URL: https://issues.apache.org/jira/browse/GEODE-5217
> Project: Geode
> Issue Type: Bug
> Components: configuration, docs
>Reporter: Patrick Rhomberg
>Priority: Major
>
> By way of intent, properties historically stored as {{gemfire.my-property}}
> should now be stored as {{geode.my-property}}. To support pre-open-source
> implementations, we support (as deprecated) the {{gemfire}} property prefix
> as though it were a {{geode}} prefix.
> By way of intent, the {{SystemPropertyHelper}} class wraps environment
> property calls to abstract this dual-prefix support.
> Problematically, the {{DistributionConfig}} class specifies its own
> {{GEMFIRE_PREFIX}}, with extending classes calling {{System.getProperty}} and
> its proxies (e.g., {{Integer.getInteger}}) directly, rather that using the
> {{SystemPropertyHelper}}.
> When properties are injected into the system environment from a properties
> file, it appears to use the {{gemfire.}} prefix for compatibility with
> existing implementations.
> As a result however, some properties (e.g., cluster-ssl) cannot be provided
> on the command-line using the intuitive "geode.cluster-ssl" and must use
> "gemfire.cluster-ssl".
> The {{DistributionConfig}} and affiliate classes should be refactor to
> support the modern, open-source project naming.
>
> To reproduce, observe that the following correctly enforces peer-to-peer SSL
> {noformat}
> start locator --name=GemfireLocator --http-service-port=0
> --bind-address=localhost --enable-cluster-configuration=true\
> --J=-Dgemfire.jmx-manager-hostname-for-clients=localhost
> --J=-Dgemfire.feature-protobuf-protocol=false
> --J=-Dgemfire.ssl-enabled-components=locator\
> --J=-Dgemfire.ssl-keystore=myKeystore.jsk
> --J=-Dgemfire.ssl-keystore-password=secret\
> --J=-Dgemfire.ssl-truststore=myTruststore.jks
> --J=-Dgemfire.ssl-truststore-password=alsoSecret
> {noformat}
> while this does not
> {noformat}
> start locator --name=GeodeLocator --http-service-port=0
> --bind-address=localhost --enable-cluster-configuration=true\
> --J=-Dgeode.jmx-manager-hostname-for-clients=localhost
> --J=-Dgeode.feature-protobuf-protocol=false
> --J=-Dgeode.ssl-enabled-components=locator\
> --J=-Dgeode.ssl-keystore=myKeystore.jsk
> --J=-Dgeode.ssl-keystore-password=secret\
> --J=-Dgeode.ssl-truststore=myTruststore.jks
> --J=-Dgeode.ssl-truststore-password=alsoSecret
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5189) Refactor SessionReplicationIntegrationJUnitTest to not require PerTestClassLoaderRunner
[
https://issues.apache.org/jira/browse/GEODE-5189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg resolved GEODE-5189.
-
Resolution: Fixed
Fixed and committed under the related ticket GEODE-5001 due to some failure to
communicate tickets. See below.
{noformat}
commit a6cdf6b414e8baf45d9685c4ba358610b242d2f9
Author: Jens Deppe
Date: Wed May 9 12:56:07 2018 -0700
GEODE-5001: For log4j >= 2.10 we need to ignore the log4j jars from the
PerTestClassLoaderRunner (#1938)
- See LOG4J2-2266 and LOG4J-2152
{noformat}
> Refactor SessionReplicationIntegrationJUnitTest to not require
> PerTestClassLoaderRunner
> ---
>
> Key: GEODE-5189
> URL: https://issues.apache.org/jira/browse/GEODE-5189
> Project: Geode
> Issue Type: Bug
> Components: logging, rest (dev)
>Reporter: Patrick Rhomberg
>Priority: Major
>
> Log4j2 versions 2.8 and higher will error when classloaders are split as they
> are in the PerTestClassLoaderRunner. This runner class should be removed,
> with the single test class consuming it refactored to not require it. This
> may require conversion to a DUnit test rather than an Integration test.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-5225) CreateAsyncEventQueueCommand duplicates class-with-parameters efforts.
Patrick Rhomberg created GEODE-5225:
---
Summary: CreateAsyncEventQueueCommand duplicates
class-with-parameters efforts.
Key: GEODE-5225
URL: https://issues.apache.org/jira/browse/GEODE-5225
Project: Geode
Issue Type: Bug
Components: gfsh
Reporter: Patrick Rhomberg
GEODE-3915 introduced the {{ClassName}} type and associated gfsh command-line
converters to accept both a classname and associated parameters in a JSON
format. E.g.,
{noformat}
create async-event-queue \
--listener=path.to.my.ListenerClass{'param1':'value1','param2':'value2'}
{noformat}
The 'create async-event-queue' command currently duplicates this effort in a
less elegant way, in the form of
{noformat}
create async-event-queue --listener=path.to.my.ListenerClass
--listener-param=param1 --listener-param=value1 --listener-param=param2
--listener-param=value2
{noformat}
The {{listener}} option should be migrated to {{ClassName}} type and the
{{listener-param}} option should be deprecated in favor of this.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5225) CreateAsyncEventQueueCommand duplicates class-with-parameters efforts.
[
https://issues.apache.org/jira/browse/GEODE-5225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg updated GEODE-5225:
Issue Type: Improvement (was: Bug)
> CreateAsyncEventQueueCommand duplicates class-with-parameters efforts.
> --
>
> Key: GEODE-5225
> URL: https://issues.apache.org/jira/browse/GEODE-5225
> Project: Geode
> Issue Type: Improvement
> Components: gfsh
>Reporter: Patrick Rhomberg
>Priority: Major
>
> GEODE-3915 introduced the {{ClassName}} type and associated gfsh command-line
> converters to accept both a classname and associated parameters in a JSON
> format. E.g.,
> {noformat}
> create async-event-queue \
> --listener=path.to.my.ListenerClass{'param1':'value1','param2':'value2'}
> {noformat}
> The 'create async-event-queue' command currently duplicates this effort in a
> less elegant way, in the form of
> {noformat}
> create async-event-queue --listener=path.to.my.ListenerClass
> --listener-param=param1 --listener-param=value1 --listener-param=param2
> --listener-param=value2
> {noformat}
> The {{listener}} option should be migrated to {{ClassName}} type and the
> {{listener-param}} option should be deprecated in favor of this.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5225) CreateAsyncEventQueueCommand duplicates class-with-parameters efforts.
[
https://issues.apache.org/jira/browse/GEODE-5225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg updated GEODE-5225:
Description:
GEODE-3915 introduced the {{ClassName}} type and associated gfsh command-line
converters to accept both a classname and associated parameters in a JSON
format. E.g.,
{noformat}
create async-event-queue \
--listener=path.to.my.ListenerClass{'param1':'value1','param2':'value2'}
{noformat}
The 'create async-event-queue' command currently duplicates this effort in a
less elegant way, in the form of
{noformat}
create async-event-queue --listener=path.to.my.ListenerClass
--listener-param=param1#value1 --listener-param#value2
{noformat}
The {{listener}} option should be migrated to {{ClassName}} type and the
{{listener-param}} option should be deprecated in favor of this.
was:
GEODE-3915 introduced the {{ClassName}} type and associated gfsh command-line
converters to accept both a classname and associated parameters in a JSON
format. E.g.,
{noformat}
create async-event-queue \
--listener=path.to.my.ListenerClass{'param1':'value1','param2':'value2'}
{noformat}
The 'create async-event-queue' command currently duplicates this effort in a
less elegant way, in the form of
{noformat}
create async-event-queue --listener=path.to.my.ListenerClass
--listener-param=param1 --listener-param=value1 --listener-param=param2
--listener-param=value2
{noformat}
The {{listener}} option should be migrated to {{ClassName}} type and the
{{listener-param}} option should be deprecated in favor of this.
> CreateAsyncEventQueueCommand duplicates class-with-parameters efforts.
> --
>
> Key: GEODE-5225
> URL: https://issues.apache.org/jira/browse/GEODE-5225
> Project: Geode
> Issue Type: Improvement
> Components: gfsh
>Reporter: Patrick Rhomberg
>Priority: Major
>
> GEODE-3915 introduced the {{ClassName}} type and associated gfsh command-line
> converters to accept both a classname and associated parameters in a JSON
> format. E.g.,
> {noformat}
> create async-event-queue \
> --listener=path.to.my.ListenerClass{'param1':'value1','param2':'value2'}
> {noformat}
> The 'create async-event-queue' command currently duplicates this effort in a
> less elegant way, in the form of
> {noformat}
> create async-event-queue --listener=path.to.my.ListenerClass
> --listener-param=param1#value1 --listener-param#value2
> {noformat}
> The {{listener}} option should be migrated to {{ClassName}} type and the
> {{listener-param}} option should be deprecated in favor of this.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5225) CreateAsyncEventQueueCommand duplicates class-with-parameters efforts.
[
https://issues.apache.org/jira/browse/GEODE-5225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg updated GEODE-5225:
Description:
GEODE-3915 introduced the {{ClassName}} type and associated gfsh command-line
converters to accept both a classname and associated parameters in a JSON
format. E.g.,
{noformat}
create async-event-queue \
--listener=path.to.my.ListenerClass{'param1':'value1','param2':'value2'}
{noformat}
The 'create async-event-queue' command currently duplicates this effort in a
less elegant way, in the form of
{noformat}
create async-event-queue \
--listener=path.to.my.ListenerClass --listener-param=param1#value1
--listener-param#value2
{noformat}
The {{listener}} option should be migrated to {{ClassName}} type and the
{{listener-param}} option should be deprecated in favor of this.
was:
GEODE-3915 introduced the {{ClassName}} type and associated gfsh command-line
converters to accept both a classname and associated parameters in a JSON
format. E.g.,
{noformat}
create async-event-queue \
--listener=path.to.my.ListenerClass{'param1':'value1','param2':'value2'}
{noformat}
The 'create async-event-queue' command currently duplicates this effort in a
less elegant way, in the form of
{noformat}
create async-event-queue --listener=path.to.my.ListenerClass
--listener-param=param1#value1 --listener-param#value2
{noformat}
The {{listener}} option should be migrated to {{ClassName}} type and the
{{listener-param}} option should be deprecated in favor of this.
> CreateAsyncEventQueueCommand duplicates class-with-parameters efforts.
> --
>
> Key: GEODE-5225
> URL: https://issues.apache.org/jira/browse/GEODE-5225
> Project: Geode
> Issue Type: Improvement
> Components: gfsh
>Reporter: Patrick Rhomberg
>Priority: Major
>
> GEODE-3915 introduced the {{ClassName}} type and associated gfsh command-line
> converters to accept both a classname and associated parameters in a JSON
> format. E.g.,
> {noformat}
> create async-event-queue \
> --listener=path.to.my.ListenerClass{'param1':'value1','param2':'value2'}
> {noformat}
> The 'create async-event-queue' command currently duplicates this effort in a
> less elegant way, in the form of
> {noformat}
> create async-event-queue \
> --listener=path.to.my.ListenerClass --listener-param=param1#value1
> --listener-param#value2
> {noformat}
> The {{listener}} option should be migrated to {{ClassName}} type and the
> {{listener-param}} option should be deprecated in favor of this.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-4953) Improve spotless -- prohibit wildcard imports
[ https://issues.apache.org/jira/browse/GEODE-4953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg resolved GEODE-4953. - Resolution: Fixed > Improve spotless -- prohibit wildcard imports > - > > Key: GEODE-4953 > URL: https://issues.apache.org/jira/browse/GEODE-4953 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Rhomberg >Assignee: Patrick Rhomberg >Priority: Major > Labels: pull-request-available > Time Spent: 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-4949) Improve spotless -- runtime, imports, and block comments
[ https://issues.apache.org/jira/browse/GEODE-4949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg resolved GEODE-4949. - Resolution: Fixed > Improve spotless -- runtime, imports, and block comments > > > Key: GEODE-4949 > URL: https://issues.apache.org/jira/browse/GEODE-4949 > Project: Geode > Issue Type: Improvement > Components: general >Reporter: Patrick Rhomberg >Priority: Major > > See > [this|https://markmail.org/message/z5fltynvyn3aeior?q=list:org%2Eapache%2Egeode%2Edev+order:date-backward+spotless#query:list%3Aorg.apache.geode.dev%20order%3Adate-backward%20spotless+page:1+mid:5gqwc3x7occg2alq+state:results] > discussion on the dev-list or the sub-tasks of this ticket for more > information. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-5241) AnalyzeSerializablesJUnitTest reports incorrect location to update sanctioned serializables
Patrick Rhomberg created GEODE-5241:
---
Summary: AnalyzeSerializablesJUnitTest reports incorrect location
to update sanctioned serializables
Key: GEODE-5241
URL: https://issues.apache.org/jira/browse/GEODE-5241
Project: Geode
Issue Type: Task
Reporter: Patrick Rhomberg
This test uses the {{/out/production/resources}} version of the
sanctioned serializables list. In the event that this file needs to be
updated, the error output directs the developer to overwrite this untracked
{{/out/}} file, rather than the tracked {{/src/}} file. Additionally,
overwriting the {{/out/}} will see subsequent runs pass has the potential for a
successful testing build, but will cause errors down the road for other
developers.
Example output for {{AnalyzeSerializablesJIUnitTest::testSerializables}},
wherein I have arbitrarily marked a gfsh command class {{Serializable}}. The
sanctioned list is actually
{{/geode-core/src/main/resources/org/apache/geode/internal/sanctioned-geode-core-serializables.txt}}
{noformat}
java.lang.AssertionError: New or moved
classes
org/apache/geode/management/internal/cli/commands/DestroyAsyncEventQueueCommand,false
If the class is not persisted or sent over the wire add it to the file
/Users/prhomberg/workspace/geode/geode-core/out/test/resources/org/apache/geode/codeAnalysis/excludedClasses.txt
Otherwise if this doesn't break backward compatibility, copy the file
/my/path/to/geode/geode-core/actualSerializables.dat to
/my/path/to/geode/geode-core/out/production/resources/org/apache/geode/internal/sanctioned-geode-core-serializables.txt.
at
org.apache.geode.codeAnalysis.AnalyzeSerializablesJUnitTest.testSerializables(AnalyzeSerializablesJUnitTest.java:201)
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.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
at
com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
at
com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
at
com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5241) AnalyzeSerializablesJUnitTest reports incorrect location to update sanctioned serializables
[
https://issues.apache.org/jira/browse/GEODE-5241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg updated GEODE-5241:
Component/s: serialization
> AnalyzeSerializablesJUnitTest reports incorrect location to update sanctioned
> serializables
> ---
>
> Key: GEODE-5241
> URL: https://issues.apache.org/jira/browse/GEODE-5241
> Project: Geode
> Issue Type: Task
> Components: serialization
>Reporter: Patrick Rhomberg
>Priority: Major
>
> This test uses the {{/out/production/resources}} version of the
> sanctioned serializables list. In the event that this file needs to be
> updated, the error output directs the developer to overwrite this untracked
> {{/out/}} file, rather than the tracked {{/src/}} file. Additionally,
> overwriting the {{/out/}} will see subsequent runs pass has the potential for
> a successful testing build, but will cause errors down the road for other
> developers.
> Example output for {{AnalyzeSerializablesJIUnitTest::testSerializables}},
> wherein I have arbitrarily marked a gfsh command class {{Serializable}}. The
> sanctioned list is actually
> {{/geode-core/src/main/resources/org/apache/geode/internal/sanctioned-geode-core-serializables.txt}}
> {noformat}
> java.lang.AssertionError: New or moved
> classes
> org/apache/geode/management/internal/cli/commands/DestroyAsyncEventQueueCommand,false
> If the class is not persisted or sent over the wire add it to the file
> /Users/prhomberg/workspace/geode/geode-core/out/test/resources/org/apache/geode/codeAnalysis/excludedClasses.txt
> Otherwise if this doesn't break backward compatibility, copy the file
> /my/path/to/geode/geode-core/actualSerializables.dat to
> /my/path/to/geode/geode-core/out/production/resources/org/apache/geode/internal/sanctioned-geode-core-serializables.txt.
> at
> org.apache.geode.codeAnalysis.AnalyzeSerializablesJUnitTest.testSerializables(AnalyzeSerializablesJUnitTest.java:201)
> 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.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-5258) SingleGfshCommand should be parameterized for the configObject's type
Patrick Rhomberg created GEODE-5258:
---
Summary: SingleGfshCommand should be parameterized for the
configObject's type
Key: GEODE-5258
URL: https://issues.apache.org/jira/browse/GEODE-5258
Project: Geode
Issue Type: Sub-task
Reporter: Patrick Rhomberg
The single gfsh command should expect a certain type of object, rather than the
generic {{Object}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-5258) SingleGfshCommand should be parameterized for the configObject's type
[
https://issues.apache.org/jira/browse/GEODE-5258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg reassigned GEODE-5258:
---
Assignee: Patrick Rhomberg
> SingleGfshCommand should be parameterized for the configObject's type
> -
>
> Key: GEODE-5258
> URL: https://issues.apache.org/jira/browse/GEODE-5258
> Project: Geode
> Issue Type: Sub-task
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
>
> The single gfsh command should expect a certain type of object, rather than
> the generic {{Object}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5258) SingleGfshCommand should be parameterized for the configObject's type
[
https://issues.apache.org/jira/browse/GEODE-5258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg updated GEODE-5258:
Component/s: configuration
> SingleGfshCommand should be parameterized for the configObject's type
> -
>
> Key: GEODE-5258
> URL: https://issues.apache.org/jira/browse/GEODE-5258
> Project: Geode
> Issue Type: Sub-task
> Components: configuration
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
>
> The single gfsh command should expect a certain type of object, rather than
> the generic {{Object}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-5284) Add testing surrounding MBean persistence during member failure and reconnection.
Patrick Rhomberg created GEODE-5284: --- Summary: Add testing surrounding MBean persistence during member failure and reconnection. Key: GEODE-5284 URL: https://issues.apache.org/jira/browse/GEODE-5284 Project: Geode Issue Type: Test Components: jmx, tests Reporter: Patrick Rhomberg -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-5284) Add testing surrounding MBean persistence during member failure and reconnection.
[ https://issues.apache.org/jira/browse/GEODE-5284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg reassigned GEODE-5284: --- Assignee: Patrick Rhomberg > Add testing surrounding MBean persistence during member failure and > reconnection. > - > > Key: GEODE-5284 > URL: https://issues.apache.org/jira/browse/GEODE-5284 > Project: Geode > Issue Type: Test > Components: jmx, tests >Reporter: Patrick Rhomberg >Assignee: Patrick Rhomberg >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5284) Add testing surrounding MBean persistence during member failure and reconnection.
[ https://issues.apache.org/jira/browse/GEODE-5284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg updated GEODE-5284: Labels: pull-request-available (was: ) > Add testing surrounding MBean persistence during member failure and > reconnection. > - > > Key: GEODE-5284 > URL: https://issues.apache.org/jira/browse/GEODE-5284 > Project: Geode > Issue Type: Test > Components: jmx, tests >Reporter: Patrick Rhomberg >Assignee: Patrick Rhomberg >Priority: Major > Labels: pull-request-available > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-5293) Improve logging (and possibly robustness) of Pulse UITests
Patrick Rhomberg created GEODE-5293:
---
Summary: Improve logging (and possibly robustness) of Pulse UITests
Key: GEODE-5293
URL: https://issues.apache.org/jira/browse/GEODE-5293
Project: Geode
Issue Type: Test
Reporter: Patrick Rhomberg
The UITests fail intermittently in the {{WebDriverRule}}, timing out during a
simple GET of the pulse login page. The root cause of these failures is
difficult to identify, and the failure in general difficult to intentionally
reproduce. Test logging should be improved to help narrow in on the actual
cause.
Some of the Jetty / Selenium / Chrome connections are performed in the
constructor of the related {{ServerRule}} class, rather than in a {{before}}
method. While the latter may be more robust in testing, the former may
actually reveal deficiencies in Pulse server production code.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-5295) Improve error reporting in ClusterStartupRule await methods
[ https://issues.apache.org/jira/browse/GEODE-5295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg reassigned GEODE-5295: --- Assignee: Patrick Rhomberg > Improve error reporting in ClusterStartupRule await methods > --- > > Key: GEODE-5295 > URL: https://issues.apache.org/jira/browse/GEODE-5295 > Project: Geode > Issue Type: Improvement >Reporter: Patrick Rhomberg >Assignee: Patrick Rhomberg >Priority: Major > Labels: pull-request-available > > The family of methods that wait until the cluster's gateways / regions / disk > stores are ready will occasionally hang, having a number not equal to the > expected number of beans. In these cases, it unclear if the number of > expected element beans is too few (indicating a delay or failure to start) or > too many (indicating a failure to destroy a previous test). > Failure reporting should be improved to indicate the nature of failure. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5295) Improve error reporting in ClusterStartupRule await methods
[ https://issues.apache.org/jira/browse/GEODE-5295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg updated GEODE-5295: Labels: pull-request-available (was: ) > Improve error reporting in ClusterStartupRule await methods > --- > > Key: GEODE-5295 > URL: https://issues.apache.org/jira/browse/GEODE-5295 > Project: Geode > Issue Type: Improvement >Reporter: Patrick Rhomberg >Assignee: Patrick Rhomberg >Priority: Major > Labels: pull-request-available > > The family of methods that wait until the cluster's gateways / regions / disk > stores are ready will occasionally hang, having a number not equal to the > expected number of beans. In these cases, it unclear if the number of > expected element beans is too few (indicating a delay or failure to start) or > too many (indicating a failure to destroy a previous test). > Failure reporting should be improved to indicate the nature of failure. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-5295) Improve error reporting in ClusterStartupRule await methods
Patrick Rhomberg created GEODE-5295: --- Summary: Improve error reporting in ClusterStartupRule await methods Key: GEODE-5295 URL: https://issues.apache.org/jira/browse/GEODE-5295 Project: Geode Issue Type: Improvement Reporter: Patrick Rhomberg The family of methods that wait until the cluster's gateways / regions / disk stores are ready will occasionally hang, having a number not equal to the expected number of beans. In these cases, it unclear if the number of expected element beans is too few (indicating a delay or failure to start) or too many (indicating a failure to destroy a previous test). Failure reporting should be improved to indicate the nature of failure. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-5299) Correct failure resulting from potential race condition in geode-wan:CreateRegionCommandDUnitTest
Patrick Rhomberg created GEODE-5299:
---
Summary: Correct failure resulting from potential race condition
in geode-wan:CreateRegionCommandDUnitTest
Key: GEODE-5299
URL: https://issues.apache.org/jira/browse/GEODE-5299
Project: Geode
Issue Type: Test
Reporter: Patrick Rhomberg
A recent commit contains the line the effective sequence:
{noformat}
locator = lsRule.startLocatorVM(0);
server1 = lsRule.startServerVM(1, locator.getPort());
server2 = lsRule.startServerVM(2, locator.getPort());
gfsh.connectAndVerify(locator);String regionName =
testName.getMethodName();
String gatewaySenderName = "gatewaySender";
IgnoredException.addIgnoredException("could not get remote locator
information");
gfsh.executeAndAssertThat(
"create gateway-sender --parallel=true --remote-distributed-system-id=2
--id="
+ gatewaySenderName)
.statusIsSuccess();
locator.waitTilGatewaySendersAreReady(1);
{noformat}
Notably, the {{waitTilGatewaySendersAreReady}} expects to find 1 gateway mbean
from the two servers on which the gateway will be created.
However, the underlying implementation of the method expects to find *exactly*
1 bean, meaning that if the gateway creation and bean registration occurs
before the {{wait*}} method is called, the test will fail to a hang despite
correct execution.
The true root cause of this error is likely the ambiguity in the method and
variable naming. Consider renaming this method and related to be explicitly
clear to future developers that these methods have exact expectation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-5299) Correct failure resulting from potential race condition in geode-wan:CreateRegionCommandDUnitTest
[
https://issues.apache.org/jira/browse/GEODE-5299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg reassigned GEODE-5299:
---
Assignee: Patrick Rhomberg
> Correct failure resulting from potential race condition in
> geode-wan:CreateRegionCommandDUnitTest
> -
>
> Key: GEODE-5299
> URL: https://issues.apache.org/jira/browse/GEODE-5299
> Project: Geode
> Issue Type: Test
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
>
> A recent commit contains the line the effective sequence:
> {noformat}
> locator = lsRule.startLocatorVM(0);
> server1 = lsRule.startServerVM(1, locator.getPort());
> server2 = lsRule.startServerVM(2, locator.getPort());
> gfsh.connectAndVerify(locator);String regionName =
> testName.getMethodName();
> String gatewaySenderName = "gatewaySender";
> IgnoredException.addIgnoredException("could not get remote locator
> information");
> gfsh.executeAndAssertThat(
> "create gateway-sender --parallel=true
> --remote-distributed-system-id=2 --id="
> + gatewaySenderName)
> .statusIsSuccess();
> locator.waitTilGatewaySendersAreReady(1);
> {noformat}
> Notably, the {{waitTilGatewaySendersAreReady}} expects to find 1 gateway
> mbean from the two servers on which the gateway will be created.
> However, the underlying implementation of the method expects to find
> *exactly* 1 bean, meaning that if the gateway creation and bean registration
> occurs before the {{wait*}} method is called, the test will fail to a hang
> despite correct execution.
> The true root cause of this error is likely the ambiguity in the method and
> variable naming. Consider renaming this method and related to be explicitly
> clear to future developers that these methods have exact expectation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5299) Correct failure resulting from potential race condition in geode-wan:CreateRegionCommandDUnitTest
[
https://issues.apache.org/jira/browse/GEODE-5299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg resolved GEODE-5299.
-
Resolution: Duplicate
> Correct failure resulting from potential race condition in
> geode-wan:CreateRegionCommandDUnitTest
> -
>
> Key: GEODE-5299
> URL: https://issues.apache.org/jira/browse/GEODE-5299
> Project: Geode
> Issue Type: Test
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
>
> A recent commit contains the line the effective sequence:
> {noformat}
> locator = lsRule.startLocatorVM(0);
> server1 = lsRule.startServerVM(1, locator.getPort());
> server2 = lsRule.startServerVM(2, locator.getPort());
> gfsh.connectAndVerify(locator);String regionName =
> testName.getMethodName();
> String gatewaySenderName = "gatewaySender";
> IgnoredException.addIgnoredException("could not get remote locator
> information");
> gfsh.executeAndAssertThat(
> "create gateway-sender --parallel=true
> --remote-distributed-system-id=2 --id="
> + gatewaySenderName)
> .statusIsSuccess();
> locator.waitTilGatewaySendersAreReady(1);
> {noformat}
> Notably, the {{waitTilGatewaySendersAreReady}} expects to find 1 gateway
> mbean from the two servers on which the gateway will be created.
> However, the underlying implementation of the method expects to find
> *exactly* 1 bean, meaning that if the gateway creation and bean registration
> occurs before the {{wait*}} method is called, the test will fail to a hang
> despite correct execution.
> The true root cause of this error is likely the ambiguity in the method and
> variable naming. Consider renaming this method and related to be explicitly
> clear to future developers that these methods have exact expectation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-5364) Improve ClusterStartupRule handling of vm count
Patrick Rhomberg created GEODE-5364: --- Summary: Improve ClusterStartupRule handling of vm count Key: GEODE-5364 URL: https://issues.apache.org/jira/browse/GEODE-5364 Project: Geode Issue Type: Improvement Reporter: Patrick Rhomberg See sub-tasks. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-5365) Remove default constructor for ClusterStartupRule
Patrick Rhomberg created GEODE-5365: --- Summary: Remove default constructor for ClusterStartupRule Key: GEODE-5365 URL: https://issues.apache.org/jira/browse/GEODE-5365 Project: Geode Issue Type: Sub-task Reporter: Patrick Rhomberg Many tests currently spin up more VMs than the test actually requires. This is typically due to the ClusterStartupRule being instantiated using the no-arg constructor. Using four VMs by default may have once been convenient, but it encourages a laissez faire attitude in test development. A developer should give due thought to the number of VMs a test needs to instantiate. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5365) A no-arg ClusterStartupRule constructor encourages bad developer practice
[ https://issues.apache.org/jira/browse/GEODE-5365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg updated GEODE-5365: Summary: A no-arg ClusterStartupRule constructor encourages bad developer practice (was: Remove default constructor for ClusterStartupRule) > A no-arg ClusterStartupRule constructor encourages bad developer practice > - > > Key: GEODE-5365 > URL: https://issues.apache.org/jira/browse/GEODE-5365 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Rhomberg >Priority: Major > > Many tests currently spin up more VMs than the test actually requires. This > is typically due to the ClusterStartupRule being instantiated using the > no-arg constructor. > Using four VMs by default may have once been convenient, but it encourages a > laissez faire attitude in test development. A developer should give due > thought to the number of VMs a test needs to instantiate. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-5366) DUnitLauncher does not respect the number of VMs requested in ClusterStartupRule
Patrick Rhomberg created GEODE-5366:
---
Summary: DUnitLauncher does not respect the number of VMs
requested in ClusterStartupRule
Key: GEODE-5366
URL: https://issues.apache.org/jira/browse/GEODE-5366
Project: Geode
Issue Type: Sub-task
Reporter: Patrick Rhomberg
The ClusterStartupRule has the method
{noformat}
@Override
protected void before() throws Throwable {
DUnitLauncher.launchIfNeeded();
for (int i = 0; i < vmCount; i++) {
Host.getHost(0).getVM(i);
}
restoreSystemProperties.before();
occupiedVMs = new HashMap<>();
}
{noformat}
By calling the no-arg {{launchIfNeeded}}, the number of requested VMs is not
properly passed to the DUnitLauncher. This is not a problem if vmCount > 4,
since the following loop will instantiate any extra VMs. However, if fewer
than 4 VMs are requested, the DUnitLauncher will still spin up extra VMs,
wasting cycles.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-5365) A no-arg ClusterStartupRule constructor encourages bad developer practice
[ https://issues.apache.org/jira/browse/GEODE-5365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg reassigned GEODE-5365: --- Assignee: Patrick Rhomberg > A no-arg ClusterStartupRule constructor encourages bad developer practice > - > > Key: GEODE-5365 > URL: https://issues.apache.org/jira/browse/GEODE-5365 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Rhomberg >Assignee: Patrick Rhomberg >Priority: Major > > Many tests currently spin up more VMs than the test actually requires. This > is typically due to the ClusterStartupRule being instantiated using the > no-arg constructor. > Using four VMs by default may have once been convenient, but it encourages a > laissez faire attitude in test development. A developer should give due > thought to the number of VMs a test needs to instantiate. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-5366) DUnitLauncher does not respect the number of VMs requested in ClusterStartupRule
[
https://issues.apache.org/jira/browse/GEODE-5366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg reassigned GEODE-5366:
---
Assignee: Patrick Rhomberg
> DUnitLauncher does not respect the number of VMs requested in
> ClusterStartupRule
>
>
> Key: GEODE-5366
> URL: https://issues.apache.org/jira/browse/GEODE-5366
> Project: Geode
> Issue Type: Sub-task
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
>
> The ClusterStartupRule has the method
> {noformat}
> @Override
> protected void before() throws Throwable {
> DUnitLauncher.launchIfNeeded();
> for (int i = 0; i < vmCount; i++) {
> Host.getHost(0).getVM(i);
> }
> restoreSystemProperties.before();
> occupiedVMs = new HashMap<>();
> }
> {noformat}
> By calling the no-arg {{launchIfNeeded}}, the number of requested VMs is not
> properly passed to the DUnitLauncher. This is not a problem if vmCount > 4,
> since the following loop will instantiate any extra VMs. However, if fewer
> than 4 VMs are requested, the DUnitLauncher will still spin up extra VMs,
> wasting cycles.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-5371) Ensure all tests marked as Flaky have not been resolved and still are accurately tagged
[ https://issues.apache.org/jira/browse/GEODE-5371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg reassigned GEODE-5371: --- Assignee: Patrick Rhomberg > Ensure all tests marked as Flaky have not been resolved and still are > accurately tagged > --- > > Key: GEODE-5371 > URL: https://issues.apache.org/jira/browse/GEODE-5371 > Project: Geode > Issue Type: Task >Reporter: Alexander Murmann >Assignee: Patrick Rhomberg >Priority: Major > Labels: swat > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5371) Ensure all tests marked as Flaky have not been resolved and still are accurately tagged
[
https://issues.apache.org/jira/browse/GEODE-5371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16530212#comment-16530212
]
Patrick Rhomberg commented on GEODE-5371:
-
And initial, old script produces the following GEODE ticket numbers referenced
inline with a {{Flaky}} tag. In hindsight, I should've updated the script to
include the file in which they are found. But here is a now-slightly-outdated
starting point.
{noformat}
++-+
| Jira # | Status |
++-+
| 153|Reopened |
| 431| Closed |
| 438|Reopened |
| 447| Closed |
| 490|Resolved |
| 500|Reopened |
| 506| Closed |
| 555| Closed |
| 567|Resolved |
| 575| Closed |
| 583| Closed |
| 600| Closed |
| 632|Open |
| 633|Open |
| 635| In Progress |
| 671|Resolved |
| 673| Closed |
| 686|Reopened |
| 690|Open |
| 693|Reopened |
| 694|Open |
| 755|Resolved |
| 757| Closed |
| 838| Closed |
| 853| Closed |
| 860| Closed |
| 897| Closed |
| 900|Reopened |
| 908|Resolved |
| 925|Resolved |
| 928| Closed |
| 932|Open |
| 973|Resolved |
| 976| Closed |
| 987|Open |
| 989|Resolved |
| 1009 |Resolved |
| 1015 | Closed |
| 1045 | Closed |
| 1059 | Closed |
| 1060 | Closed |
| 1068 | Closed |
| 1089 |Open |
| 1091 |Open |
| 1137 |Resolved |
| 1138 | Closed |
| 1140 | Closed |
| 1164 | Closed |
| 1165 |Open |
| 1181 | Closed |
| 1182 | Closed |
| 1249 |Resolved |
| 1251 | Closed |
| 1312 |Resolved |
| 1345 | Closed |
| 1380 |Resolved |
| 1419 |Resolved |
| 1482 | Closed |
| 1487 |Resolved |
| 1497 |Resolved |
| 1502 |Resolved |
| 1537 |Resolved |
| 1552 |Resolved |
| 1561 |Open |
| 1585 |Resolved |
| 1595 |Resolved |
| 1602 |Resolved |
| 1603 |Resolved |
| 1618 |Resolved |
| 1629 |Resolved |
| 1661 |Open |
| 1670 |Resolved |
| 1683 |Open |
| 1688 |Resolved |
| 1703 |Open |
| 1704 |Open |
| 1705 |Open |
| 1717 |Resolved |
| 1763 | Closed |
| 1765 |Resolved |
| 1768 |Resolved |
| 1770 |Open |
| 1771 |Resolved |
| 1806 |Resolved |
| 1828 | Closed |
| 1878 | Closed |
| 1920 |Reopened |
| 1922 | Closed |
| 1924 |Resolved |
| 1930 | Closed |
| 1933 | Closed |
| 1942 | Closed |
| 1943 | Closed |
| 1957 |Resolved |
| 1998 |Open |
| 2009 |Resolved |
| 2022 |Open |
| 2051 |Resolved |
| 2071 |Resolved |
| 2072 |Open |
| 2176 |Resolved |
| 2286 |Open |
| 2790 | Closed |
| 3065 |Open |
| 3205 |Reopened |
| 3404 |Open |
| 3451 |Open |
| 3461 |Reopened |
| 3505 |Reopened |
| 3506 |Open |
| 3530 |Open |
| 3581 |Open |
| 3778 |Reopened |
| 3939 |Open |
| 4647 |Resolved |
| 5094 |Open |
++-+
{noformat}
> Ensure all tests marked as Flaky have not been resolved and still are
> accurately tagged
> ---
>
> Key: GEODE-5371
> URL: https://issues.apache.org/jira/browse/GEODE-5371
> Project: Geode
> Issue Type: Task
>Reporter: Alexander Murmann
>Assignee: Patrick Rhomberg
>Priority: Major
> Labels: swat
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-3065) Tests in RedisServerTest are marked as flaky due to potential bind exceptions
[ https://issues.apache.org/jira/browse/GEODE-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg updated GEODE-3065: Attachment: TEST-org.apache.geode.management.internal.cli.commands.GemfireDataCommandsDUnitTest.xml > Tests in RedisServerTest are marked as flaky due to potential bind exceptions > - > > Key: GEODE-3065 > URL: https://issues.apache.org/jira/browse/GEODE-3065 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Udo Kohlmeyer >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-3065) Tests in RedisServerTest are marked as flaky due to potential bind exceptions
[ https://issues.apache.org/jira/browse/GEODE-3065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg updated GEODE-3065: Attachment: (was: TEST-org.apache.geode.management.internal.cli.commands.GemfireDataCommandsDUnitTest.xml) > Tests in RedisServerTest are marked as flaky due to potential bind exceptions > - > > Key: GEODE-3065 > URL: https://issues.apache.org/jira/browse/GEODE-3065 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Udo Kohlmeyer >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-5378) AcceptanceTests fail because they cannot start service db
[ https://issues.apache.org/jira/browse/GEODE-5378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg reassigned GEODE-5378: --- Assignee: Patrick Rhomberg > AcceptanceTests fail because they cannot start service db > - > > Key: GEODE-5378 > URL: https://issues.apache.org/jira/browse/GEODE-5378 > Project: Geode > Issue Type: Task >Reporter: Alexander Murmann >Assignee: Patrick Rhomberg >Priority: Critical > Labels: swat > > The build 125-127 have had 10 failures that were related to failure to start > a service db in the JDBC tests. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5371) Ensure all tests marked as Flaky have not been resolved and still are accurately tagged
[
https://issues.apache.org/jira/browse/GEODE-5371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16537528#comment-16537528
]
Patrick Rhomberg commented on GEODE-5371:
-
Running over the weekend, the {{FlakyTest}} precheckin target was run 1513
times. The results as aggregated by the {{concourse-job-performance.py}}
script used by the metrics pipeline yields the following:
{noformat}
org.apache.geode.internal.cache.wan.asyncqueue.AsyncEventQueueStatsDUnitTest.testAsyncStatsTwoListeners:
82 failures (94.58030403172505% success rate)
org.apache.geode.internal.cache.partitioned.fixed.FixedPartitioningDUnitTest.testBug43283:
97 failures (93.58889623265037% success rate)
org.apache.geode.internal.cache.partitioned.PersistentPartitionedRegionDistributedTest.recoversFromCloseDuringRegionOperation:
15 failures (99.00859220092532% success rate)
org.apache.geode.internal.cache.persistence.PersistentRecoveryOrderDUnitTest.testCrashDuringPreparePersistentId:
36 failures (97.62062128222075% success rate)
org.apache.geode.security.ClientPostAuthorizationDUnitTest.testAllOpsNotifications:
6 failures (99.60343688037013% success rate)
org.apache.geode.management.internal.cli.commands.LauncherLifecycleCommandsDUnitTest.test014GemFireServerJvmProcessTerminatesOnOutOfMemoryError:
40 failures (97.35624586913417% success rate)
org.apache.geode.internal.cache.persistence.PersistentRecoveryOrderOldConfigDUnitTest.testCrashDuringPreparePersistentId:
30 failures (98.01718440185063% success rate)
org.apache.geode.management.internal.cli.commands.GemfireDataCommandsDUnitTest.testRegionsViaMbeanAndFunctions:
3 failures (99.80171844018506% success rate)
org.apache.geode.redis.HashesJUnitTest.testHIncrBy: 4 failures
(99.73562458691342% success rate)
org.apache.geode.management.internal.cli.commands.GemfireDataCommandsDUnitTest.testRebalanceCommandForSimulateWithNoMember:
1 failures (99.93390614672836% success rate)
org.apache.geode.management.internal.cli.commands.DurableClientCommandsDUnitTest.testCloseDurableCQ:
2 failures (99.86781229345671% success rate)
org.apache.geode.management.internal.cli.commands.LauncherLifecycleCommandsDUnitTest.testVersionTitleForStartServerAndLocator:
2 failures (99.86781229345671% success rate)
org.apache.geode.management.internal.cli.commands.DurableClientCommandsDUnitTest.testCloseDurableClients:
1 failures (99.93390614672836% success rate)
org.apache.geode.distributed.SystemAdminDUnitTest.testPrintStacks: 1 failures
(99.93390614672836% success rate)
org.apache.geode.management.internal.cli.commands.RebalanceCommandOverHttpDistributedTest.testSimulateForEntireDSWithTimeout:
1 failures (99.93390614672836% success rate)
org.apache.geode.cache30.DistributedNoAckRegionCCEDUnitTest.testConcurrentEventsOnEmptyRegion:
1 failures (99.93390614672836% success rate)
org.apache.geode.internal.cache.DeprecatedCacheServerLauncherIntegrationTest.testCreateBuckets:
1 failures (99.93390614672836% success rate)
org.apache.geode.internal.cache.PartitionedRegionSingleHopDUnitTest.testMetadataIsSameOnAllServersAndClients:
1 failures (99.93390614672836% success rate)
org.apache.geode.management.internal.cli.commands.GemfireDataCommandsDUnitTest.testSimulateForEntireDS:
1 failures (99.93390614672836% success rate)
org.apache.geode.cache30.DistributedNoAckRegionCCEOffHeapDUnitTest.testConcurrentEventsOnEmptyRegion:
1 failures (99.93390614672836% success rate)
org.apache.geode.management.WANManagementDUnitTest.testReceiverMBean: 1
failures (99.93390614672836% success rate)
org.apache.geode.management.internal.cli.commands.GemfireDataCommandsDUnitTest.testRebalanceCommandForTimeOutForRegion:
1 failures (99.93390614672836% success rate)
org.apache.geode.management.internal.cli.commands.GemfireDataCommandsDUnitTest.testSimulateForEntireDSWithTimeout:
1 failures (99.93390614672836% success rate)
org.apache.geode.cache30.DistributedAckPersistentRegionCCEOffHeapDUnitTest.testConcurrentEventsOnEmptyRegion:
1 failures (99.93390614672836% success rate)
{noformat}
> Ensure all tests marked as Flaky have not been resolved and still are
> accurately tagged
> ---
>
> Key: GEODE-5371
> URL: https://issues.apache.org/jira/browse/GEODE-5371
> Project: Geode
> Issue Type: Task
>Reporter: Alexander Murmann
>Assignee: Patrick Rhomberg
>Priority: Major
> Labels: swat
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (GEODE-5371) Ensure all tests marked as Flaky have not been resolved and still are accurately tagged
[
https://issues.apache.org/jira/browse/GEODE-5371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16537528#comment-16537528
]
Patrick Rhomberg edited comment on GEODE-5371 at 7/9/18 9:21 PM:
-
Running over the weekend, the {{FlakyTest}} precheckin target was run 1513
times. The results as aggregated by the {{concourse-job-performance.py}}
script used by the metrics pipeline yields the following:
{noformat}
org.apache.geode.cache30.DistributedAckPersistentRegionCCEOffHeapDUnitTest.testConcurrentEventsOnEmptyRegion:
1 failures (99.93390614672836% success rate)
org.apache.geode.cache30.DistributedNoAckRegionCCEDUnitTest.testConcurrentEventsOnEmptyRegion:
1 failures (99.93390614672836% success rate)
org.apache.geode.cache30.DistributedNoAckRegionCCEOffHeapDUnitTest.testConcurrentEventsOnEmptyRegion:
1 failures (99.93390614672836% success rate)
org.apache.geode.distributed.SystemAdminDUnitTest.testPrintStacks: 1 failures
(99.93390614672836% success rate)
org.apache.geode.internal.cache.DeprecatedCacheServerLauncherIntegrationTest.testCreateBuckets:
1 failures (99.93390614672836% success rate)
org.apache.geode.internal.cache.PartitionedRegionSingleHopDUnitTest.testMetadataIsSameOnAllServersAndClients:
1 failures (99.93390614672836% success rate)
org.apache.geode.internal.cache.partitioned.PersistentPartitionedRegionDistributedTest.recoversFromCloseDuringRegionOperation:
15 failures (99.00859220092532% success rate)
org.apache.geode.internal.cache.partitioned.fixed.FixedPartitioningDUnitTest.testBug43283:
97 failures (93.58889623265037% success rate)
org.apache.geode.internal.cache.persistence.PersistentRecoveryOrderDUnitTest.testCrashDuringPreparePersistentId:
36 failures (97.62062128222075% success rate)
org.apache.geode.internal.cache.persistence.PersistentRecoveryOrderOldConfigDUnitTest.testCrashDuringPreparePersistentId:
30 failures (98.01718440185063% success rate)
org.apache.geode.internal.cache.wan.asyncqueue.AsyncEventQueueStatsDUnitTest.testAsyncStatsTwoListeners:
82 failures (94.58030403172505% success rate)
org.apache.geode.management.WANManagementDUnitTest.testReceiverMBean: 1
failures (99.93390614672836% success rate)
org.apache.geode.management.internal.cli.commands.DurableClientCommandsDUnitTest.testCloseDurableCQ:
2 failures (99.86781229345671% success rate)
org.apache.geode.management.internal.cli.commands.DurableClientCommandsDUnitTest.testCloseDurableClients:
1 failures (99.93390614672836% success rate)
org.apache.geode.management.internal.cli.commands.GemfireDataCommandsDUnitTest.testRebalanceCommandForSimulateWithNoMember:
1 failures (99.93390614672836% success rate)
org.apache.geode.management.internal.cli.commands.GemfireDataCommandsDUnitTest.testRebalanceCommandForTimeOutForRegion:
1 failures (99.93390614672836% success rate)
org.apache.geode.management.internal.cli.commands.GemfireDataCommandsDUnitTest.testRegionsViaMbeanAndFunctions:
3 failures (99.80171844018506% success rate)
org.apache.geode.management.internal.cli.commands.GemfireDataCommandsDUnitTest.testSimulateForEntireDS:
1 failures (99.93390614672836% success rate)
org.apache.geode.management.internal.cli.commands.GemfireDataCommandsDUnitTest.testSimulateForEntireDSWithTimeout:
1 failures (99.93390614672836% success rate)
org.apache.geode.management.internal.cli.commands.LauncherLifecycleCommandsDUnitTest.test014GemFireServerJvmProcessTerminatesOnOutOfMemoryError:
40 failures (97.35624586913417% success rate)
org.apache.geode.management.internal.cli.commands.LauncherLifecycleCommandsDUnitTest.testVersionTitleForStartServerAndLocator:
2 failures (99.86781229345671% success rate)
org.apache.geode.management.internal.cli.commands.RebalanceCommandOverHttpDistributedTest.testSimulateForEntireDSWithTimeout:
1 failures (99.93390614672836% success rate)
org.apache.geode.redis.HashesJUnitTest.testHIncrBy: 4 failures
(99.73562458691342% success rate)
org.apache.geode.security.ClientPostAuthorizationDUnitTest.testAllOpsNotifications:
6 failures (99.60343688037013% success rate)
{noformat}
was (Author: prhomberg):
Running over the weekend, the {{FlakyTest}} precheckin target was run 1513
times. The results as aggregated by the {{concourse-job-performance.py}}
script used by the metrics pipeline yields the following:
{noformat}
org.apache.geode.internal.cache.wan.asyncqueue.AsyncEventQueueStatsDUnitTest.testAsyncStatsTwoListeners:
82 failures (94.58030403172505% success rate)
org.apache.geode.internal.cache.partitioned.fixed.FixedPartitioningDUnitTest.testBug43283:
97 failures (93.58889623265037% success rate)
org.apache.geode.internal.cache.partitioned.PersistentPartitionedRegionDistributedTest.recoversFromCloseDuringRegionOperation:
15 failures (99.00859220092532% success rate)
org.apache.geode.internal.cache.persistence.PersistentRecoveryOrderDUnitTest.testCras
[jira] [Commented] (GEODE-5371) Ensure all tests marked as Flaky have not been resolved and still are accurately tagged
[
https://issues.apache.org/jira/browse/GEODE-5371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16537625#comment-16537625
]
Patrick Rhomberg commented on GEODE-5371:
-
Alternatively, ordered by failure rate:
{noformat}
org.apache.geode.internal.cache.partitioned.fixed.FixedPartitioningDUnitTest.testBug43283:
97 failures (93.58889623265037% success rate)
org.apache.geode.internal.cache.wan.asyncqueue.AsyncEventQueueStatsDUnitTest.testAsyncStatsTwoListeners:
82 failures (94.58030403172505% success rate)
org.apache.geode.management.internal.cli.commands.LauncherLifecycleCommandsDUnitTest.test014GemFireServerJvmProcessTerminatesOnOutOfMemoryError:
40 failures (97.35624586913417% success rate)
org.apache.geode.internal.cache.persistence.PersistentRecoveryOrderDUnitTest.testCrashDuringPreparePersistentId:
36 failures (97.62062128222075% success rate)
org.apache.geode.internal.cache.persistence.PersistentRecoveryOrderOldConfigDUnitTest.testCrashDuringPreparePersistentId:
30 failures (98.01718440185063% success rate)
org.apache.geode.internal.cache.partitioned.PersistentPartitionedRegionDistributedTest.recoversFromCloseDuringRegionOperation:
15 failures (99.00859220092532% success rate)
org.apache.geode.security.ClientPostAuthorizationDUnitTest.testAllOpsNotifications:
6 failures (99.60343688037013% success rate)
org.apache.geode.redis.HashesJUnitTest.testHIncrBy: 4 failures
(99.73562458691342% success rate)
org.apache.geode.management.internal.cli.commands.GemfireDataCommandsDUnitTest.testRegionsViaMbeanAndFunctions:
3 failures (99.80171844018506% success rate)
org.apache.geode.management.internal.cli.commands.LauncherLifecycleCommandsDUnitTest.testVersionTitleForStartServerAndLocator:
2 failures (99.86781229345671% success rate)
org.apache.geode.management.internal.cli.commands.DurableClientCommandsDUnitTest.testCloseDurableCQ:
2 failures (99.86781229345671% success rate)
org.apache.geode.cache30.DistributedAckPersistentRegionCCEOffHeapDUnitTest.testConcurrentEventsOnEmptyRegion:
1 failures (99.93390614672836% success rate)
org.apache.geode.cache30.DistributedNoAckRegionCCEDUnitTest.testConcurrentEventsOnEmptyRegion:
1 failures (99.93390614672836% success rate)
org.apache.geode.cache30.DistributedNoAckRegionCCEOffHeapDUnitTest.testConcurrentEventsOnEmptyRegion:
1 failures (99.93390614672836% success rate)
org.apache.geode.distributed.SystemAdminDUnitTest.testPrintStacks: 1 failures
(99.93390614672836% success rate)
org.apache.geode.internal.cache.DeprecatedCacheServerLauncherIntegrationTest.testCreateBuckets:
1 failures (99.93390614672836% success rate)
org.apache.geode.internal.cache.PartitionedRegionSingleHopDUnitTest.testMetadataIsSameOnAllServersAndClients:
1 failures (99.93390614672836% success rate)
org.apache.geode.management.WANManagementDUnitTest.testReceiverMBean: 1
failures (99.93390614672836% success rate)
org.apache.geode.management.internal.cli.commands.DurableClientCommandsDUnitTest.testCloseDurableClients:
1 failures (99.93390614672836% success rate)
org.apache.geode.management.internal.cli.commands.GemfireDataCommandsDUnitTest.testRebalanceCommandForSimulateWithNoMember:
1 failures (99.93390614672836% success rate)
org.apache.geode.management.internal.cli.commands.GemfireDataCommandsDUnitTest.testRebalanceCommandForTimeOutForRegion:
1 failures (99.93390614672836% success rate)
org.apache.geode.management.internal.cli.commands.GemfireDataCommandsDUnitTest.testSimulateForEntireDS:
1 failures (99.93390614672836% success rate)
org.apache.geode.management.internal.cli.commands.GemfireDataCommandsDUnitTest.testSimulateForEntireDSWithTimeout:
1 failures (99.93390614672836% success rate)
org.apache.geode.management.internal.cli.commands.RebalanceCommandOverHttpDistributedTest.testSimulateForEntireDSWithTimeout:
1 failures (99.93390614672836% success rate)
{noformat}
> Ensure all tests marked as Flaky have not been resolved and still are
> accurately tagged
> ---
>
> Key: GEODE-5371
> URL: https://issues.apache.org/jira/browse/GEODE-5371
> Project: Geode
> Issue Type: Task
>Reporter: Alexander Murmann
>Assignee: Patrick Rhomberg
>Priority: Major
> Labels: swat
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-567) CI Failure: FixedPartitioningDUnitTest.testBug43283
[
https://issues.apache.org/jira/browse/GEODE-567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16537629#comment-16537629
]
Patrick Rhomberg commented on GEODE-567:
>From GEODE-5371, out of ~1,500 runs:
{{org.apache.geode.internal.cache.partitioned.fixed.FixedPartitioningDUnitTest.testBug43283:
97 failures (93.58889623265037% success rate)}}
> CI Failure: FixedPartitioningDUnitTest.testBug43283
> ---
>
> Key: GEODE-567
> URL: https://issues.apache.org/jira/browse/GEODE-567
> Project: Geode
> Issue Type: Bug
> Components: regions
>Reporter: Barry Oglesby
>Priority: Major
> Labels: CI, Flaky, swat
>
> Geode_develop_DistributedTests
> Private Build #571 (Nov 14, 2015 7:09:09 AM)
> Revision: 88da702593157d8a0c014295cab16149fc088dfc
> {noformat}
> junit.framework.AssertionFailedError: exception thrown is not
> PartitionNotAvailableException
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.TestCase.fail(TestCase.java:227)
> at
> com.gemstone.gemfire.internal.cache.partitioned.fixed.FixedPartitioningDUnitTest.testBug43283(FixedPartitioningDUnitTest.java:545)
> {noformat}
> Standard Output shows:
> {noformat}
> Previously run tests: [ReliableMessagingDUnitTest,
> CacheServerTransactionsDUnitTest, ForceInvalidateOffHeapEvictionDUnitTest,
> UnregisterInterestDUnitTest, InterestRegrListenerDUnitTest,
> EventIDVerificationDUnitTest, DataSerializerPropogationDUnitTest,
> CacheServerTransactionsSelectorDUnitTest, Bug36805DUnitTest,
> PersistentColocatedPartitionedRegionDUnitTest, Bug51400DUnitTest,
> PersistPRKRFDUnitTest, StreamingPartitionOperationOneDUnitTest,
> Bug47388DUnitTest, PartitionedRegionMetaDataCleanupDUnitTest,
> PersistentPartitionedRegionOldConfigDUnitTest,
> PartitionedRegionLoaderWriterDUnitTest, ElidedPutAllDUnitTest,
> ShutdownAllDUnitTest, Bug39356DUnitTest, PartitionResolverDUnitTest,
> Bug43684DUnitTest, StreamingPartitionOperationManyDUnitTest,
> PersistentPartitionedRegionWithTransactionDUnitTest,
> PersistentPartitionedRegionDUnitTest,
> FixedPartitioningWithColocationAndPersistenceDUnitTest,
> FixedPartitioningDUnitTest]
> {noformat}
> Standard Error shows:
> {noformat}
> dunit.RMIException: While invoking
> com.gemstone.gemfire.internal.cache.partitioned.fixed.FixedPartitioningTestBase.putThorughAccessor_Immediate
> in VM 3 running on Host cc4-rh6.gemstone.com with 4 VMs
> at dunit.VM.invoke(VM.java:170)
> at
> com.gemstone.gemfire.internal.cache.partitioned.fixed.FixedPartitioningDUnitTest.testBug43283(FixedPartitioningDUnitTest.java:539)
> 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:497)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at junit.framework.TestCase.runBare(TestCase.java:141)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at junit.framework.TestSuite.runTest(TestSuite.java:252)
> at junit.framework.TestSuite.run(TestSuite.java:247)
> at
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:105)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:64)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50)
> at sun.reflect.GeneratedMethodAccessor169.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
> at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>
[jira] [Commented] (GEODE-5097) CI Failure: AsyncEventQueueStatsDUnitTest.testAsyncStatsTwoListeners
[
https://issues.apache.org/jira/browse/GEODE-5097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16537635#comment-16537635
]
Patrick Rhomberg commented on GEODE-5097:
-
See GEODE-5371, over ~1500 runs:
{{org.apache.geode.internal.cache.wan.asyncqueue.AsyncEventQueueStatsDUnitTest.testAsyncStatsTwoListeners:
82 failures (94.58030403172505% success rate)}}
> CI Failure: AsyncEventQueueStatsDUnitTest.testAsyncStatsTwoListeners
>
>
> Key: GEODE-5097
> URL: https://issues.apache.org/jira/browse/GEODE-5097
> Project: Geode
> Issue Type: Bug
>Reporter: Barry Oglesby
>Priority: Major
> Labels: swat
>
> Occurred in FlakyTest 434:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/FlakyTest/builds/434
> {noformat}
> org.apache.geode.internal.cache.wan.asyncqueue.AsyncEventQueueStatsDUnitTest
> > testAsyncStatsTwoListeners FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.wan.asyncqueue.AsyncEventQueueStatsDUnitTest$$Lambda$79/2036409943.run
> in VM 2 running on Host 5f4c74fb-2dca-48a0-4b2c-156d54846ff4 with 5 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:436)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:405)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:348)
> at
> org.apache.geode.internal.cache.wan.asyncqueue.AsyncEventQueueStatsDUnitTest.testAsyncStatsTwoListeners(AsyncEventQueueStatsDUnitTest.java:139)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Condition defined as a lambda
> expression in org.apache.geode.internal.cache.wan.AsyncEventQueueTestBase
> that uses int,
> intorg.apache.geode.cache.asyncqueue.internal.AsyncEventQueueStats Expected
> queue entries: 1000 but actual entries: 999 expected:<1000> but was:<999>
> within 120 seconds.
> at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:104)
> at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:117)
> at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
> at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:809)
> at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:648)
> at
> org.apache.geode.internal.cache.wan.AsyncEventQueueTestBase.checkAsyncEventQueueStats(AsyncEventQueueTestBase.java:735)
> at org.apache.geode.internal.cache.wan.asyncqueue.AsyncEventQueueStatsDUni
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-1866) LauncherLifecycleCommandsDUnitTest.test014GemFireServerJvmProcessTerminatesOnOutOfMemoryError
[
https://issues.apache.org/jira/browse/GEODE-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg updated GEODE-1866:
Labels: CI flaky swat (was: CI flaky)
> LauncherLifecycleCommandsDUnitTest.test014GemFireServerJvmProcessTerminatesOnOutOfMemoryError
> -
>
> Key: GEODE-1866
> URL: https://issues.apache.org/jira/browse/GEODE-1866
> Project: Geode
> Issue Type: Bug
> Components: management
>Reporter: xiaojian zhou
>Priority: Major
> Labels: CI, flaky, swat
> Fix For: 1.0.0-incubating
>
>
> {noformat}
> Geode_develop_DistributedTests 3832
> one of failures is:
> com.gemstone.gemfire.management.internal.cli.commands.LauncherLifecycleCommandsDUnitTest
> > test006StartLocatorInRelativeDirectory FAILED
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at
> com.gemstone.gemfire.management.internal.cli.commands.LauncherLifecycleCommandsDUnitTest.readPid(LauncherLifecycleCommandsDUnitTest.java:175)
> at
> com.gemstone.gemfire.management.internal.cli.commands.LauncherLifecycleCommandsDUnitTest.waitForGemFireProcessToStop(LauncherLifecycleCommandsDUnitTest.java:240)
> at
> com.gemstone.gemfire.management.internal.cli.commands.LauncherLifecycleCommandsDUnitTest.stopLocator(LauncherLifecycleCommandsDUnitTest.java:210)
> at
> com.gemstone.gemfire.management.internal.cli.commands.LauncherLifecycleCommandsDUnitTest.stopLocator(LauncherLifecycleCommandsDUnitTest.java:206)
> at
> com.gemstone.gemfire.management.internal.cli.commands.LauncherLifecycleCommandsDUnitTest.test006StartLocatorInRelativeDirectory(LauncherLifecycleCommandsDUnitTest.java:492)
> [noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-1866) LauncherLifecycleCommandsDUnitTest.test014GemFireServerJvmProcessTerminatesOnOutOfMemoryError
[
https://issues.apache.org/jira/browse/GEODE-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16537643#comment-16537643
]
Patrick Rhomberg commented on GEODE-1866:
-
See GEODE-5371, over ~1500 runs:
{{org.apache.geode.management.internal.cli.commands.LauncherLifecycleCommandsDUnitTest.test014GemFireServerJvmProcessTerminatesOnOutOfMemoryError:
40 failures (97.35624586913417% success rate)}}
> LauncherLifecycleCommandsDUnitTest.test014GemFireServerJvmProcessTerminatesOnOutOfMemoryError
> -
>
> Key: GEODE-1866
> URL: https://issues.apache.org/jira/browse/GEODE-1866
> Project: Geode
> Issue Type: Bug
> Components: management
>Reporter: xiaojian zhou
>Priority: Major
> Labels: CI, flaky, swat
> Fix For: 1.0.0-incubating
>
>
> {noformat}
> Geode_develop_DistributedTests 3832
> one of failures is:
> com.gemstone.gemfire.management.internal.cli.commands.LauncherLifecycleCommandsDUnitTest
> > test006StartLocatorInRelativeDirectory FAILED
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at
> com.gemstone.gemfire.management.internal.cli.commands.LauncherLifecycleCommandsDUnitTest.readPid(LauncherLifecycleCommandsDUnitTest.java:175)
> at
> com.gemstone.gemfire.management.internal.cli.commands.LauncherLifecycleCommandsDUnitTest.waitForGemFireProcessToStop(LauncherLifecycleCommandsDUnitTest.java:240)
> at
> com.gemstone.gemfire.management.internal.cli.commands.LauncherLifecycleCommandsDUnitTest.stopLocator(LauncherLifecycleCommandsDUnitTest.java:210)
> at
> com.gemstone.gemfire.management.internal.cli.commands.LauncherLifecycleCommandsDUnitTest.stopLocator(LauncherLifecycleCommandsDUnitTest.java:206)
> at
> com.gemstone.gemfire.management.internal.cli.commands.LauncherLifecycleCommandsDUnitTest.test006StartLocatorInRelativeDirectory(LauncherLifecycleCommandsDUnitTest.java:492)
> [noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-1703) CI failure: PersistentRecoveryOrderDUnitTest.testCrashDuringPreparePersistentId fails assertion: Region not created within30000
[
https://issues.apache.org/jira/browse/GEODE-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg updated GEODE-1703:
Labels: CI flaky swat (was: CI flaky)
> CI failure:
> PersistentRecoveryOrderDUnitTest.testCrashDuringPreparePersistentId fails
> assertion: Region not created within3
> ---
>
> Key: GEODE-1703
> URL: https://issues.apache.org/jira/browse/GEODE-1703
> Project: Geode
> Issue Type: Bug
> Components: regions, tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Minor
> Labels: CI, flaky, swat
>
> {noformat}
> :geode-core:distributedTest
> com.gemstone.gemfire.internal.cache.persistence.PersistentRecoveryOrderDUnitTest
> > testCrashDuringPreparePersistentId FAILED
> java.lang.AssertionError: Region not created within3
> at org.junit.Assert.fail(Assert.java:88)
> at
> com.gemstone.gemfire.internal.cache.persistence.PersistentReplicatedTestBase._createPersistentRegion(PersistentReplicatedTestBase.java:179)
> at
> com.gemstone.gemfire.internal.cache.persistence.PersistentReplicatedTestBase.createPersistentRegion(PersistentReplicatedTestBase.java:172)
> at
> com.gemstone.gemfire.internal.cache.persistence.PersistentRecoveryOrderDUnitTest.testCrashDuringPreparePersistentId(PersistentRecoveryOrderDUnitTest.java:1344)
> 7429 tests completed, 1 failed, 587 skipped
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-1703) CI failure: PersistentRecoveryOrderDUnitTest.testCrashDuringPreparePersistentId fails assertion: Region not created within30000
[
https://issues.apache.org/jira/browse/GEODE-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16537653#comment-16537653
]
Patrick Rhomberg commented on GEODE-1703:
-
See GEODE-5371, over ~1500 runs:
{noformat}
org.apache.geode.internal.cache.persistence.PersistentRecoveryOrderDUnitTest.testCrashDuringPreparePersistentId:
36 failures (97.62062128222075% success rate)
org.apache.geode.internal.cache.persistence.PersistentRecoveryOrderOldConfigDUnitTest.testCrashDuringPreparePersistentId:
30 failures (98.01718440185063% success rate)
{noformat}
> CI failure:
> PersistentRecoveryOrderDUnitTest.testCrashDuringPreparePersistentId fails
> assertion: Region not created within3
> ---
>
> Key: GEODE-1703
> URL: https://issues.apache.org/jira/browse/GEODE-1703
> Project: Geode
> Issue Type: Bug
> Components: regions, tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Minor
> Labels: CI, flaky, swat
>
> {noformat}
> :geode-core:distributedTest
> com.gemstone.gemfire.internal.cache.persistence.PersistentRecoveryOrderDUnitTest
> > testCrashDuringPreparePersistentId FAILED
> java.lang.AssertionError: Region not created within3
> at org.junit.Assert.fail(Assert.java:88)
> at
> com.gemstone.gemfire.internal.cache.persistence.PersistentReplicatedTestBase._createPersistentRegion(PersistentReplicatedTestBase.java:179)
> at
> com.gemstone.gemfire.internal.cache.persistence.PersistentReplicatedTestBase.createPersistentRegion(PersistentReplicatedTestBase.java:172)
> at
> com.gemstone.gemfire.internal.cache.persistence.PersistentRecoveryOrderDUnitTest.testCrashDuringPreparePersistentId(PersistentRecoveryOrderDUnitTest.java:1344)
> 7429 tests completed, 1 failed, 587 skipped
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5325) CI failure: PersistentPartitionedRegionDistributedTest.recoversFromCloseDuringRegionOperation fails intermittently
[
https://issues.apache.org/jira/browse/GEODE-5325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg updated GEODE-5325:
Labels: CI Flaky swat (was: CI Flaky)
> CI failure:
> PersistentPartitionedRegionDistributedTest.recoversFromCloseDuringRegionOperation
> fails intermittently
> --
>
> Key: GEODE-5325
> URL: https://issues.apache.org/jira/browse/GEODE-5325
> Project: Geode
> Issue Type: Bug
> Components: persistence
>Affects Versions: 1.7.0
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Minor
> Labels: CI, Flaky, swat
>
> {noformat}
> org.apache.geode.internal.cache.partitioned.PersistentPartitionedRegionDistributedTest
> > recoversFromCloseDuringRegionOperation FAILED
> java.lang.AssertionError: An exception occurred during asynchronous
> invocation.
> at
> org.apache.geode.test.dunit.AsyncInvocation.checkException(AsyncInvocation.java:150)
> at
> org.apache.geode.test.dunit.AsyncInvocation.get(AsyncInvocation.java:424)
> at
> org.apache.geode.test.dunit.AsyncInvocation.get(AsyncInvocation.java:393)
> at
> org.apache.geode.internal.cache.partitioned.PersistentPartitionedRegionDistributedTest.recoversFromCloseDuringRegionOperation(PersistentPartitionedRegionDistributedTest.java:999)
> Caused by:
> org.apache.geode.distributed.DistributedSystemDisconnectedException:
> Distribution manager on 172.17.0.4(172):32770 started at Wed Jun 13
> 23:12:28 UTC 2018: Message distribution has terminated
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$Stopper.generateCancelledException(ClusterDistributionManager.java:4556)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Stopper.generateCancelledException(InternalDistributedSystem.java:962)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl$Stopper.generateCancelledException(GemFireCacheImpl.java:1556)
> at
> org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
> at
> org.apache.geode.internal.cache.LocalRegion.checkRegionDestroyed(LocalRegion.java:7419)
> at
> org.apache.geode.internal.cache.LocalRegion.checkReadiness(LocalRegion.java:2735)
> at
> org.apache.geode.internal.cache.PartitionedRegion.checkShutdown(PartitionedRegion.java:1745)
> at
> org.apache.geode.internal.cache.PartitionedRegion.putInBucket(PartitionedRegion.java:2972)
> at
> org.apache.geode.internal.cache.PartitionedRegion.virtualPut(PartitionedRegion.java:2091)
> at
> org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:152)
> at
> org.apache.geode.internal.cache.LocalRegion.basicPut(LocalRegion.java:5086)
> at
> org.apache.geode.internal.cache.LocalRegion.validatedPut(LocalRegion.java:1618)
> at
> org.apache.geode.internal.cache.LocalRegion.put(LocalRegion.java:1605)
> at
> org.apache.geode.internal.cache.AbstractRegion.put(AbstractRegion.java:413)
> at
> org.apache.geode.internal.cache.partitioned.PersistentPartitionedRegionDistributedTest.lambda$recoversFromCloseDuringRegionOperation$1509c1f8$1(PersistentPartitionedRegionDistributedTest.java:969)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5325) CI failure: PersistentPartitionedRegionDistributedTest.recoversFromCloseDuringRegionOperation fails intermittently
[
https://issues.apache.org/jira/browse/GEODE-5325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16537655#comment-16537655
]
Patrick Rhomberg commented on GEODE-5325:
-
See GEODE-5371, over ~1500 runs:
{{org.apache.geode.internal.cache.partitioned.PersistentPartitionedRegionDistributedTest.recoversFromCloseDuringRegionOperation:
15 failures (99.00859220092532% success rate)}}
> CI failure:
> PersistentPartitionedRegionDistributedTest.recoversFromCloseDuringRegionOperation
> fails intermittently
> --
>
> Key: GEODE-5325
> URL: https://issues.apache.org/jira/browse/GEODE-5325
> Project: Geode
> Issue Type: Bug
> Components: persistence
>Affects Versions: 1.7.0
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Minor
> Labels: CI, Flaky, swat
>
> {noformat}
> org.apache.geode.internal.cache.partitioned.PersistentPartitionedRegionDistributedTest
> > recoversFromCloseDuringRegionOperation FAILED
> java.lang.AssertionError: An exception occurred during asynchronous
> invocation.
> at
> org.apache.geode.test.dunit.AsyncInvocation.checkException(AsyncInvocation.java:150)
> at
> org.apache.geode.test.dunit.AsyncInvocation.get(AsyncInvocation.java:424)
> at
> org.apache.geode.test.dunit.AsyncInvocation.get(AsyncInvocation.java:393)
> at
> org.apache.geode.internal.cache.partitioned.PersistentPartitionedRegionDistributedTest.recoversFromCloseDuringRegionOperation(PersistentPartitionedRegionDistributedTest.java:999)
> Caused by:
> org.apache.geode.distributed.DistributedSystemDisconnectedException:
> Distribution manager on 172.17.0.4(172):32770 started at Wed Jun 13
> 23:12:28 UTC 2018: Message distribution has terminated
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$Stopper.generateCancelledException(ClusterDistributionManager.java:4556)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Stopper.generateCancelledException(InternalDistributedSystem.java:962)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl$Stopper.generateCancelledException(GemFireCacheImpl.java:1556)
> at
> org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
> at
> org.apache.geode.internal.cache.LocalRegion.checkRegionDestroyed(LocalRegion.java:7419)
> at
> org.apache.geode.internal.cache.LocalRegion.checkReadiness(LocalRegion.java:2735)
> at
> org.apache.geode.internal.cache.PartitionedRegion.checkShutdown(PartitionedRegion.java:1745)
> at
> org.apache.geode.internal.cache.PartitionedRegion.putInBucket(PartitionedRegion.java:2972)
> at
> org.apache.geode.internal.cache.PartitionedRegion.virtualPut(PartitionedRegion.java:2091)
> at
> org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:152)
> at
> org.apache.geode.internal.cache.LocalRegion.basicPut(LocalRegion.java:5086)
> at
> org.apache.geode.internal.cache.LocalRegion.validatedPut(LocalRegion.java:1618)
> at
> org.apache.geode.internal.cache.LocalRegion.put(LocalRegion.java:1605)
> at
> org.apache.geode.internal.cache.AbstractRegion.put(AbstractRegion.java:413)
> at
> org.apache.geode.internal.cache.partitioned.PersistentPartitionedRegionDistributedTest.lambda$recoversFromCloseDuringRegionOperation$1509c1f8$1(PersistentPartitionedRegionDistributedTest.java:969)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-3451) Data inconsistency detected in distributed ack test on empty region
[
https://issues.apache.org/jira/browse/GEODE-3451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16537712#comment-16537712
]
Patrick Rhomberg commented on GEODE-3451:
-
This intermittently fails across all children of the parent test class.
See GEODE-5317, over ~1500 runs:
{noformat}
org.apache.geode.cache30.DistributedAckPersistentRegionCCEOffHeapDUnitTest.testConcurrentEventsOnEmptyRegion:
1 failures (99.93390614672836% success rate)
org.apache.geode.cache30.DistributedNoAckRegionCCEDUnitTest.testConcurrentEventsOnEmptyRegion:
1 failures (99.93390614672836% success rate)
org.apache.geode.cache30.DistributedNoAckRegionCCEOffHeapDUnitTest.testConcurrentEventsOnEmptyRegion:
1 failures (99.93390614672836% success rate)
{noformat}
> Data inconsistency detected in distributed ack test on empty region
> ---
>
> Key: GEODE-3451
> URL: https://issues.apache.org/jira/browse/GEODE-3451
> Project: Geode
> Issue Type: Bug
> Components: regions
>Reporter: Nick Reich
>Priority: Major
> Labels: ci, flaky, swat
>
> {noformat}
> org.apache.geode.cache30.DistributedAckRegionCCEOffHeapDUnitTest >
> testConcurrentEventsOnEmptyRegion FAILED
> org.junit.ComparisonFailure: region contents are not consistent for
> cckey8 expected: but was:
> {noformat}
> Note: test failure was not readily reproduced
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-3451) Data inconsistency detected in distributed ack test on empty region
[
https://issues.apache.org/jira/browse/GEODE-3451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg updated GEODE-3451:
Labels: ci flaky swat (was: ci flaky)
> Data inconsistency detected in distributed ack test on empty region
> ---
>
> Key: GEODE-3451
> URL: https://issues.apache.org/jira/browse/GEODE-3451
> Project: Geode
> Issue Type: Bug
> Components: regions
>Reporter: Nick Reich
>Priority: Major
> Labels: ci, flaky, swat
>
> {noformat}
> org.apache.geode.cache30.DistributedAckRegionCCEOffHeapDUnitTest >
> testConcurrentEventsOnEmptyRegion FAILED
> org.junit.ComparisonFailure: region contents are not consistent for
> cckey8 expected: but was:
> {noformat}
> Note: test failure was not readily reproduced
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Reopened] (GEODE-1009) CI Failure: ClientPostAuthorizationDUnitTest.testAllOpsNotifications
[
https://issues.apache.org/jira/browse/GEODE-1009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg reopened GEODE-1009:
-
See GEODE-5317, over ~1500 runs
{{org.apache.geode.security.ClientPostAuthorizationDUnitTest.testAllOpsNotifications:
6 failures (99.60343688037013% success rate)}}
> CI Failure: ClientPostAuthorizationDUnitTest.testAllOpsNotifications
>
>
> Key: GEODE-1009
> URL: https://issues.apache.org/jira/browse/GEODE-1009
> Project: Geode
> Issue Type: Bug
> Components: security
>Reporter: Dan Smith
>Priority: Major
> Labels: Flaky
>
> {noformat}
> java.lang.AssertionError: Event never occurred after 12000 ms: null
> at org.junit.Assert.fail(Assert.java:88)
> at com.gemstone.gemfire.test.dunit.Wait.waitForCriterion(Wait.java:119)
> at
> com.gemstone.gemfire.security.SecurityTestUtil.waitForCondition(SecurityTestUtil.java:728)
> at
> com.gemstone.gemfire.security.SecurityTestUtil.waitForCondition(SecurityTestUtil.java:709)
> at
> com.gemstone.gemfire.security.ClientAuthorizationTestBase.doOp(ClientAuthorizationTestBase.java:351)
> at
> com.gemstone.gemfire.security.ClientAuthorizationTestBase.executeOpBlock(ClientAuthorizationTestBase.java:797)
> at
> com.gemstone.gemfire.security.ClientPostAuthorizationDUnitTest.testAllOpsNotifications(ClientPostAuthorizationDUnitTest.java:357)
> 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:497)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at junit.framework.TestCase.runBare(TestCase.java:141)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at junit.framework.TestSuite.runTest(TestSuite.java:252)
> at junit.framework.TestSuite.run(TestSuite.java:247)
> at
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:105)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:64)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50)
> at sun.reflect.GeneratedMethodAccessor326.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.messaging.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:106)
> at sun.reflect.GeneratedMethodAccessor325.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.messaging.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:360)
> at
> org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54)
> at
> org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:40)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Standard Output
> Previously run tests: [PRDeltaPropagationDUnitTest,
> RemoteCQTransactionDUnitTest, Put
[jira] [Updated] (GEODE-1009) CI Failure: ClientPostAuthorizationDUnitTest.testAllOpsNotifications
[
https://issues.apache.org/jira/browse/GEODE-1009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg updated GEODE-1009:
Labels: Flaky swat (was: Flaky)
> CI Failure: ClientPostAuthorizationDUnitTest.testAllOpsNotifications
>
>
> Key: GEODE-1009
> URL: https://issues.apache.org/jira/browse/GEODE-1009
> Project: Geode
> Issue Type: Bug
> Components: security
>Reporter: Dan Smith
>Priority: Major
> Labels: Flaky, swat
>
> {noformat}
> java.lang.AssertionError: Event never occurred after 12000 ms: null
> at org.junit.Assert.fail(Assert.java:88)
> at com.gemstone.gemfire.test.dunit.Wait.waitForCriterion(Wait.java:119)
> at
> com.gemstone.gemfire.security.SecurityTestUtil.waitForCondition(SecurityTestUtil.java:728)
> at
> com.gemstone.gemfire.security.SecurityTestUtil.waitForCondition(SecurityTestUtil.java:709)
> at
> com.gemstone.gemfire.security.ClientAuthorizationTestBase.doOp(ClientAuthorizationTestBase.java:351)
> at
> com.gemstone.gemfire.security.ClientAuthorizationTestBase.executeOpBlock(ClientAuthorizationTestBase.java:797)
> at
> com.gemstone.gemfire.security.ClientPostAuthorizationDUnitTest.testAllOpsNotifications(ClientPostAuthorizationDUnitTest.java:357)
> 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:497)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at junit.framework.TestCase.runBare(TestCase.java:141)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at junit.framework.TestSuite.runTest(TestSuite.java:252)
> at junit.framework.TestSuite.run(TestSuite.java:247)
> at
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:105)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:64)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50)
> at sun.reflect.GeneratedMethodAccessor326.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.messaging.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:106)
> at sun.reflect.GeneratedMethodAccessor325.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.messaging.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:360)
> at
> org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54)
> at
> org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:40)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Standard Output
> Previously run tests: [PRDeltaPropagationDUnitTest,
> RemoteCQTransactionDUnitTest, PutAllCSDUnitTest, HADispatcherDUnitTest,
> CQListGIIDUnitTest, DeltaPropagationWithCQDUnitTest,
> MultiuserDurableCQAuthzDUnitT
[jira] [Commented] (GEODE-1942) CI Failure: org.apache.geode.redis.HashesJUnitTest.testHIncrBy
[
https://issues.apache.org/jira/browse/GEODE-1942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16537729#comment-16537729
]
Patrick Rhomberg commented on GEODE-1942:
-
If Redis support is going to be removed, I suppose we could just remove these
tests... But as long as we're supporting it, I think we should get these tests
passing.
See GEODE-5317. Over ~1500 runs,
{{org.apache.geode.redis.HashesJUnitTest.testHIncrBy: 4 failures
(99.73562458691342% success rate)}}
> CI Failure: org.apache.geode.redis.HashesJUnitTest.testHIncrBy
> --
>
> Key: GEODE-1942
> URL: https://issues.apache.org/jira/browse/GEODE-1942
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Bruce Schuchardt
>Priority: Major
> Labels: CI, swat
>
> Error Message
> redis.clients.jedis.exceptions.JedisConnectionException:
> java.net.SocketTimeoutException: Read timed out
> Stacktrace
> redis.clients.jedis.exceptions.JedisConnectionException:
> java.net.SocketTimeoutException: Read timed out
> at
> redis.clients.util.RedisInputStream.ensureFill(RedisInputStream.java:201)
> at
> redis.clients.util.RedisInputStream.readByte(RedisInputStream.java:40)
> at redis.clients.jedis.Protocol.process(Protocol.java:132)
> at redis.clients.jedis.Protocol.read(Protocol.java:196)
> at
> redis.clients.jedis.Connection.readProtocolWithCheckingBroken(Connection.java:288)
> at redis.clients.jedis.Connection.getIntegerReply(Connection.java:213)
> at redis.clients.jedis.Jedis.hincrBy(Jedis.java:675)
> at
> org.apache.geode.redis.HashesJUnitTest.testHIncrBy(HashesJUnitTest.java:143)
> 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:497)
> 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.RunAfters.evaluate(RunAfters.java:27)
> 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.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.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:497)
> 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(TestWo
[jira] [Updated] (GEODE-1942) CI Failure: org.apache.geode.redis.HashesJUnitTest.testHIncrBy
[ https://issues.apache.org/jira/browse/GEODE-1942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg updated GEODE-1942: Labels: CI swat (was: CI) > CI Failure: org.apache.geode.redis.HashesJUnitTest.testHIncrBy > -- > > Key: GEODE-1942 > URL: https://issues.apache.org/jira/browse/GEODE-1942 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Bruce Schuchardt >Priority: Major > Labels: CI, swat > > Error Message > redis.clients.jedis.exceptions.JedisConnectionException: > java.net.SocketTimeoutException: Read timed out > Stacktrace > redis.clients.jedis.exceptions.JedisConnectionException: > java.net.SocketTimeoutException: Read timed out > at > redis.clients.util.RedisInputStream.ensureFill(RedisInputStream.java:201) > at > redis.clients.util.RedisInputStream.readByte(RedisInputStream.java:40) > at redis.clients.jedis.Protocol.process(Protocol.java:132) > at redis.clients.jedis.Protocol.read(Protocol.java:196) > at > redis.clients.jedis.Connection.readProtocolWithCheckingBroken(Connection.java:288) > at redis.clients.jedis.Connection.getIntegerReply(Connection.java:213) > at redis.clients.jedis.Jedis.hincrBy(Jedis.java:675) > at > org.apache.geode.redis.HashesJUnitTest.testHIncrBy(HashesJUnitTest.java:143) > 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:497) > 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.RunAfters.evaluate(RunAfters.java:27) > 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.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.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:497) > 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:109) > 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:
[jira] [Updated] (GEODE-577) QueryMonitorDUnitTest is flaky and needs to be rewritten (60 failures in 200)
[
https://issues.apache.org/jira/browse/GEODE-577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg updated GEODE-577:
---
Summary: QueryMonitorDUnitTest is flaky and needs to be rewritten (60
failures in 200) (was: QueryMonitorDUnitTest is flaky and needs to be
rewritten)
> QueryMonitorDUnitTest is flaky and needs to be rewritten (60 failures in 200)
> -
>
> Key: GEODE-577
> URL: https://issues.apache.org/jira/browse/GEODE-577
> Project: Geode
> Issue Type: Bug
> Components: querying
>Reporter: Barry Oglesby
>Priority: Major
> Labels: CI, Flaky, swat
> Fix For: 1.7.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> GemFire_develop_DistributedTests
> Private Build #38 (Nov 15, 2015 3:12:12 PM)
> Revision: b7f640cf2e41acb40a531cc7abbee932a9ea093c
> Revision: 88da702593157d8a0c014295cab16149fc088dfc
> Error Message
> {noformat}
> dunit.RMIException: While invoking
> com.gemstone.gemfire.cache.query.dunit.QueryMonitorDUnitTest$14.run in VM 1
> running on Host latvia.gemstone.com with 4 VMs
> {noformat}
> Stacktrace
> {noformat}
> dunit.RMIException: While invoking
> com.gemstone.gemfire.cache.query.dunit.QueryMonitorDUnitTest$14.run in VM 1
> running on Host latvia.gemstone.com with 4 VMs
> at dunit.VM.invoke(VM.java:369)
> at dunit.VM.invoke(VM.java:312)
> at dunit.VM.invoke(VM.java:266)
> at
> com.gemstone.gemfire.cache.query.dunit.QueryMonitorDUnitTest.testQueryExecutionLocally(QueryMonitorDUnitTest.java:493)
> 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:497)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at junit.framework.TestCase.runBare(TestCase.java:141)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at junit.framework.TestSuite.runTest(TestSuite.java:252)
> at junit.framework.TestSuite.run(TestSuite.java:247)
> at
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:105)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:64)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50)
> at sun.reflect.GeneratedMethodAccessor124.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.messaging.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:106)
> at sun.reflect.GeneratedMethodAccessor123.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.messaging.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:360)
> at
> org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54)
> at
> org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:40)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thr
[jira] [Created] (GEODE-5418) Many flaky tests in children of MultiVMRegionTestCase
Patrick Rhomberg created GEODE-5418:
---
Summary: Many flaky tests in children of MultiVMRegionTestCase
Key: GEODE-5418
URL: https://issues.apache.org/jira/browse/GEODE-5418
Project: Geode
Issue Type: Bug
Reporter: Patrick Rhomberg
When running DIstributedTest 200+ times, we observed that this group of tests
has many methods that are flaky
{noformat}
org.apache.geode.cache30.DiskDistributedNoAckAsyncOverflowRegionDUnitTest.testDistributedRegionDestroy:
1 failures (99.55947136563876% success rate)
org.apache.geode.cache30.DiskDistributedNoAckSyncOverflowRegionDUnitTest.testEntryIdleDestroy:
1 failures (99.55947136563876% success rate)
org.apache.geode.cache30.DistributedAckOverflowRegionCCEOffHeapDUnitTest.testClearWithConcurrentEventsAsync:
1 failures (99.55947136563876% success rate)
org.apache.geode.cache30.DistributedAckOverflowRegionCCEOffHeapDUnitTest.testConcurrentEventsOnNonReplicatedRegion:
2 failures (99.11894273127754% success rate)
org.apache.geode.cache30.DistributedAckPersistentRegionCCEDUnitTest.testClearWithConcurrentEvents:
1 failures (99.55947136563876% success rate)
org.apache.geode.cache30.DistributedAckPersistentRegionCCEOffHeapDUnitTest.testInvalidateEntry:
1 failures (99.55947136563876% success rate)
org.apache.geode.cache30.DistributedAckPersistentRegionCCEOffHeapDUnitTest.testNBRegionDestructionDuringGetInitialImage:
1 failures (99.55947136563876% success rate)
org.apache.geode.cache30.DistributedAckPersistentRegionCCEOffHeapDUnitTest.testNetSearchObservesIdleTime:
1 failures (99.55947136563876% success rate)
org.apache.geode.cache30.DistributedAckPersistentRegionCCEOffHeapDUnitTest.testNonblockingGetInitialImage:
2 failures (99.11894273127754% success rate)
org.apache.geode.cache30.DistributedAckPersistentRegionCCEOffHeapDUnitTest.testTombstones:
1 failures (99.55947136563876% success rate)
org.apache.geode.cache30.DistributedNoAckRegionCCEDUnitTest.testEntryIdleDestroy:
1 failures (99.55947136563876% success rate)
org.apache.geode.cache30.DistributedNoAckRegionCCEDUnitTest.testTXMultiRegion:
1 failures (99.55947136563876% success rate)
org.apache.geode.cache30.DistributedNoAckRegionCCEDUnitTest.testTXRmtMirror: 3
failures (98.6784140969163% success rate)
org.apache.geode.cache30.DistributedNoAckRegionCCEOffHeapDUnitTest.testConcurrentEventsOnNonReplicatedRegion:
2 failures (99.11894273127754% success rate)
org.apache.geode.cache30.DistributedNoAckRegionCCEOffHeapDUnitTest.testRegionIdleInvalidate:
1 failures (99.55947136563876% success rate)
org.apache.geode.cache30.DistributedNoAckRegionCCEOffHeapDUnitTest.testTXRmtMirror:
3 failures (98.6784140969163% success rate)
org.apache.geode.cache30.DistributedNoAckRegionCCEOffHeapDUnitTest.testTombstones:
1 failures (99.55947136563876% success rate)
org.apache.geode.cache30.DistributedNoAckRegionDUnitTest.testTXRmtMirror: 5
failures (97.79735682819384% success rate)
org.apache.geode.cache30.DistributedNoAckRegionOffHeapDUnitTest.testMirroredLocalLoad:
1 failures (99.55947136563876% success rate)
org.apache.geode.cache30.DistributedNoAckRegionOffHeapDUnitTest.testTXRmtMirror:
8 failures (96.47577092511013% success rate)
org.apache.geode.cache30.PartitionedRegionOffHeapDUnitTest.testDistributedUpdate:
7 failures (96.91629955947137% success rate)
{noformat}
Whoever picks this up can split these out if they are not related, but leaving
them as a single ticket here in case they have a common cause.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5418) Many flaky tests in children of MultiVMRegionTestCase
[
https://issues.apache.org/jira/browse/GEODE-5418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg updated GEODE-5418:
Labels: swat (was: )
> Many flaky tests in children of MultiVMRegionTestCase
> -
>
> Key: GEODE-5418
> URL: https://issues.apache.org/jira/browse/GEODE-5418
> Project: Geode
> Issue Type: Bug
>Reporter: Patrick Rhomberg
>Priority: Major
> Labels: swat
>
> When running DIstributedTest 200+ times, we observed that this group of tests
> has many methods that are flaky
> {noformat}
> org.apache.geode.cache30.DiskDistributedNoAckAsyncOverflowRegionDUnitTest.testDistributedRegionDestroy:
> 1 failures (99.55947136563876% success rate)
> org.apache.geode.cache30.DiskDistributedNoAckSyncOverflowRegionDUnitTest.testEntryIdleDestroy:
> 1 failures (99.55947136563876% success rate)
> org.apache.geode.cache30.DistributedAckOverflowRegionCCEOffHeapDUnitTest.testClearWithConcurrentEventsAsync:
> 1 failures (99.55947136563876% success rate)
> org.apache.geode.cache30.DistributedAckOverflowRegionCCEOffHeapDUnitTest.testConcurrentEventsOnNonReplicatedRegion:
> 2 failures (99.11894273127754% success rate)
> org.apache.geode.cache30.DistributedAckPersistentRegionCCEDUnitTest.testClearWithConcurrentEvents:
> 1 failures (99.55947136563876% success rate)
> org.apache.geode.cache30.DistributedAckPersistentRegionCCEOffHeapDUnitTest.testInvalidateEntry:
> 1 failures (99.55947136563876% success rate)
> org.apache.geode.cache30.DistributedAckPersistentRegionCCEOffHeapDUnitTest.testNBRegionDestructionDuringGetInitialImage:
> 1 failures (99.55947136563876% success rate)
> org.apache.geode.cache30.DistributedAckPersistentRegionCCEOffHeapDUnitTest.testNetSearchObservesIdleTime:
> 1 failures (99.55947136563876% success rate)
> org.apache.geode.cache30.DistributedAckPersistentRegionCCEOffHeapDUnitTest.testNonblockingGetInitialImage:
> 2 failures (99.11894273127754% success rate)
> org.apache.geode.cache30.DistributedAckPersistentRegionCCEOffHeapDUnitTest.testTombstones:
> 1 failures (99.55947136563876% success rate)
> org.apache.geode.cache30.DistributedNoAckRegionCCEDUnitTest.testEntryIdleDestroy:
> 1 failures (99.55947136563876% success rate)
> org.apache.geode.cache30.DistributedNoAckRegionCCEDUnitTest.testTXMultiRegion:
> 1 failures (99.55947136563876% success rate)
> org.apache.geode.cache30.DistributedNoAckRegionCCEDUnitTest.testTXRmtMirror:
> 3 failures (98.6784140969163% success rate)
> org.apache.geode.cache30.DistributedNoAckRegionCCEOffHeapDUnitTest.testConcurrentEventsOnNonReplicatedRegion:
> 2 failures (99.11894273127754% success rate)
> org.apache.geode.cache30.DistributedNoAckRegionCCEOffHeapDUnitTest.testRegionIdleInvalidate:
> 1 failures (99.55947136563876% success rate)
> org.apache.geode.cache30.DistributedNoAckRegionCCEOffHeapDUnitTest.testTXRmtMirror:
> 3 failures (98.6784140969163% success rate)
> org.apache.geode.cache30.DistributedNoAckRegionCCEOffHeapDUnitTest.testTombstones:
> 1 failures (99.55947136563876% success rate)
> org.apache.geode.cache30.DistributedNoAckRegionDUnitTest.testTXRmtMirror: 5
> failures (97.79735682819384% success rate)
> org.apache.geode.cache30.DistributedNoAckRegionOffHeapDUnitTest.testMirroredLocalLoad:
> 1 failures (99.55947136563876% success rate)
> org.apache.geode.cache30.DistributedNoAckRegionOffHeapDUnitTest.testTXRmtMirror:
> 8 failures (96.47577092511013% success rate)
> org.apache.geode.cache30.PartitionedRegionOffHeapDUnitTest.testDistributedUpdate:
> 7 failures (96.91629955947137% success rate)
> {noformat}
> Whoever picks this up can split these out if they are not related, but
> leaving them as a single ticket here in case they have a common cause.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5418) Many flaky tests in children of MultiVMRegionTestCase
[
https://issues.apache.org/jira/browse/GEODE-5418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg updated GEODE-5418:
Attachment: DistributedTest_metrics.txt
> Many flaky tests in children of MultiVMRegionTestCase
> -
>
> Key: GEODE-5418
> URL: https://issues.apache.org/jira/browse/GEODE-5418
> Project: Geode
> Issue Type: Bug
>Reporter: Patrick Rhomberg
>Priority: Major
> Labels: swat
> Attachments: DistributedTest_metrics.txt
>
>
> When running DIstributedTest 200+ times, we observed that this group of tests
> has many methods that are flaky
> {noformat}
> org.apache.geode.cache30.DiskDistributedNoAckAsyncOverflowRegionDUnitTest.testDistributedRegionDestroy:
> 1 failures (99.55947136563876% success rate)
> org.apache.geode.cache30.DiskDistributedNoAckSyncOverflowRegionDUnitTest.testEntryIdleDestroy:
> 1 failures (99.55947136563876% success rate)
> org.apache.geode.cache30.DistributedAckOverflowRegionCCEOffHeapDUnitTest.testClearWithConcurrentEventsAsync:
> 1 failures (99.55947136563876% success rate)
> org.apache.geode.cache30.DistributedAckOverflowRegionCCEOffHeapDUnitTest.testConcurrentEventsOnNonReplicatedRegion:
> 2 failures (99.11894273127754% success rate)
> org.apache.geode.cache30.DistributedAckPersistentRegionCCEDUnitTest.testClearWithConcurrentEvents:
> 1 failures (99.55947136563876% success rate)
> org.apache.geode.cache30.DistributedAckPersistentRegionCCEOffHeapDUnitTest.testInvalidateEntry:
> 1 failures (99.55947136563876% success rate)
> org.apache.geode.cache30.DistributedAckPersistentRegionCCEOffHeapDUnitTest.testNBRegionDestructionDuringGetInitialImage:
> 1 failures (99.55947136563876% success rate)
> org.apache.geode.cache30.DistributedAckPersistentRegionCCEOffHeapDUnitTest.testNetSearchObservesIdleTime:
> 1 failures (99.55947136563876% success rate)
> org.apache.geode.cache30.DistributedAckPersistentRegionCCEOffHeapDUnitTest.testNonblockingGetInitialImage:
> 2 failures (99.11894273127754% success rate)
> org.apache.geode.cache30.DistributedAckPersistentRegionCCEOffHeapDUnitTest.testTombstones:
> 1 failures (99.55947136563876% success rate)
> org.apache.geode.cache30.DistributedNoAckRegionCCEDUnitTest.testEntryIdleDestroy:
> 1 failures (99.55947136563876% success rate)
> org.apache.geode.cache30.DistributedNoAckRegionCCEDUnitTest.testTXMultiRegion:
> 1 failures (99.55947136563876% success rate)
> org.apache.geode.cache30.DistributedNoAckRegionCCEDUnitTest.testTXRmtMirror:
> 3 failures (98.6784140969163% success rate)
> org.apache.geode.cache30.DistributedNoAckRegionCCEOffHeapDUnitTest.testConcurrentEventsOnNonReplicatedRegion:
> 2 failures (99.11894273127754% success rate)
> org.apache.geode.cache30.DistributedNoAckRegionCCEOffHeapDUnitTest.testRegionIdleInvalidate:
> 1 failures (99.55947136563876% success rate)
> org.apache.geode.cache30.DistributedNoAckRegionCCEOffHeapDUnitTest.testTXRmtMirror:
> 3 failures (98.6784140969163% success rate)
> org.apache.geode.cache30.DistributedNoAckRegionCCEOffHeapDUnitTest.testTombstones:
> 1 failures (99.55947136563876% success rate)
> org.apache.geode.cache30.DistributedNoAckRegionDUnitTest.testTXRmtMirror: 5
> failures (97.79735682819384% success rate)
> org.apache.geode.cache30.DistributedNoAckRegionOffHeapDUnitTest.testMirroredLocalLoad:
> 1 failures (99.55947136563876% success rate)
> org.apache.geode.cache30.DistributedNoAckRegionOffHeapDUnitTest.testTXRmtMirror:
> 8 failures (96.47577092511013% success rate)
> org.apache.geode.cache30.PartitionedRegionOffHeapDUnitTest.testDistributedUpdate:
> 7 failures (96.91629955947137% success rate)
> {noformat}
> Whoever picks this up can split these out if they are not related, but
> leaving them as a single ticket here in case they have a common cause.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5418) Many flaky tests in children of MultiVMRegionTestCase
[
https://issues.apache.org/jira/browse/GEODE-5418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16540627#comment-16540627
]
Patrick Rhomberg commented on GEODE-5418:
-
Attached links to all of these failures. In order to view those links, you will
need to request access to the staging pipeline on d...@geode.apache.org.
> Many flaky tests in children of MultiVMRegionTestCase
> -
>
> Key: GEODE-5418
> URL: https://issues.apache.org/jira/browse/GEODE-5418
> Project: Geode
> Issue Type: Bug
>Reporter: Patrick Rhomberg
>Priority: Major
> Labels: swat
> Attachments: DistributedTest_metrics.txt
>
>
> When running DIstributedTest 200+ times, we observed that this group of tests
> has many methods that are flaky
> {noformat}
> org.apache.geode.cache30.DiskDistributedNoAckAsyncOverflowRegionDUnitTest.testDistributedRegionDestroy:
> 1 failures (99.55947136563876% success rate)
> org.apache.geode.cache30.DiskDistributedNoAckSyncOverflowRegionDUnitTest.testEntryIdleDestroy:
> 1 failures (99.55947136563876% success rate)
> org.apache.geode.cache30.DistributedAckOverflowRegionCCEOffHeapDUnitTest.testClearWithConcurrentEventsAsync:
> 1 failures (99.55947136563876% success rate)
> org.apache.geode.cache30.DistributedAckOverflowRegionCCEOffHeapDUnitTest.testConcurrentEventsOnNonReplicatedRegion:
> 2 failures (99.11894273127754% success rate)
> org.apache.geode.cache30.DistributedAckPersistentRegionCCEDUnitTest.testClearWithConcurrentEvents:
> 1 failures (99.55947136563876% success rate)
> org.apache.geode.cache30.DistributedAckPersistentRegionCCEOffHeapDUnitTest.testInvalidateEntry:
> 1 failures (99.55947136563876% success rate)
> org.apache.geode.cache30.DistributedAckPersistentRegionCCEOffHeapDUnitTest.testNBRegionDestructionDuringGetInitialImage:
> 1 failures (99.55947136563876% success rate)
> org.apache.geode.cache30.DistributedAckPersistentRegionCCEOffHeapDUnitTest.testNetSearchObservesIdleTime:
> 1 failures (99.55947136563876% success rate)
> org.apache.geode.cache30.DistributedAckPersistentRegionCCEOffHeapDUnitTest.testNonblockingGetInitialImage:
> 2 failures (99.11894273127754% success rate)
> org.apache.geode.cache30.DistributedAckPersistentRegionCCEOffHeapDUnitTest.testTombstones:
> 1 failures (99.55947136563876% success rate)
> org.apache.geode.cache30.DistributedNoAckRegionCCEDUnitTest.testEntryIdleDestroy:
> 1 failures (99.55947136563876% success rate)
> org.apache.geode.cache30.DistributedNoAckRegionCCEDUnitTest.testTXMultiRegion:
> 1 failures (99.55947136563876% success rate)
> org.apache.geode.cache30.DistributedNoAckRegionCCEDUnitTest.testTXRmtMirror:
> 3 failures (98.6784140969163% success rate)
> org.apache.geode.cache30.DistributedNoAckRegionCCEOffHeapDUnitTest.testConcurrentEventsOnNonReplicatedRegion:
> 2 failures (99.11894273127754% success rate)
> org.apache.geode.cache30.DistributedNoAckRegionCCEOffHeapDUnitTest.testRegionIdleInvalidate:
> 1 failures (99.55947136563876% success rate)
> org.apache.geode.cache30.DistributedNoAckRegionCCEOffHeapDUnitTest.testTXRmtMirror:
> 3 failures (98.6784140969163% success rate)
> org.apache.geode.cache30.DistributedNoAckRegionCCEOffHeapDUnitTest.testTombstones:
> 1 failures (99.55947136563876% success rate)
> org.apache.geode.cache30.DistributedNoAckRegionDUnitTest.testTXRmtMirror: 5
> failures (97.79735682819384% success rate)
> org.apache.geode.cache30.DistributedNoAckRegionOffHeapDUnitTest.testMirroredLocalLoad:
> 1 failures (99.55947136563876% success rate)
> org.apache.geode.cache30.DistributedNoAckRegionOffHeapDUnitTest.testTXRmtMirror:
> 8 failures (96.47577092511013% success rate)
> org.apache.geode.cache30.PartitionedRegionOffHeapDUnitTest.testDistributedUpdate:
> 7 failures (96.91629955947137% success rate)
> {noformat}
> Whoever picks this up can split these out if they are not related, but
> leaving them as a single ticket here in case they have a common cause.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-1821) CI Failure: PersistentColocatedPartitionedRegionDUnitTest.testFullTreeOfColocatedChildPRsWithMissingRegions
[
https://issues.apache.org/jira/browse/GEODE-1821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg updated GEODE-1821:
Description:
{noformat}
Build #3755 (Aug 24, 2016 5:09:20 AM)
Revision: 37269735eec44f51ee53075718afe2fa85edc22e
refs/remotes/origin/develop
Error Message
java.util.concurrent.TimeoutException: Timed out waiting 3 milliseconds for
AsyncInvocation to complete.
Stacktrace
java.util.concurrent.TimeoutException: Timed out waiting 3 milliseconds for
AsyncInvocation to complete.
at
com.gemstone.gemfire.test.dunit.AsyncInvocation.timeoutIfAlive(AsyncInvocation.java:443)
at
com.gemstone.gemfire.test.dunit.AsyncInvocation.get(AsyncInvocation.java:390)
at
com.gemstone.gemfire.internal.cache.partitioned.PersistentColocatedPartitionedRegionDUnitTest.testFullTreeOfColocatedChildPRsWithMissingRegions(PersistentColocatedPartitionedRegionDUnitTest.java:1197)
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:497)
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.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.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:497)
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:109)
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:497)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at
org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:377)
at
org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54)
at
org.gradle.internal.concurrent
[jira] [Created] (GEODE-5419) PersistentPartitionedRegionDistributedTest is brittle to other disk failures
Patrick Rhomberg created GEODE-5419:
---
Summary: PersistentPartitionedRegionDistributedTest is brittle to
other disk failures
Key: GEODE-5419
URL: https://issues.apache.org/jira/browse/GEODE-5419
Project: Geode
Issue Type: Bug
Reporter: Patrick Rhomberg
In this concourse run it looks like PersistentPartitionedRegionDistributedTest
had multiple failures after a previous failed test. We suspect some disk files
were left around between test runs that caused these failures.
We should fix these tests to be more robust and clean up their environment
before starting.
[Failure
results|http://staging-files.apachegeode-ci.info/builds/1.8.0-1.3.0/test-results/disitributedTest/1531274835/]
[Concourse
run|https://concourse.apachegeode-ci.info/teams/staging/pipelines/mass-dist/jobs/DistributedTest/builds/153],
requiring access to {{staging}}. If desired, contact d...@geode.apache.org.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5419) PersistentPartitionedRegionDistributedTest is brittle to other disk failures
[
https://issues.apache.org/jira/browse/GEODE-5419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg updated GEODE-5419:
Labels: swat (was: )
> PersistentPartitionedRegionDistributedTest is brittle to other disk failures
>
>
> Key: GEODE-5419
> URL: https://issues.apache.org/jira/browse/GEODE-5419
> Project: Geode
> Issue Type: Bug
>Reporter: Patrick Rhomberg
>Priority: Major
> Labels: swat
>
> In this concourse run it looks like
> PersistentPartitionedRegionDistributedTest had multiple failures after a
> previous failed test. We suspect some disk files were left around between
> test runs that caused these failures.
> We should fix these tests to be more robust and clean up their environment
> before starting.
> [Failure
> results|http://staging-files.apachegeode-ci.info/builds/1.8.0-1.3.0/test-results/disitributedTest/1531274835/]
> [Concourse
> run|https://concourse.apachegeode-ci.info/teams/staging/pipelines/mass-dist/jobs/DistributedTest/builds/153],
> requiring access to {{staging}}. If desired, contact d...@geode.apache.org.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-5425) Improve quality of concourse_job_performance.py
[
https://issues.apache.org/jira/browse/GEODE-5425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg reassigned GEODE-5425:
---
Assignee: Patrick Rhomberg
> Improve quality of concourse_job_performance.py
> ---
>
> Key: GEODE-5425
> URL: https://issues.apache.org/jira/browse/GEODE-5425
> Project: Geode
> Issue Type: Task
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
> Labels: swat
>
> This script could use general cleanup to adhere more closely to PEP-8.
> Additionally:
> * Team target should be parameterized
> * The fetch limit for the initial build summary should be included in the GET
> if more than 100 builds are to be (initially) examined
> * Perhaps optionally, reporting should be able to group by test class, method
> name (for those extending TestBase classes)
> * Optionally, highlight / exclude those failures that resulted from a
> {{timeout exceeded}} failure.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-5425) Improve quality of concourse_job_performance.py
Patrick Rhomberg created GEODE-5425:
---
Summary: Improve quality of concourse_job_performance.py
Key: GEODE-5425
URL: https://issues.apache.org/jira/browse/GEODE-5425
Project: Geode
Issue Type: Task
Reporter: Patrick Rhomberg
This script could use general cleanup to adhere more closely to PEP-8.
Additionally:
* Team target should be parameterized
* The fetch limit for the initial build summary should be included in the GET
if more than 100 builds are to be (initially) examined
* Perhaps optionally, reporting should be able to group by test class, method
name (for those extending TestBase classes)
* Optionally, highlight / exclude those failures that resulted from a {{timeout
exceeded}} failure.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5425) Improve quality of concourse_job_performance.py
[
https://issues.apache.org/jira/browse/GEODE-5425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg updated GEODE-5425:
Labels: swat (was: )
> Improve quality of concourse_job_performance.py
> ---
>
> Key: GEODE-5425
> URL: https://issues.apache.org/jira/browse/GEODE-5425
> Project: Geode
> Issue Type: Task
>Reporter: Patrick Rhomberg
>Priority: Major
> Labels: swat
>
> This script could use general cleanup to adhere more closely to PEP-8.
> Additionally:
> * Team target should be parameterized
> * The fetch limit for the initial build summary should be included in the GET
> if more than 100 builds are to be (initially) examined
> * Perhaps optionally, reporting should be able to group by test class, method
> name (for those extending TestBase classes)
> * Optionally, highlight / exclude those failures that resulted from a
> {{timeout exceeded}} failure.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-5426) Suites that do not modify behavior rerun tests in the pipeline
[
https://issues.apache.org/jira/browse/GEODE-5426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg reassigned GEODE-5426:
---
Assignee: Patrick Rhomberg
> Suites that do not modify behavior rerun tests in the pipeline
> --
>
> Key: GEODE-5426
> URL: https://issues.apache.org/jira/browse/GEODE-5426
> Project: Geode
> Issue Type: Task
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
> Labels: swat
>
> The only JUnit Suite that effects different behavior is
> {{CommandOverHttpDUnitTest}}. All others should be removed to steamline
> testing.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5426) Suites that do not modify behavior rerun tests in the pipeline
[
https://issues.apache.org/jira/browse/GEODE-5426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg updated GEODE-5426:
Labels: swat (was: )
> Suites that do not modify behavior rerun tests in the pipeline
> --
>
> Key: GEODE-5426
> URL: https://issues.apache.org/jira/browse/GEODE-5426
> Project: Geode
> Issue Type: Task
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
> Labels: swat
>
> The only JUnit Suite that effects different behavior is
> {{CommandOverHttpDUnitTest}}. All others should be removed to steamline
> testing.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-5426) Suites that do not modify behavior rerun tests in the pipeline
Patrick Rhomberg created GEODE-5426:
---
Summary: Suites that do not modify behavior rerun tests in the
pipeline
Key: GEODE-5426
URL: https://issues.apache.org/jira/browse/GEODE-5426
Project: Geode
Issue Type: Task
Reporter: Patrick Rhomberg
The only JUnit Suite that effects different behavior is
{{CommandOverHttpDUnitTest}}. All others should be removed to steamline
testing.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-1661) CI failure: IntegratedSecurityCacheLifecycleIntegrationTest.initAndCloseTest
[
https://issues.apache.org/jira/browse/GEODE-1661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg updated GEODE-1661:
Description:
{noformat}
org.junit.ComparisonFailure: expected:<[1]> but was:<[0]>
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
com.gemstone.gemfire.security.IntegratedSecurityCacheLifecycleIntegrationTest.initAndCloseTest(IntegratedSecurityCacheLifecycleIntegrationTest.java:71)
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.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:112)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.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.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at
org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at
org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
at
org.gradle.messaging.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:109)
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.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at
org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at
org.gradle.messaging.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:360)
at
org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54)
at
org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:40)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{noformat}
was:
org.junit.ComparisonFailure: expected:<[1]> but was:<[0]>
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
su
