[jira] [Assigned] (GEODE-7591) potential hang
[
https://issues.apache.org/jira/browse/GEODE-7591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jakov Varenina reassigned GEODE-7591:
-
Assignee: Jakov Varenina
> potential hang
> --
>
> Key: GEODE-7591
> URL: https://issues.apache.org/jira/browse/GEODE-7591
> Project: Geode
> Issue Type: Improvement
> Components: membership
>Reporter: Bruce J Schuchardt
>Assignee: Jakov Varenina
>Priority: Major
>
> This method in ClusterDistributionManager waits for a new membership view to
> be installed, but if the cache is being closed while waiting the method could
> hang because it only checks for cache closure if the object it's waiting on
> is notified. We should change the wait() to have a timeout so that the
> `stopper` is polled periodically
> {code:java}
> void waitForViewInstallation(long id) throws InterruptedException {
> if (id <= membershipViewIdAcknowledged) {
> return;
> }
> synchronized (membershipViewIdGuard) {
> while (membershipViewIdAcknowledged < id &&
> !stopper.isCancelInProgress()) {
> if (logger.isDebugEnabled()) {
> logger.debug("waiting for view {}. Current DM view processed by all
> listeners is {}", id,
> membershipViewIdAcknowledged);
> }
> membershipViewIdGuard.wait();
> }
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[
https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17064848#comment-17064848
]
Udo Kohlmeyer commented on GEODE-7763:
--
[~jasonhuynh] I will commit this test now to be run. Well, I would say that we
would not want to have another significant degrade to go unnoticed.
> Apache Geode 1.11 severely and negatively impacts performance and resource
> utilization
> --
>
> Key: GEODE-7763
> URL: https://issues.apache.org/jira/browse/GEODE-7763
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.10.0, 1.11.0
>Reporter: John Blum
>Priority: Critical
> Labels: performance
> Fix For: 1.12.0
>
> Attachments: 1.11-client-stats.gfs, 1.11-server-stats.gfs,
> 1.11_thread_dumps.rtf, 1.9-client-stats.gfs, 1.9-server-stats.gfs, 1.9.log,
> apache-geode-1.10-client-server-interaction-output.txt,
> apache-geode-1.10-client-server-startup-output.txt,
> apache-geode-1.11-client-server-interaction-output.txt,
> apache-geode-1.11-client-server-startup-output.txt,
> geode-7763-geode-changes.diff, geode-7763-ssdg-changes.diff
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> This problem was first observed in Apache Geode 1.11.0. The problem was not
> present in Apache Geode 1.9.2. This problem is an issue for Apache Geode
> 1.10 as well!
> After upgrading _Spring Session for Apache Geode_ (SSDG) 2.3 to _Spring Data
> for Apache Geode_ (SDG) Neumann/2.3, which is based on Apache Geode 1.11,
> this problem with SSDG's test suite started occurring.
> _Spring Session for Apache Geode_ (SSDG) 2.2, which is based on _Spring Data
> for Apache Geode_ (SDG) Moore/2.2, pulls in Apache Geode 1.9.2. This problem
> did not occur in SSDG 2.2. with Apache Geode 1.9.2.
> Out of curiosity, I wondered whether this problem affects (i.e. was actually
> introduced in) Apache Geode 1.10.0. So, I configured SSDG 2.3 to pull in SDG
> Moore/2.2 but run with Apache Geode 1.10. The problem occurred with Apache
> Geode 1.10 as well!
> The SSDG test class in question, affected by Geode's deficiencies, is the
> [MultiThreadedHighlyConcurrentClientServerSessionOperationsIntegrationTests|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java].
> The test class was modeled after a customer UC, who were using Spring Session
> and Apache Geode/Pivotal GemFire as the HTTP Session state management
> provider, therefore it simulates their highly concurrent environment.
> The test class has 2 primary parameters: [Thread
> Count|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L90]
> and the [Workload
> Size|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L91].
> The "_Workload Size_" should not be confused with the "_Payload Size_" of the
> individual objects passed to the Geode data access operations (i.e. {{gets}},
> {{puts}}, {{removes}}). The "_Workload Size_" merely determines the number
> of {{get}}, {{put}} or {{remove}} operations performed on the (Session)
> Region over the duration of the test run. Certain operations are "favored"
> over others, therefore the number of {{gets}}, {{puts}} and {{removes}} is
> weighted.
> The "_Payload_" in this case is a (HTTP) {{Session}} object and the "size" is
> directly proportional to the number of Session attributes stored in the
> Session.
> As you can see from the [test class
> configuration|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L90-L91]
> in *SSDG* {{2.2}}, the *Thread Count* was set to *180* and the *Workload
> Size* (or number of Region operations) was set to *10,000*.
> This had to be significantly adjusted in SSDG 2.3 using Apache Geode 1.11
> (and, as it turns out, Apache Geode 1.10 as well), as can be seen in the
> {{2.3.0.M1}} release bits source,
> [here|https://github.com/spring-projects/spring-session-data-geode/blob/2.3.0.M1/spring-session-data-geode/src/integration-test/java/org/spri
[jira] [Comment Edited] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[
https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17064848#comment-17064848
]
Udo Kohlmeyer edited comment on GEODE-7763 at 3/23/20, 2:41 PM:
[~jasonhuynh] I will commit this test now to be run. Well, I would say that we
would not want to have another significant degrade to go unnoticed.
Onwards and upwards
was (Author: ukohlmeyer):
[~jasonhuynh] I will commit this test now to be run. Well, I would say that we
would not want to have another significant degrade to go unnoticed.
> Apache Geode 1.11 severely and negatively impacts performance and resource
> utilization
> --
>
> Key: GEODE-7763
> URL: https://issues.apache.org/jira/browse/GEODE-7763
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.10.0, 1.11.0
>Reporter: John Blum
>Priority: Critical
> Labels: performance
> Fix For: 1.12.0
>
> Attachments: 1.11-client-stats.gfs, 1.11-server-stats.gfs,
> 1.11_thread_dumps.rtf, 1.9-client-stats.gfs, 1.9-server-stats.gfs, 1.9.log,
> apache-geode-1.10-client-server-interaction-output.txt,
> apache-geode-1.10-client-server-startup-output.txt,
> apache-geode-1.11-client-server-interaction-output.txt,
> apache-geode-1.11-client-server-startup-output.txt,
> geode-7763-geode-changes.diff, geode-7763-ssdg-changes.diff
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> This problem was first observed in Apache Geode 1.11.0. The problem was not
> present in Apache Geode 1.9.2. This problem is an issue for Apache Geode
> 1.10 as well!
> After upgrading _Spring Session for Apache Geode_ (SSDG) 2.3 to _Spring Data
> for Apache Geode_ (SDG) Neumann/2.3, which is based on Apache Geode 1.11,
> this problem with SSDG's test suite started occurring.
> _Spring Session for Apache Geode_ (SSDG) 2.2, which is based on _Spring Data
> for Apache Geode_ (SDG) Moore/2.2, pulls in Apache Geode 1.9.2. This problem
> did not occur in SSDG 2.2. with Apache Geode 1.9.2.
> Out of curiosity, I wondered whether this problem affects (i.e. was actually
> introduced in) Apache Geode 1.10.0. So, I configured SSDG 2.3 to pull in SDG
> Moore/2.2 but run with Apache Geode 1.10. The problem occurred with Apache
> Geode 1.10 as well!
> The SSDG test class in question, affected by Geode's deficiencies, is the
> [MultiThreadedHighlyConcurrentClientServerSessionOperationsIntegrationTests|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java].
> The test class was modeled after a customer UC, who were using Spring Session
> and Apache Geode/Pivotal GemFire as the HTTP Session state management
> provider, therefore it simulates their highly concurrent environment.
> The test class has 2 primary parameters: [Thread
> Count|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L90]
> and the [Workload
> Size|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L91].
> The "_Workload Size_" should not be confused with the "_Payload Size_" of the
> individual objects passed to the Geode data access operations (i.e. {{gets}},
> {{puts}}, {{removes}}). The "_Workload Size_" merely determines the number
> of {{get}}, {{put}} or {{remove}} operations performed on the (Session)
> Region over the duration of the test run. Certain operations are "favored"
> over others, therefore the number of {{gets}}, {{puts}} and {{removes}} is
> weighted.
> The "_Payload_" in this case is a (HTTP) {{Session}} object and the "size" is
> directly proportional to the number of Session attributes stored in the
> Session.
> As you can see from the [test class
> configuration|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L90-L91]
> in *SSDG* {{2.2}}, the *Thread Count* was set to *180* and the *Workload
> Size* (or number of Region operations) was set to *10,000*.
> This had to be significantly adjusted in SSDG 2.3 using Apache Geode 1.11
> (and,
[jira] [Commented] (GEODE-7851) Pulse should support OAuth2 authorization code flow
[ https://issues.apache.org/jira/browse/GEODE-7851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17064945#comment-17064945 ] ASF subversion and git services commented on GEODE-7851: Commit 578cb0756710cf18ba345e125601e057ec413ebf in geode's branch refs/heads/develop from Jinmei Liao [ https://gitbox.apache.org/repos/asf?p=geode.git;h=578cb07 ] GEODE-7851: Pulse Oauth Configuration (#4823) Co-authored-by: Dale Emery Co-authored-by: Joris Melchior * create an OAuthSecurityConfig to configure spring using oauth * add PULSE as one of the oauth-enabled-component, and if pulse is set to use oauth, set the OAuthSecurityConfig as the active security profile * use pulse.properties in the locator's working dir to externalize pulse authentication provider configuration > Pulse should support OAuth2 authorization code flow > --- > > Key: GEODE-7851 > URL: https://issues.apache.org/jira/browse/GEODE-7851 > Project: Geode > Issue Type: New Feature > Components: docs, pulse >Reporter: Jinmei Liao >Assignee: Dale Emery >Priority: Major > Time Spent: 5h > Remaining Estimate: 0h > > Instead of using username/password to log in to pulse, pulse should redirect > to a configured authentication provider to get access token to login. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7098) Tomcat8SessionsClientServerDUnitTest fails with ConnectException
[ https://issues.apache.org/jira/browse/GEODE-7098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17064947#comment-17064947 ] Ivan Godwin commented on GEODE-7098: New failures: testExtraSessionsNotCreated https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/1401 testMultipleAttributeUpdates https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/1447 > Tomcat8SessionsClientServerDUnitTest fails with ConnectException > > > Key: GEODE-7098 > URL: https://issues.apache.org/jira/browse/GEODE-7098 > Project: Geode > Issue Type: Bug >Reporter: Benjamin P Ross >Assignee: Mark Hanson >Priority: Major > Labels: flaky > > We've seen Tomcat8SessionsClientServerDUnitTest.testExtraSessionsNotCreated > fail with > a ConnectException > org.apache.geode.modules.session.Tomcat8SessionsClientServerDUnitTest > > testExtraSessionsNotCreated FAILED > java.net.ConnectException: Connection refused (Connection refused) > Caused by: > java.net.ConnectException: Connection refused (Connection refused) > This could be an environmental error, but if a pattern develops it could be > due to a flaky test. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-6413) CI Failure: Bind Exception during ClusterCommunicationsDUnitTest.performARollingUpgrade
[
https://issues.apache.org/jira/browse/GEODE-6413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson updated GEODE-6413:
---
Labels: flaky (was: )
> CI Failure: Bind Exception during
> ClusterCommunicationsDUnitTest.performARollingUpgrade
> ---
>
> Key: GEODE-6413
> URL: https://issues.apache.org/jira/browse/GEODE-6413
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Benjamin P Ross
>Priority: Major
> Labels: flaky
> Fix For: 1.9.0
>
>
> Stack Trace:
> {noformat}
> org.apache.geode.ClusterCommunicationsDUnitTest >
> performARollingUpgrade[SHARED_CONNECTIONS] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.NamedRunnable.run in VM 0 running on Host
> c4dd6cb2c206 with 3 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:393)
> at
> org.apache.geode.ClusterCommunicationsDUnitTest.performARollingUpgrade(ClusterCommunicationsDUnitTest.java:214)
> Caused by:
> java.net.BindException: Failed to create server socket on
> c4dd6cb2c206/172.17.0.16[43969]
> at
> org.apache.geode.internal.net.SocketCreator.createServerSocket(SocketCreator.java:756)
> at
> org.apache.geode.internal.net.SocketCreator.createServerSocket(SocketCreator.java:714)
> at
> org.apache.geode.internal.net.SocketCreator.createServerSocket(SocketCreator.java:680)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.initializeServerSocket(TcpServer.java:225)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.startServerThread(TcpServer.java:215)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.start(TcpServer.java:210)
> at
> org.apache.geode.distributed.internal.InternalLocator.startTcpServer(InternalLocator.java:501)
> at
> org.apache.geode.distributed.internal.InternalLocator.startPeerLocation(InternalLocator.java:557)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:340)
> at
> org.apache.geode.distributed.Locator.startLocator(Locator.java:252)
> at
> org.apache.geode.distributed.Locator.startLocatorAndDS(Locator.java:139)
> at
> org.apache.geode.ClusterCommunicationsDUnitTest.lambda$null$1(ClusterCommunicationsDUnitTest.java:220)
> Caused by:
> java.net.BindException: Address already in use (Bind failed)
> at java.net.PlainSocketImpl.socketBind(Native Method)
> at
> java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387)
> at java.net.ServerSocket.bind(ServerSocket.java:375)
> at
> org.apache.geode.internal.net.SocketCreator.createServerSocket(SocketCreator.java:753)
> ... 11 more
> {noformat}
> This test may be fixed with a longer await() timeout.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-6413) CI Failure: Bind Exception during ClusterCommunicationsDUnitTest.performARollingUpgrade
[
https://issues.apache.org/jira/browse/GEODE-6413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson updated GEODE-6413:
---
Labels: (was: flaky)
> CI Failure: Bind Exception during
> ClusterCommunicationsDUnitTest.performARollingUpgrade
> ---
>
> Key: GEODE-6413
> URL: https://issues.apache.org/jira/browse/GEODE-6413
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Benjamin P Ross
>Priority: Major
> Fix For: 1.9.0
>
>
> Stack Trace:
> {noformat}
> org.apache.geode.ClusterCommunicationsDUnitTest >
> performARollingUpgrade[SHARED_CONNECTIONS] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.NamedRunnable.run in VM 0 running on Host
> c4dd6cb2c206 with 3 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:393)
> at
> org.apache.geode.ClusterCommunicationsDUnitTest.performARollingUpgrade(ClusterCommunicationsDUnitTest.java:214)
> Caused by:
> java.net.BindException: Failed to create server socket on
> c4dd6cb2c206/172.17.0.16[43969]
> at
> org.apache.geode.internal.net.SocketCreator.createServerSocket(SocketCreator.java:756)
> at
> org.apache.geode.internal.net.SocketCreator.createServerSocket(SocketCreator.java:714)
> at
> org.apache.geode.internal.net.SocketCreator.createServerSocket(SocketCreator.java:680)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.initializeServerSocket(TcpServer.java:225)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.startServerThread(TcpServer.java:215)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.start(TcpServer.java:210)
> at
> org.apache.geode.distributed.internal.InternalLocator.startTcpServer(InternalLocator.java:501)
> at
> org.apache.geode.distributed.internal.InternalLocator.startPeerLocation(InternalLocator.java:557)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:340)
> at
> org.apache.geode.distributed.Locator.startLocator(Locator.java:252)
> at
> org.apache.geode.distributed.Locator.startLocatorAndDS(Locator.java:139)
> at
> org.apache.geode.ClusterCommunicationsDUnitTest.lambda$null$1(ClusterCommunicationsDUnitTest.java:220)
> Caused by:
> java.net.BindException: Address already in use (Bind failed)
> at java.net.PlainSocketImpl.socketBind(Native Method)
> at
> java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387)
> at java.net.ServerSocket.bind(ServerSocket.java:375)
> at
> org.apache.geode.internal.net.SocketCreator.createServerSocket(SocketCreator.java:753)
> ... 11 more
> {noformat}
> This test may be fixed with a longer await() timeout.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-7135) Tomcat8SessionsDUnitTest > testSessionExpiration1 FAILED
[
https://issues.apache.org/jira/browse/GEODE-7135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson resolved GEODE-7135.
Resolution: Duplicate
> Tomcat8SessionsDUnitTest > testSessionExpiration1 FAILED
>
>
> Key: GEODE-7135
> URL: https://issues.apache.org/jira/browse/GEODE-7135
> Project: Geode
> Issue Type: Bug
>Reporter: Murtuza Boxwala
>Priority: Major
> Labels: flaky
>
> {code:java}
> org.apache.geode.modules.session.Tomcat8SessionsDUnitTest >
> testSessionExpiration1 FAILED
> java.net.ConnectException: Connection refused (Connection refused)
> Caused by:
> java.net.ConnectException: Connection refused (Connection refused)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-6008) CI Failure: ClientServerHostNameVerificationDistributedTest.expectConnectionFailureWhenNoHostNameInServerKey failed
[
https://issues.apache.org/jira/browse/GEODE-6008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17065002#comment-17065002
]
ASF subversion and git services commented on GEODE-6008:
Commit 97a0dc87980f1c2c42351c84ec32a2411d292251 in geode's branch
refs/heads/feature/GEODE-6008b from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=97a0dc8 ]
GEODE-6008: CI Failure:
ClientServerHostNameVerificationDistributedTest.expectConnectionFailureWhenNoHostNameInServerKey
failed
The "Message distribution has terminated" failure is caused by an
unreported NullPointerException in a residual reader thread introduced
in the fix for GEODE-7727. That fix caused a thread to say alive in a
peer-to-peer tcp/ip Connection in order to clean up the receiving side
of a socket. The Connection shutdown method close() method, however,
releases the Connection's input buffer and nulls out the field. The
reader thread then threw an NPE that was caught and caused the
"Message distribution has terminated" message, which is picked up as a
suspect string by the testing infrastructure.
This problem is also seen in GEODE-7894, GEODE-7871, GEODE-7873 and
GEODE-7806.
The fix is to record the fact that a residual reader thread exists and
avoid releasing the Connection's input buffer when the connection is
closed. This lets the reader thread do the cleanup.
While testing the fix I found that the NioSslEngine was throwing an
IllegalStateException when the reader thread tried to use it in this
same situation. This exception wasn't being caught and caused more
suspect strings to be logged. I've changed this to a checked exception
that is already handled by the reader thread.
ClientServerHostNameVerificationDistributedTest also wasn't working on
my Mac due to its /etc/hosts configuration. I changed the test to allow
the IP address selected by LocalHostUtil to be a valid client/server
address for the SSL certificates it generates.
> CI Failure:
> ClientServerHostNameVerificationDistributedTest.expectConnectionFailureWhenNoHostNameInServerKey
> failed
> ---
>
> Key: GEODE-6008
> URL: https://issues.apache.org/jira/browse/GEODE-6008
> Project: Geode
> Issue Type: Bug
> Components: client/server, membership
>Reporter: Jinmei Liao
>Assignee: Bruce J Schuchardt
>Priority: Major
> Fix For: 1.9.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> java.lang.AssertionError: Suspicious strings were written to the log during
> this run.
> {noformat}
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 1872
> y: java.security.cert.CertificateException: No name matching 88deff82cd47
> found
> at org.junit.Assert.fail(Assert.java:88)
> at
> org.apache.geode.test.dunit.standalone.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:412)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.after(ClusterStartupRule.java:172)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:50)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:106)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> at
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:66)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invo
[jira] [Commented] (GEODE-7727) Geode P2P connection hanging
[
https://issues.apache.org/jira/browse/GEODE-7727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17065003#comment-17065003
]
ASF subversion and git services commented on GEODE-7727:
Commit 97a0dc87980f1c2c42351c84ec32a2411d292251 in geode's branch
refs/heads/feature/GEODE-6008b from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=97a0dc8 ]
GEODE-6008: CI Failure:
ClientServerHostNameVerificationDistributedTest.expectConnectionFailureWhenNoHostNameInServerKey
failed
The "Message distribution has terminated" failure is caused by an
unreported NullPointerException in a residual reader thread introduced
in the fix for GEODE-7727. That fix caused a thread to say alive in a
peer-to-peer tcp/ip Connection in order to clean up the receiving side
of a socket. The Connection shutdown method close() method, however,
releases the Connection's input buffer and nulls out the field. The
reader thread then threw an NPE that was caught and caused the
"Message distribution has terminated" message, which is picked up as a
suspect string by the testing infrastructure.
This problem is also seen in GEODE-7894, GEODE-7871, GEODE-7873 and
GEODE-7806.
The fix is to record the fact that a residual reader thread exists and
avoid releasing the Connection's input buffer when the connection is
closed. This lets the reader thread do the cleanup.
While testing the fix I found that the NioSslEngine was throwing an
IllegalStateException when the reader thread tried to use it in this
same situation. This exception wasn't being caught and caused more
suspect strings to be logged. I've changed this to a checked exception
that is already handled by the reader thread.
ClientServerHostNameVerificationDistributedTest also wasn't working on
my Mac due to its /etc/hosts configuration. I changed the test to allow
the IP address selected by LocalHostUtil to be a valid client/server
address for the SSL certificates it generates.
> Geode P2P connection hanging
>
>
> Key: GEODE-7727
> URL: https://issues.apache.org/jira/browse/GEODE-7727
> Project: Geode
> Issue Type: Bug
>Reporter: Mario Ivanac
>Assignee: Mario Ivanac
>Priority: Major
> Labels: needs-review, pull-request-available
> Fix For: 1.13.0
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> {color:#172b4d}Geode P2P handshake reader stops listening to it's socket once
> the handshake between 2 peers is established. This seems to be a design
> choice.
> {color}
> {color:#172b4d}The problem is when the connection gets killed (TCP FIN).
> Since nothing is listening on the socket, nothing will get that FIN package
> and close the connection. The connection is left hanging (CLOSE-WAIT state).
> The peers are then unable to establish proper P2P communication later.{color}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7894) CustomSSLProviderDistributedTest hostNameIsValidatedWhenUsingDefaultContext fails with suspect uncaught DistributedSystemDisconnectedException
[
https://issues.apache.org/jira/browse/GEODE-7894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17065004#comment-17065004
]
ASF subversion and git services commented on GEODE-7894:
Commit 97a0dc87980f1c2c42351c84ec32a2411d292251 in geode's branch
refs/heads/feature/GEODE-6008b from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=97a0dc8 ]
GEODE-6008: CI Failure:
ClientServerHostNameVerificationDistributedTest.expectConnectionFailureWhenNoHostNameInServerKey
failed
The "Message distribution has terminated" failure is caused by an
unreported NullPointerException in a residual reader thread introduced
in the fix for GEODE-7727. That fix caused a thread to say alive in a
peer-to-peer tcp/ip Connection in order to clean up the receiving side
of a socket. The Connection shutdown method close() method, however,
releases the Connection's input buffer and nulls out the field. The
reader thread then threw an NPE that was caught and caused the
"Message distribution has terminated" message, which is picked up as a
suspect string by the testing infrastructure.
This problem is also seen in GEODE-7894, GEODE-7871, GEODE-7873 and
GEODE-7806.
The fix is to record the fact that a residual reader thread exists and
avoid releasing the Connection's input buffer when the connection is
closed. This lets the reader thread do the cleanup.
While testing the fix I found that the NioSslEngine was throwing an
IllegalStateException when the reader thread tried to use it in this
same situation. This exception wasn't being caught and caused more
suspect strings to be logged. I've changed this to a checked exception
that is already handled by the reader thread.
ClientServerHostNameVerificationDistributedTest also wasn't working on
my Mac due to its /etc/hosts configuration. I changed the test to allow
the IP address selected by LocalHostUtil to be a valid client/server
address for the SSL certificates it generates.
> CustomSSLProviderDistributedTest hostNameIsValidatedWhenUsingDefaultContext
> fails with suspect uncaught DistributedSystemDisconnectedException
> --
>
> Key: GEODE-7894
> URL: https://issues.apache.org/jira/browse/GEODE-7894
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Darrel Schneider
>Assignee: Dan Smith
>Priority: Minor
> Labels: flakey
>
> See:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/1663
> {noformat}
> org.apache.geode.cache.client.internal.CustomSSLProviderDistributedTest >
> hostNameIsValidatedWhenUsingDefaultContext FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 1654
> [fatal 2020/03/19 17:26:01.806 GMT tid=215] Uncaught
> exception in thread Thread[unused p2p reader,5,RMI Runtime]
> org.apache.geode.distributed.DistributedSystemDisconnectedException:
> Distribution manager on 172.17.0.15(server-1:113):41001 started at Thu
> Mar 19 17:25:57 GMT 2020: Message distribution has terminated
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$Stopper.generateCancelledException(ClusterDistributionManager.java:2873)
> at
> org.apache.geode.internal.tcp.TCPConduit$Stopper.generateCancelledException(TCPConduit.java:1004)
> at
> org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
> at
> org.apache.geode.internal.tcp.Connection.readMessages(Connection.java:1666)
> at org.apache.geode.internal.tcp.Connection.run(Connection.java:1446)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7873) CI Failure: DeployJarWithSSLDUnitTest.deployJarWithMultipleLocators
[
https://issues.apache.org/jira/browse/GEODE-7873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17065006#comment-17065006
]
ASF subversion and git services commented on GEODE-7873:
Commit 97a0dc87980f1c2c42351c84ec32a2411d292251 in geode's branch
refs/heads/feature/GEODE-6008b from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=97a0dc8 ]
GEODE-6008: CI Failure:
ClientServerHostNameVerificationDistributedTest.expectConnectionFailureWhenNoHostNameInServerKey
failed
The "Message distribution has terminated" failure is caused by an
unreported NullPointerException in a residual reader thread introduced
in the fix for GEODE-7727. That fix caused a thread to say alive in a
peer-to-peer tcp/ip Connection in order to clean up the receiving side
of a socket. The Connection shutdown method close() method, however,
releases the Connection's input buffer and nulls out the field. The
reader thread then threw an NPE that was caught and caused the
"Message distribution has terminated" message, which is picked up as a
suspect string by the testing infrastructure.
This problem is also seen in GEODE-7894, GEODE-7871, GEODE-7873 and
GEODE-7806.
The fix is to record the fact that a residual reader thread exists and
avoid releasing the Connection's input buffer when the connection is
closed. This lets the reader thread do the cleanup.
While testing the fix I found that the NioSslEngine was throwing an
IllegalStateException when the reader thread tried to use it in this
same situation. This exception wasn't being caught and caused more
suspect strings to be logged. I've changed this to a checked exception
that is already handled by the reader thread.
ClientServerHostNameVerificationDistributedTest also wasn't working on
my Mac due to its /etc/hosts configuration. I changed the test to allow
the IP address selected by LocalHostUtil to be a valid client/server
address for the SSL certificates it generates.
> CI Failure: DeployJarWithSSLDUnitTest.deployJarWithMultipleLocators
> ---
>
> Key: GEODE-7873
> URL: https://issues.apache.org/jira/browse/GEODE-7873
> Project: Geode
> Issue Type: Bug
>Reporter: Ivan Godwin
>Priority: Major
>
> DeployJarWithSSLDUnitTest > deployJarWithMultipleLocators failed with the
> following output:
> {code:java}
> org.apache.geode.management.internal.configuration.DeployJarWithSSLDUnitTest
> > deployJarWithMultipleLocators FAILEDjava.lang.AssertionError:
> Suspicious strings were written to the log during this run.Fix the
> strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 1966
> [fatal 2020/03/11 17:43:42.352 GMT tid=82] Uncaught
> exception in thread Thread[unused p2p reader,5,RMI Runtime]
> org.apache.geode.distributed.DistributedSystemDisconnectedException:
> Distribution manager on 172.17.0.9(server-2:123):41002 started at Wed Mar
> 11 17:43:37 GMT 2020: Message distribution has terminated at
> org.apache.geode.distributed.internal.ClusterDistributionManager$Stopper.generateCancelledException(ClusterDistributionManager.java:2872)
> at
> org.apache.geode.internal.tcp.TCPConduit$Stopper.generateCancelledException(TCPConduit.java:1004)
> at
> org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
> at
> org.apache.geode.internal.tcp.Connection.readMessages(Connection.java:1666)
>at org.apache.geode.internal.tcp.Connection.run(Connection.java:1446)
> at java.lang.Thread.run(Thread.java:748)
> ---
> Found suspect string in log4j at line 1975
> [fatal 2020/03/11 17:43:42.362 GMT tid=65] Uncaught
> exception in thread Thread[unused p2p reader,5,RMI Runtime]
> org.apache.geode.distributed.DistributedSystemDisconnectedException:
> Distribution manager on 172.17.0.9(server-2:123):41002 started at Wed Mar
> 11 17:43:37 GMT 2020: Message distribution has terminated at
> org.apache.geode.distributed.internal.ClusterDistributionManager$Stopper.generateCancelledException(ClusterDistributionManager.java:2872)
> at
> org.apache.geode.internal.tcp.TCPConduit$Stopper.generateCancelledException(TCPConduit.java:1004)
> at
> org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
> at
> org.apache.geode.internal.tcp.Connection.readMessages(Connection.java:1666)
>at org.apache.geode.internal.tcp.Connection.run(Connection.java:1446)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> https://concourse.apachegeode-ci.info/te
[jira] [Commented] (GEODE-7806) CI Failure: org.apache.geode.cache.client.internal.CacheServerSSLConnectionDUnitTest > testCacheServerSSL[1] FAILED
[ https://issues.apache.org/jira/browse/GEODE-7806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17065007#comment-17065007 ] ASF subversion and git services commented on GEODE-7806: Commit 97a0dc87980f1c2c42351c84ec32a2411d292251 in geode's branch refs/heads/feature/GEODE-6008b from Bruce Schuchardt [ https://gitbox.apache.org/repos/asf?p=geode.git;h=97a0dc8 ] GEODE-6008: CI Failure: ClientServerHostNameVerificationDistributedTest.expectConnectionFailureWhenNoHostNameInServerKey failed The "Message distribution has terminated" failure is caused by an unreported NullPointerException in a residual reader thread introduced in the fix for GEODE-7727. That fix caused a thread to say alive in a peer-to-peer tcp/ip Connection in order to clean up the receiving side of a socket. The Connection shutdown method close() method, however, releases the Connection's input buffer and nulls out the field. The reader thread then threw an NPE that was caught and caused the "Message distribution has terminated" message, which is picked up as a suspect string by the testing infrastructure. This problem is also seen in GEODE-7894, GEODE-7871, GEODE-7873 and GEODE-7806. The fix is to record the fact that a residual reader thread exists and avoid releasing the Connection's input buffer when the connection is closed. This lets the reader thread do the cleanup. While testing the fix I found that the NioSslEngine was throwing an IllegalStateException when the reader thread tried to use it in this same situation. This exception wasn't being caught and caused more suspect strings to be logged. I've changed this to a checked exception that is already handled by the reader thread. ClientServerHostNameVerificationDistributedTest also wasn't working on my Mac due to its /etc/hosts configuration. I changed the test to allow the IP address selected by LocalHostUtil to be a valid client/server address for the SSL certificates it generates. > CI Failure: > org.apache.geode.cache.client.internal.CacheServerSSLConnectionDUnitTest > > testCacheServerSSL[1] FAILED > --- > > Key: GEODE-7806 > URL: https://issues.apache.org/jira/browse/GEODE-7806 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Anilkumar Gingade >Priority: Major > > org.apache.geode.cache.client.internal.CacheServerSSLConnectionDUnitTest > > testCacheServerSSL[1] FAILED > java.lang.AssertionError: Suspicious strings were written to the log > during this run. > Fix the strings or use IgnoredException.addIgnoredException to ignore. > --- > Found suspect string in log4j at line 2337 > [fatal 2020/02/18 22:01:03.293 GMT tid=178] Uncaught > exception in thread Thread[unused p2p reader,5,main] > org.apache.geode.distributed.DistributedSystemDisconnectedException: > Distribution manager on 172.17.0.19(1:locator):41001 started at Tue > Feb 18 22:00:52 GMT 2020: Message distribution has terminated > at > org.apache.geode.distributed.internal.ClusterDistributionManager$Stopper.generateCancelledException(ClusterDistributionManager.java:2874) > at > org.apache.geode.internal.tcp.TCPConduit$Stopper.generateCancelledException(TCPConduit.java:986) > at > org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83) > at > org.apache.geode.internal.tcp.Connection.readMessages(Connection.java:1690) > at org.apache.geode.internal.tcp.Connection.run(Connection.java:1472) > at java.base/java.lang.Thread.run(Thread.java:834) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7871) CI Failure: ClientServerHostNameVerificationDistributedTest.expectConnectionFailureWhenNoHostNameInLocatorKey Failed
[
https://issues.apache.org/jira/browse/GEODE-7871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17065005#comment-17065005
]
ASF subversion and git services commented on GEODE-7871:
Commit 97a0dc87980f1c2c42351c84ec32a2411d292251 in geode's branch
refs/heads/feature/GEODE-6008b from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=97a0dc8 ]
GEODE-6008: CI Failure:
ClientServerHostNameVerificationDistributedTest.expectConnectionFailureWhenNoHostNameInServerKey
failed
The "Message distribution has terminated" failure is caused by an
unreported NullPointerException in a residual reader thread introduced
in the fix for GEODE-7727. That fix caused a thread to say alive in a
peer-to-peer tcp/ip Connection in order to clean up the receiving side
of a socket. The Connection shutdown method close() method, however,
releases the Connection's input buffer and nulls out the field. The
reader thread then threw an NPE that was caught and caused the
"Message distribution has terminated" message, which is picked up as a
suspect string by the testing infrastructure.
This problem is also seen in GEODE-7894, GEODE-7871, GEODE-7873 and
GEODE-7806.
The fix is to record the fact that a residual reader thread exists and
avoid releasing the Connection's input buffer when the connection is
closed. This lets the reader thread do the cleanup.
While testing the fix I found that the NioSslEngine was throwing an
IllegalStateException when the reader thread tried to use it in this
same situation. This exception wasn't being caught and caused more
suspect strings to be logged. I've changed this to a checked exception
that is already handled by the reader thread.
ClientServerHostNameVerificationDistributedTest also wasn't working on
my Mac due to its /etc/hosts configuration. I changed the test to allow
the IP address selected by LocalHostUtil to be a valid client/server
address for the SSL certificates it generates.
> CI Failure:
> ClientServerHostNameVerificationDistributedTest.expectConnectionFailureWhenNoHostNameInLocatorKey
> Failed
>
>
> Key: GEODE-7871
> URL: https://issues.apache.org/jira/browse/GEODE-7871
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.12.0
>Reporter: Ivan Godwin
>Assignee: Bruce J Schuchardt
>Priority: Major
>
> ClientServerHostNameVerificationDistributedTest >
> expectConnectionFailureWhenNoHostNameInLocatorKey failed with the following
> output:
> {code:java}
> org.apache.geode.cache.client.internal.ClientServerHostNameVerificationDistributedTest
> > expectConnectionFailureWhenNoHostNameInLocatorKey FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 3602
> [fatal 2020/03/12 02:42:26.780 GMT tid=94] Uncaught
> exception in thread Thread[unused p2p reader,5,RMI Runtime]
> org.apache.geode.distributed.DistributedSystemDisconnectedException:
> Distribution manager on 172.17.0.14(server-2:95):41002 started at Thu Mar
> 12 02:42:11 GMT 2020: Message distribution has terminated
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$Stopper.generateCancelledException(ClusterDistributionManager.java:2872)
> at
> org.apache.geode.internal.tcp.TCPConduit$Stopper.generateCancelledException(TCPConduit.java:1004)
> at
> org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
> at
> org.apache.geode.internal.tcp.Connection.readMessages(Connection.java:1666)
> at org.apache.geode.internal.tcp.Connection.run(Connection.java:1446)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {code}
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/1621
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7727) Geode P2P connection hanging
[
https://issues.apache.org/jira/browse/GEODE-7727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17065010#comment-17065010
]
Bruce J Schuchardt commented on GEODE-7727:
---
The fix for this problem introduced an NPE during shutdown of a Connection.
The problem was reported in these JIRA tickets: GEODE-7894, GEODE-7871,
GEODE-7873,
GEODE-7806 and GEODE-6008 (reopened).
> Geode P2P connection hanging
>
>
> Key: GEODE-7727
> URL: https://issues.apache.org/jira/browse/GEODE-7727
> Project: Geode
> Issue Type: Bug
>Reporter: Mario Ivanac
>Assignee: Mario Ivanac
>Priority: Major
> Labels: needs-review, pull-request-available
> Fix For: 1.13.0
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> {color:#172b4d}Geode P2P handshake reader stops listening to it's socket once
> the handshake between 2 peers is established. This seems to be a design
> choice.
> {color}
> {color:#172b4d}The problem is when the connection gets killed (TCP FIN).
> Since nothing is listening on the socket, nothing will get that FIN package
> and close the connection. The connection is left hanging (CLOSE-WAIT state).
> The peers are then unable to establish proper P2P communication later.{color}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-7135) Tomcat8SessionsDUnitTest > testSessionExpiration1 FAILED
[
https://issues.apache.org/jira/browse/GEODE-7135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson reassigned GEODE-7135:
--
Assignee: Mark Hanson
> Tomcat8SessionsDUnitTest > testSessionExpiration1 FAILED
>
>
> Key: GEODE-7135
> URL: https://issues.apache.org/jira/browse/GEODE-7135
> Project: Geode
> Issue Type: Bug
>Reporter: Murtuza Boxwala
>Assignee: Mark Hanson
>Priority: Major
> Labels: flaky
>
> {code:java}
> org.apache.geode.modules.session.Tomcat8SessionsDUnitTest >
> testSessionExpiration1 FAILED
> java.net.ConnectException: Connection refused (Connection refused)
> Caused by:
> java.net.ConnectException: Connection refused (Connection refused)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-7786) Tomcat7CachingClientServerTest is having a couple test failures...
[
https://issues.apache.org/jira/browse/GEODE-7786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson reassigned GEODE-7786:
--
Assignee: Mark Hanson
> Tomcat7CachingClientServerTest is having a couple test failures...
> --
>
> Key: GEODE-7786
> URL: https://issues.apache.org/jira/browse/GEODE-7786
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Mark Hanson
>Assignee: Mark Hanson
>Priority: Major
> Labels: flaky
>
> containersShouldExpireInSetTimeframe
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/304]
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/222]
> {noformat}
> org.awaitility.core.ConditionTimeoutException: Condition with lambda
> expression in org.apache.geode.session.tests.CargoTestBase was not fulfilled
> within 300 seconds.
> at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:145)
> at
> org.awaitility.core.CallableCondition.await(CallableCondition.java:79)
> at
> org.awaitility.core.CallableCondition.await(CallableCondition.java:27)
> at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:902)
> at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:860)
> at
> org.apache.geode.session.tests.CargoTestBase.getKeyValueDataOnAllClients(CargoTestBase.java:145)
> at
> org.apache.geode.session.tests.CargoTestBase.containersShouldExpireInSetTimeframe(CargoTestBase.java:250)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at
> org.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:40)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:138)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> at
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(Re
[jira] [Resolved] (GEODE-7786) Tomcat7CachingClientServerTest is having a couple test failures...
[
https://issues.apache.org/jira/browse/GEODE-7786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson resolved GEODE-7786.
Resolution: Duplicate
> Tomcat7CachingClientServerTest is having a couple test failures...
> --
>
> Key: GEODE-7786
> URL: https://issues.apache.org/jira/browse/GEODE-7786
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Mark Hanson
>Priority: Major
> Labels: flaky
>
> containersShouldExpireInSetTimeframe
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/304]
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/222]
> {noformat}
> org.awaitility.core.ConditionTimeoutException: Condition with lambda
> expression in org.apache.geode.session.tests.CargoTestBase was not fulfilled
> within 300 seconds.
> at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:145)
> at
> org.awaitility.core.CallableCondition.await(CallableCondition.java:79)
> at
> org.awaitility.core.CallableCondition.await(CallableCondition.java:27)
> at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:902)
> at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:860)
> at
> org.apache.geode.session.tests.CargoTestBase.getKeyValueDataOnAllClients(CargoTestBase.java:145)
> at
> org.apache.geode.session.tests.CargoTestBase.containersShouldExpireInSetTimeframe(CargoTestBase.java:250)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at
> org.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:40)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:138)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> at
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
>
[jira] [Created] (GEODE-7900) GfshHostNameVerificationDistributedTest > expectConnectionFailureWhenNoHostNameInLocatorKey failing on Windows
Bill Burcham created GEODE-7900:
---
Summary: GfshHostNameVerificationDistributedTest >
expectConnectionFailureWhenNoHostNameInLocatorKey failing on Windows
Key: GEODE-7900
URL: https://issues.apache.org/jira/browse/GEODE-7900
Project: Geode
Issue Type: Bug
Components: configuration
Reporter: Bill Burcham
failures in these two tests e.g. here
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/IntegrationTestOpenJDK11/builds/1613:
{code}
org.apache.geode.management.internal.cli.commands.GfshHostNameVerificationDistributedTest
> expectConnectionFailureWhenNoHostNameInLocatorKey FAILED
java.lang.AssertionError:
Expecting:
<"Duplicated server name of type 0
">
to contain:
<"Unable to form SSL connection">
at
org.apache.geode.test.junit.assertions.CommandResultAssert.containsOutput(CommandResultAssert.java:87)
at
org.apache.geode.management.internal.cli.commands.GfshHostNameVerificationDistributedTest.validateGfshConnection(GfshHostNameVerificationDistributedTest.java:163)
at
org.apache.geode.management.internal.cli.commands.GfshHostNameVerificationDistributedTest.expectConnectionFailureWhenNoHostNameInLocatorKey(GfshHostNameVerificationDistributedTest.java:117)
org.apache.geode.management.internal.cli.commands.GfshHostNameVerificationDistributedTest
> expectConnectionFailureWhenWrongHostNameInLocatorKey FAILED
java.lang.AssertionError:
Expecting:
<"Duplicated server name of type 0
">
to contain:
<"Unable to form SSL connection">
at
org.apache.geode.test.junit.assertions.CommandResultAssert.containsOutput(CommandResultAssert.java:87)
at
org.apache.geode.management.internal.cli.commands.GfshHostNameVerificationDistributedTest.validateGfshConnection(GfshHostNameVerificationDistributedTest.java:163)
at
org.apache.geode.management.internal.cli.commands.GfshHostNameVerificationDistributedTest.expectConnectionFailureWhenWrongHostNameInLocatorKey(GfshHostNameVerificationDistributedTest.java:128)
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-7900) GfshHostNameVerificationDistributedTest > expectConnectionFailureWhenNoHostNameInLocatorKey failing on Windows
[
https://issues.apache.org/jira/browse/GEODE-7900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Burcham reassigned GEODE-7900:
---
Assignee: Dan Smith
> GfshHostNameVerificationDistributedTest >
> expectConnectionFailureWhenNoHostNameInLocatorKey failing on Windows
> --
>
> Key: GEODE-7900
> URL: https://issues.apache.org/jira/browse/GEODE-7900
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Reporter: Bill Burcham
>Assignee: Dan Smith
>Priority: Major
>
> failures in these two tests e.g. here
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/IntegrationTestOpenJDK11/builds/1613:
> {code}
> org.apache.geode.management.internal.cli.commands.GfshHostNameVerificationDistributedTest
> > expectConnectionFailureWhenNoHostNameInLocatorKey FAILED
> java.lang.AssertionError:
> Expecting:
> <"Duplicated server name of type 0
> ">
> to contain:
> <"Unable to form SSL connection">
> at
> org.apache.geode.test.junit.assertions.CommandResultAssert.containsOutput(CommandResultAssert.java:87)
> at
> org.apache.geode.management.internal.cli.commands.GfshHostNameVerificationDistributedTest.validateGfshConnection(GfshHostNameVerificationDistributedTest.java:163)
> at
> org.apache.geode.management.internal.cli.commands.GfshHostNameVerificationDistributedTest.expectConnectionFailureWhenNoHostNameInLocatorKey(GfshHostNameVerificationDistributedTest.java:117)
> org.apache.geode.management.internal.cli.commands.GfshHostNameVerificationDistributedTest
> > expectConnectionFailureWhenWrongHostNameInLocatorKey FAILED
> java.lang.AssertionError:
> Expecting:
> <"Duplicated server name of type 0
> ">
> to contain:
> <"Unable to form SSL connection">
> at
> org.apache.geode.test.junit.assertions.CommandResultAssert.containsOutput(CommandResultAssert.java:87)
> at
> org.apache.geode.management.internal.cli.commands.GfshHostNameVerificationDistributedTest.validateGfshConnection(GfshHostNameVerificationDistributedTest.java:163)
> at
> org.apache.geode.management.internal.cli.commands.GfshHostNameVerificationDistributedTest.expectConnectionFailureWhenWrongHostNameInLocatorKey(GfshHostNameVerificationDistributedTest.java:128)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-7900) GfshHostNameVerificationDistributedTest > expectConnectionFailureWhenNoHostNameInLocatorKey failing on Windows
[
https://issues.apache.org/jira/browse/GEODE-7900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith updated GEODE-7900:
-
Component/s: membership
> GfshHostNameVerificationDistributedTest >
> expectConnectionFailureWhenNoHostNameInLocatorKey failing on Windows
> --
>
> Key: GEODE-7900
> URL: https://issues.apache.org/jira/browse/GEODE-7900
> Project: Geode
> Issue Type: Bug
> Components: configuration, membership
>Reporter: Bill Burcham
>Assignee: Dan Smith
>Priority: Major
>
> failures in these two tests e.g. here
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/IntegrationTestOpenJDK11/builds/1613:
> {code}
> org.apache.geode.management.internal.cli.commands.GfshHostNameVerificationDistributedTest
> > expectConnectionFailureWhenNoHostNameInLocatorKey FAILED
> java.lang.AssertionError:
> Expecting:
> <"Duplicated server name of type 0
> ">
> to contain:
> <"Unable to form SSL connection">
> at
> org.apache.geode.test.junit.assertions.CommandResultAssert.containsOutput(CommandResultAssert.java:87)
> at
> org.apache.geode.management.internal.cli.commands.GfshHostNameVerificationDistributedTest.validateGfshConnection(GfshHostNameVerificationDistributedTest.java:163)
> at
> org.apache.geode.management.internal.cli.commands.GfshHostNameVerificationDistributedTest.expectConnectionFailureWhenNoHostNameInLocatorKey(GfshHostNameVerificationDistributedTest.java:117)
> org.apache.geode.management.internal.cli.commands.GfshHostNameVerificationDistributedTest
> > expectConnectionFailureWhenWrongHostNameInLocatorKey FAILED
> java.lang.AssertionError:
> Expecting:
> <"Duplicated server name of type 0
> ">
> to contain:
> <"Unable to form SSL connection">
> at
> org.apache.geode.test.junit.assertions.CommandResultAssert.containsOutput(CommandResultAssert.java:87)
> at
> org.apache.geode.management.internal.cli.commands.GfshHostNameVerificationDistributedTest.validateGfshConnection(GfshHostNameVerificationDistributedTest.java:163)
> at
> org.apache.geode.management.internal.cli.commands.GfshHostNameVerificationDistributedTest.expectConnectionFailureWhenWrongHostNameInLocatorKey(GfshHostNameVerificationDistributedTest.java:128)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-7901) Redis testGetSet_shouldBeAtomic and testGetRange_rangePastEndOfValue_returnsEmptyString tests failing
Bill Burcham created GEODE-7901:
---
Summary: Redis testGetSet_shouldBeAtomic and
testGetRange_rangePastEndOfValue_returnsEmptyString tests failing
Key: GEODE-7901
URL: https://issues.apache.org/jira/browse/GEODE-7901
Project: Geode
Issue Type: Bug
Components: redis
Reporter: Bill Burcham
Three CI failures recently e.g.
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/IntegrationTestOpenJDK11/builds/1615
{code}
org.apache.geode.redis.StringsIntegrationTest > testGetSet_shouldBeAtomic FAILED
java.util.concurrent.TimeoutException
at java.util.concurrent.FutureTask.get(FutureTask.java:204)
at
org.apache.geode.redis.StringsIntegrationTest.testGetSet_shouldBeAtomic(StringsIntegrationTest.java:284)
java.lang.ClassCastException: class java.lang.Long cannot be cast to class
[B (java.lang.Long and [B are in module java.base of loader 'bootstrap')
at
redis.clients.jedis.Connection.getStatusCodeReply(Connection.java:236)
at redis.clients.jedis.BinaryJedis.flushAll(BinaryJedis.java:599)
at
org.apache.geode.redis.StringsIntegrationTest.flushAll(StringsIntegrationTest.java:82)
org.apache.geode.redis.StringsIntegrationTest >
testGetRange_rangePastEndOfValue_returnsEmptyString FAILED
org.junit.ComparisonFailure: expected:<"[]"> but was:<"[OK]">
at
jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
org.apache.geode.redis.StringsIntegrationTest.testGetRange_rangePastEndOfValue_returnsEmptyString(StringsIntegrationTest.java:209)
{code}
a couple more CI failures:
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/IntegrationTestOpenJDK11/builds/1613
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/IntegrationTestOpenJDK11/builds/1616
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-7901) Redis testGetSet_shouldBeAtomic and testGetRange_rangePastEndOfValue_returnsEmptyString tests failing
[
https://issues.apache.org/jira/browse/GEODE-7901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Burcham reassigned GEODE-7901:
---
Assignee: Bill Burcham
> Redis testGetSet_shouldBeAtomic and
> testGetRange_rangePastEndOfValue_returnsEmptyString tests failing
> -
>
> Key: GEODE-7901
> URL: https://issues.apache.org/jira/browse/GEODE-7901
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Bill Burcham
>Assignee: Bill Burcham
>Priority: Major
>
> Three CI failures recently e.g.
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/IntegrationTestOpenJDK11/builds/1615
> {code}
> org.apache.geode.redis.StringsIntegrationTest > testGetSet_shouldBeAtomic
> FAILED
> java.util.concurrent.TimeoutException
> at java.util.concurrent.FutureTask.get(FutureTask.java:204)
> at
> org.apache.geode.redis.StringsIntegrationTest.testGetSet_shouldBeAtomic(StringsIntegrationTest.java:284)
> java.lang.ClassCastException: class java.lang.Long cannot be cast to
> class [B (java.lang.Long and [B are in module java.base of loader 'bootstrap')
> at
> redis.clients.jedis.Connection.getStatusCodeReply(Connection.java:236)
> at redis.clients.jedis.BinaryJedis.flushAll(BinaryJedis.java:599)
> at
> org.apache.geode.redis.StringsIntegrationTest.flushAll(StringsIntegrationTest.java:82)
> org.apache.geode.redis.StringsIntegrationTest >
> testGetRange_rangePastEndOfValue_returnsEmptyString FAILED
> org.junit.ComparisonFailure: expected:<"[]"> but was:<"[OK]">
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.redis.StringsIntegrationTest.testGetRange_rangePastEndOfValue_returnsEmptyString(StringsIntegrationTest.java:209)
> {code}
> a couple more CI failures:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/IntegrationTestOpenJDK11/builds/1613
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/IntegrationTestOpenJDK11/builds/1616
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-7902) CI Failure: DeploymentManagementRedployDUnitTest.redeployJarsWithNewVersionsOfFunctionsAndMultipleLocators Assertion Failure
Ivan Godwin created GEODE-7902:
--
Summary: CI Failure:
DeploymentManagementRedployDUnitTest.redeployJarsWithNewVersionsOfFunctionsAndMultipleLocators
Assertion Failure
Key: GEODE-7902
URL: https://issues.apache.org/jira/browse/GEODE-7902
Project: Geode
Issue Type: Bug
Reporter: Ivan Godwin
Four failures occurred in recent runs of the new test:
{code:java}
org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest
> redeployJarsWithNewVersionsOfFunctionsAndMultipleLocators FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest$$Lambda$109/1334041298.run
in VM 1 running on Host 58d73054f62c with 4 VMs
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
at
org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:94)
at
org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest.redeployJarsWithNewVersionsOfFunctionsAndMultipleLocators(DeploymentManagementRedployDUnitTest.java:148)
Caused by:
org.junit.ComparisonFailure: expected:<"Version[2]"> but
was:<"Version[1]">
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest.assertThatFunctionHasVersion(DeploymentManagementRedployDUnitTest.java:222)
at
org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest.lambda$redeployJarsWithNewVersionsOfFunctionsAndMultipleLocators$bb17a952$6(DeploymentManagementRedployDUnitTest.java:148)
{code}
redeployJarsWithNewVersionsOfFunctionsAndMultipleLocators
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/1496
redeployJarsWithNewVersionsOfFunctionsAndMultipleLocators
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/1459
redeployJarsWithNewVersionsOfFunctionsAndMultipleLocators
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/1453
redeployJarsWithNewVersionsOfFunctionsAndMultipleLocators
[https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/1435]
Test class and filename also look like they have a typo.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-7903) QueueManagerJUnitTest > testWatchForNewRedundant test fails sometimes
Bill Burcham created GEODE-7903:
---
Summary: QueueManagerJUnitTest > testWatchForNewRedundant test
fails sometimes
Key: GEODE-7903
URL: https://issues.apache.org/jira/browse/GEODE-7903
Project: Geode
Issue Type: Bug
Components: client queues
Reporter: Bill Burcham
This test failed in CI on AdoptOpenJDK11
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/IntegrationTestOpenJDK11/builds/1617
{code}
org.apache.geode.cache.client.internal.QueueManagerJUnitTest >
testWatchForNewRedundant FAILED
java.lang.AssertionError: expected:<[2, 3]> but was:<[2]>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:144)
at
org.apache.geode.cache.client.internal.QueueManagerJUnitTest.assertPortEquals(QueueManagerJUnitTest.java:300)
at
org.apache.geode.cache.client.internal.QueueManagerJUnitTest.testWatchForNewRedundant(QueueManagerJUnitTest.java:239)
{code}
Ran 100x w/ no failure in IntelliJ on Mac on AdoptOpenJDK8
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-7902) CI Failure: DeploymentManagementRedployDUnitTest.redeployJarsWithNewVersionsOfFunctionsAndMultipleLocators Assertion Failure
[
https://issues.apache.org/jira/browse/GEODE-7902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Godwin reassigned GEODE-7902:
--
Assignee: Ivan Godwin
> CI Failure:
> DeploymentManagementRedployDUnitTest.redeployJarsWithNewVersionsOfFunctionsAndMultipleLocators
> Assertion Failure
>
>
> Key: GEODE-7902
> URL: https://issues.apache.org/jira/browse/GEODE-7902
> Project: Geode
> Issue Type: Bug
>Reporter: Ivan Godwin
>Assignee: Ivan Godwin
>Priority: Major
>
> Four failures occurred in recent runs of the new test:
> {code:java}
> org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest
> > redeployJarsWithNewVersionsOfFunctionsAndMultipleLocators FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest$$Lambda$109/1334041298.run
> in VM 1 running on Host 58d73054f62c with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
> at
> org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:94)
> at
> org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest.redeployJarsWithNewVersionsOfFunctionsAndMultipleLocators(DeploymentManagementRedployDUnitTest.java:148)
> Caused by:
> org.junit.ComparisonFailure: expected:<"Version[2]"> but
> was:<"Version[1]">
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest.assertThatFunctionHasVersion(DeploymentManagementRedployDUnitTest.java:222)
> at
> org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest.lambda$redeployJarsWithNewVersionsOfFunctionsAndMultipleLocators$bb17a952$6(DeploymentManagementRedployDUnitTest.java:148)
> {code}
> redeployJarsWithNewVersionsOfFunctionsAndMultipleLocators
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/1496
> redeployJarsWithNewVersionsOfFunctionsAndMultipleLocators
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/1459
> redeployJarsWithNewVersionsOfFunctionsAndMultipleLocators
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/1453
> redeployJarsWithNewVersionsOfFunctionsAndMultipleLocators
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/1435]
> Test class and filename also look like they have a typo.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-7902) CI Failure: DeploymentManagementRedployDUnitTest.redeployJarsWithNewVersionsOfFunctionsAndMultipleLocators Assertion Failure
[
https://issues.apache.org/jira/browse/GEODE-7902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Godwin reassigned GEODE-7902:
--
Assignee: Jinmei Liao (was: Ivan Godwin)
> CI Failure:
> DeploymentManagementRedployDUnitTest.redeployJarsWithNewVersionsOfFunctionsAndMultipleLocators
> Assertion Failure
>
>
> Key: GEODE-7902
> URL: https://issues.apache.org/jira/browse/GEODE-7902
> Project: Geode
> Issue Type: Bug
>Reporter: Ivan Godwin
>Assignee: Jinmei Liao
>Priority: Major
>
> Four failures occurred in recent runs of the new test:
> {code:java}
> org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest
> > redeployJarsWithNewVersionsOfFunctionsAndMultipleLocators FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest$$Lambda$109/1334041298.run
> in VM 1 running on Host 58d73054f62c with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
> at
> org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:94)
> at
> org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest.redeployJarsWithNewVersionsOfFunctionsAndMultipleLocators(DeploymentManagementRedployDUnitTest.java:148)
> Caused by:
> org.junit.ComparisonFailure: expected:<"Version[2]"> but
> was:<"Version[1]">
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest.assertThatFunctionHasVersion(DeploymentManagementRedployDUnitTest.java:222)
> at
> org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest.lambda$redeployJarsWithNewVersionsOfFunctionsAndMultipleLocators$bb17a952$6(DeploymentManagementRedployDUnitTest.java:148)
> {code}
> redeployJarsWithNewVersionsOfFunctionsAndMultipleLocators
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/1496
> redeployJarsWithNewVersionsOfFunctionsAndMultipleLocators
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/1459
> redeployJarsWithNewVersionsOfFunctionsAndMultipleLocators
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/1453
> redeployJarsWithNewVersionsOfFunctionsAndMultipleLocators
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/1435]
> Test class and filename also look like they have a typo.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-7870) PubSubIntegrationTest is still flaky
[
https://issues.apache.org/jira/browse/GEODE-7870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson reassigned GEODE-7870:
--
Assignee: Mark Hanson
> PubSubIntegrationTest is still flaky
>
>
> Key: GEODE-7870
> URL: https://issues.apache.org/jira/browse/GEODE-7870
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Jens Deppe
>Assignee: Mark Hanson
>Priority: Major
>
> This test still fails intermittently (but much less than it used to be).
> Here is an example failure:
> {noformat}
> org.apache.geode.redis.PubSubIntegrationTest > testPatternSubscribe FAILED
> java.lang.AssertionError:
> Expecting:
> <["hello"]>
> to contain exactly (and in same order):
> <["hello"]>
> but could not find the following elements:
> <["hello"]>
> at
> org.apache.geode.redis.PubSubIntegrationTest.testPatternSubscribe(PubSubIntegrationTest.java:254)
> org.apache.geode.redis.PubSubIntegrationTest > testPatternWithoutAGlob FAILED
> org.awaitility.core.ConditionTimeoutException: Condition with lambda
> expression in org.apache.geode.redis.PubSubIntegrationTest that uses
> org.apache.geode.redis.mocks.MockSubscriber was not fulfilled within 300
> seconds.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:145)
> at
> org.awaitility.core.CallableCondition.await(CallableCondition.java:79)
> at
> org.awaitility.core.CallableCondition.await(CallableCondition.java:27)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:902)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:860)
> at
> org.apache.geode.redis.PubSubIntegrationTest.waitFor(PubSubIntegrationTest.java:324)
> at
> org.apache.geode.redis.PubSubIntegrationTest.testPatternWithoutAGlob(PubSubIntegrationTest.java:301)
> org.apache.geode.redis.PubSubIntegrationTest > testTwoSubscribersOneChannel
> FAILED
> org.awaitility.core.ConditionTimeoutException: Condition with lambda
> expression in org.apache.geode.redis.PubSubIntegrationTest that uses
> org.apache.geode.redis.mocks.MockSubscriber was not fulfilled within 300
> seconds.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:145)
> at
> org.awaitility.core.CallableCondition.await(CallableCondition.java:79)
> at
> org.awaitility.core.CallableCondition.await(CallableCondition.java:27)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:902)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:860)
> at
> org.apache.geode.redis.PubSubIntegrationTest.waitFor(PubSubIntegrationTest.java:324)
> at
> org.apache.geode.redis.PubSubIntegrationTest.testTwoSubscribersOneChannel(PubSubIntegrationTest.java:166)
> org.apache.geode.redis.PubSubIntegrationTest >
> testOneSubscriberSubscribingToTwoChannels FAILED
> org.awaitility.core.ConditionTimeoutException: Condition with lambda
> expression in org.apache.geode.redis.PubSubIntegrationTest that uses
> org.apache.geode.redis.mocks.MockSubscriber was not fulfilled within 300
> seconds.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:145)
> at
> org.awaitility.core.CallableCondition.await(CallableCondition.java:79)
> at
> org.awaitility.core.CallableCondition.await(CallableCondition.java:27)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:902)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:860)
> at
> org.apache.geode.redis.PubSubIntegrationTest.waitFor(PubSubIntegrationTest.java:324)
> at
> org.apache.geode.redis.PubSubIntegrationTest.testOneSubscriberSubscribingToTwoChannels(PubSubIntegrationTest.java:136)
> org.apache.geode.redis.PubSubIntegrationTest > testPatternAndRegularSubscribe
> FAILED
> org.awaitility.core.ConditionTimeoutException: Condition with lambda
> expression in org.apache.geode.redis.PubSubIntegrationTest that uses
> org.apache.geode.redis.mocks.MockSubscriber was not fulfilled within 300
> seconds.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:145)
> at
> org.awaitility.core.CallableCondition.await(CallableCondition.java:79)
> at
> org.awaitility.core.CallableCondition.await(CallableCondition.java:27)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:902)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:860)
> at
> org.apache.geode.redis.PubSubIntegrationTest.waitFor(PubSubIntegrationTest.java:324)
> at
> org.apache.geode.redis.PubSubIntegrationTest.testPatternAndRegular
[jira] [Assigned] (GEODE-7870) PubSubIntegrationTest is still flaky
[
https://issues.apache.org/jira/browse/GEODE-7870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson reassigned GEODE-7870:
--
Assignee: (was: Mark Hanson)
> PubSubIntegrationTest is still flaky
>
>
> Key: GEODE-7870
> URL: https://issues.apache.org/jira/browse/GEODE-7870
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Jens Deppe
>Priority: Major
>
> This test still fails intermittently (but much less than it used to be).
> Here is an example failure:
> {noformat}
> org.apache.geode.redis.PubSubIntegrationTest > testPatternSubscribe FAILED
> java.lang.AssertionError:
> Expecting:
> <["hello"]>
> to contain exactly (and in same order):
> <["hello"]>
> but could not find the following elements:
> <["hello"]>
> at
> org.apache.geode.redis.PubSubIntegrationTest.testPatternSubscribe(PubSubIntegrationTest.java:254)
> org.apache.geode.redis.PubSubIntegrationTest > testPatternWithoutAGlob FAILED
> org.awaitility.core.ConditionTimeoutException: Condition with lambda
> expression in org.apache.geode.redis.PubSubIntegrationTest that uses
> org.apache.geode.redis.mocks.MockSubscriber was not fulfilled within 300
> seconds.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:145)
> at
> org.awaitility.core.CallableCondition.await(CallableCondition.java:79)
> at
> org.awaitility.core.CallableCondition.await(CallableCondition.java:27)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:902)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:860)
> at
> org.apache.geode.redis.PubSubIntegrationTest.waitFor(PubSubIntegrationTest.java:324)
> at
> org.apache.geode.redis.PubSubIntegrationTest.testPatternWithoutAGlob(PubSubIntegrationTest.java:301)
> org.apache.geode.redis.PubSubIntegrationTest > testTwoSubscribersOneChannel
> FAILED
> org.awaitility.core.ConditionTimeoutException: Condition with lambda
> expression in org.apache.geode.redis.PubSubIntegrationTest that uses
> org.apache.geode.redis.mocks.MockSubscriber was not fulfilled within 300
> seconds.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:145)
> at
> org.awaitility.core.CallableCondition.await(CallableCondition.java:79)
> at
> org.awaitility.core.CallableCondition.await(CallableCondition.java:27)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:902)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:860)
> at
> org.apache.geode.redis.PubSubIntegrationTest.waitFor(PubSubIntegrationTest.java:324)
> at
> org.apache.geode.redis.PubSubIntegrationTest.testTwoSubscribersOneChannel(PubSubIntegrationTest.java:166)
> org.apache.geode.redis.PubSubIntegrationTest >
> testOneSubscriberSubscribingToTwoChannels FAILED
> org.awaitility.core.ConditionTimeoutException: Condition with lambda
> expression in org.apache.geode.redis.PubSubIntegrationTest that uses
> org.apache.geode.redis.mocks.MockSubscriber was not fulfilled within 300
> seconds.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:145)
> at
> org.awaitility.core.CallableCondition.await(CallableCondition.java:79)
> at
> org.awaitility.core.CallableCondition.await(CallableCondition.java:27)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:902)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:860)
> at
> org.apache.geode.redis.PubSubIntegrationTest.waitFor(PubSubIntegrationTest.java:324)
> at
> org.apache.geode.redis.PubSubIntegrationTest.testOneSubscriberSubscribingToTwoChannels(PubSubIntegrationTest.java:136)
> org.apache.geode.redis.PubSubIntegrationTest > testPatternAndRegularSubscribe
> FAILED
> org.awaitility.core.ConditionTimeoutException: Condition with lambda
> expression in org.apache.geode.redis.PubSubIntegrationTest that uses
> org.apache.geode.redis.mocks.MockSubscriber was not fulfilled within 300
> seconds.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:145)
> at
> org.awaitility.core.CallableCondition.await(CallableCondition.java:79)
> at
> org.awaitility.core.CallableCondition.await(CallableCondition.java:27)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:902)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:860)
> at
> org.apache.geode.redis.PubSubIntegrationTest.waitFor(PubSubIntegrationTest.java:324)
> at
> org.apache.geode.redis.PubSubIntegrationTest.testPatternAndRegularSubscribe(PubSubIntegrat
[jira] [Commented] (GEODE-7889) CI Failure: CloseConnectionTest.sharedSenderShouldRecoverFromClosedSocket
[
https://issues.apache.org/jira/browse/GEODE-7889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17065358#comment-17065358
]
ASF subversion and git services commented on GEODE-7889:
Commit e1949a40c35f9df5aae6bf54baa96a44623d2e69 in geode's branch
refs/heads/develop from Ivan Godwin
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=e1949a4 ]
GEODE-7889: Fix CloseConnectionTest
- Use await().untilAsserted() to allow connections to settle
- Use setup and tear down methods
- Do not extend CacheTestCase as it is an empty abstract with a deprecated super
> CI Failure: CloseConnectionTest.sharedSenderShouldRecoverFromClosedSocket
> --
>
> Key: GEODE-7889
> URL: https://issues.apache.org/jira/browse/GEODE-7889
> Project: Geode
> Issue Type: Bug
>Reporter: Ivan Godwin
>Assignee: Ivan Godwin
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
>
> Failed with the following exception:
> {code:java}
> org.apache.geode.internal.tcp.CloseConnectionTest >
> sharedSenderShouldRecoverFromClosedSocket FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.tcp.CloseConnectionTest$$Lambda$33/1407663190.run
> in VM 1 running on Host 7418acf65cfc with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
> at
> org.apache.geode.internal.tcp.CloseConnectionTest.sharedSenderShouldRecoverFromClosedSocket(CloseConnectionTest.java:62)
> Caused by:
> org.junit.ComparisonFailure: expected:<[2]> but was:<[1]>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.tcp.CloseConnectionTest.lambda$sharedSenderShouldRecoverFromClosedSocket$bb17a952$5(CloseConnectionTest.java:64)
> {code}
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/1214
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/1209
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/1202
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-7889) CI Failure: CloseConnectionTest.sharedSenderShouldRecoverFromClosedSocket
[
https://issues.apache.org/jira/browse/GEODE-7889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Godwin updated GEODE-7889:
---
Labels: flaky (was: )
> CI Failure: CloseConnectionTest.sharedSenderShouldRecoverFromClosedSocket
> --
>
> Key: GEODE-7889
> URL: https://issues.apache.org/jira/browse/GEODE-7889
> Project: Geode
> Issue Type: Bug
>Reporter: Ivan Godwin
>Assignee: Ivan Godwin
>Priority: Major
> Labels: flaky
> Time Spent: 20m
> Remaining Estimate: 0h
>
>
> Failed with the following exception:
> {code:java}
> org.apache.geode.internal.tcp.CloseConnectionTest >
> sharedSenderShouldRecoverFromClosedSocket FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.tcp.CloseConnectionTest$$Lambda$33/1407663190.run
> in VM 1 running on Host 7418acf65cfc with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
> at
> org.apache.geode.internal.tcp.CloseConnectionTest.sharedSenderShouldRecoverFromClosedSocket(CloseConnectionTest.java:62)
> Caused by:
> org.junit.ComparisonFailure: expected:<[2]> but was:<[1]>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.tcp.CloseConnectionTest.lambda$sharedSenderShouldRecoverFromClosedSocket$bb17a952$5(CloseConnectionTest.java:64)
> {code}
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/1214
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/1209
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/1202
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-7889) CI Failure: CloseConnectionTest.sharedSenderShouldRecoverFromClosedSocket
[
https://issues.apache.org/jira/browse/GEODE-7889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Godwin resolved GEODE-7889.
Fix Version/s: 1.13.0
Resolution: Fixed
> CI Failure: CloseConnectionTest.sharedSenderShouldRecoverFromClosedSocket
> --
>
> Key: GEODE-7889
> URL: https://issues.apache.org/jira/browse/GEODE-7889
> Project: Geode
> Issue Type: Bug
>Reporter: Ivan Godwin
>Assignee: Ivan Godwin
>Priority: Major
> Labels: flaky
> Fix For: 1.13.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
>
> Failed with the following exception:
> {code:java}
> org.apache.geode.internal.tcp.CloseConnectionTest >
> sharedSenderShouldRecoverFromClosedSocket FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.tcp.CloseConnectionTest$$Lambda$33/1407663190.run
> in VM 1 running on Host 7418acf65cfc with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
> at
> org.apache.geode.internal.tcp.CloseConnectionTest.sharedSenderShouldRecoverFromClosedSocket(CloseConnectionTest.java:62)
> Caused by:
> org.junit.ComparisonFailure: expected:<[2]> but was:<[1]>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.tcp.CloseConnectionTest.lambda$sharedSenderShouldRecoverFromClosedSocket$bb17a952$5(CloseConnectionTest.java:64)
> {code}
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/1214
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/1209
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/1202
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
