[jira] [Assigned] (GEODE-7670) Partitioned Region clear operations can occur during concurrent data operations
[ https://issues.apache.org/jira/browse/GEODE-7670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juan Ramos reassigned GEODE-7670: - Assignee: Juan Ramos > Partitioned Region clear operations can occur during concurrent data > operations > --- > > Key: GEODE-7670 > URL: https://issues.apache.org/jira/browse/GEODE-7670 > Project: Geode > Issue Type: Sub-task > Components: regions >Reporter: Nabarun Nag >Assignee: Juan Ramos >Priority: Major > Labels: GeodeCommons > > Clear operations are successful when concurrent read/write operations occur. > Ensure there are test coverage for this use case and modify the code needed > to enable this. > Acceptance : > * Passing DUnit tests where clear operations are successful on partitioned > region with > * concurrent puts (writes) and clear op > * concurrent gets (reads) and clear op > * Test coverage to when a member departs in this scenario > * Test coverage to when a member restarts in this scenario > * Unit tests with complete code coverage for the newly written code. -- 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=17065888#comment-17065888
]
ASF subversion and git services commented on GEODE-7894:
Commit d446cd620f2ebc32355594793b37d6ea437857a1 in geode's branch
refs/heads/feature/GEODE-6008b from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=d446cd6 ]
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-7893) geode-lucene POM dependencies are not correct
[ https://issues.apache.org/jira/browse/GEODE-7893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17065877#comment-17065877 ] ASF subversion and git services commented on GEODE-7893: Commit 9cddaec75a2cdfbc01d01cac26c9cb46a61e4692 in geode's branch refs/heads/feature/GEODE-6008b from Robert Houghton [ https://gitbox.apache.org/repos/asf?p=geode.git;h=9cddaec ] GEODE-7893: Fix Analyzer dependency in geode-lucene (#4829) * GEODE-7893: Fix Analyzer dependency in geode-lucene lucene-core and geode-core are `api` not `implementation` dependencies. > geode-lucene POM dependencies are not correct > - > > Key: GEODE-7893 > URL: https://issues.apache.org/jira/browse/GEODE-7893 > Project: Geode > Issue Type: Bug > Components: build, lucene >Reporter: Robert Houghton >Assignee: Robert Houghton >Priority: Major > Fix For: 1.13.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The LuceneIndexFactoryBean configures Lucene Analyser, which is not 'api' > dependency in geode-lucene -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7884) server hangs due to IllegalStateException
[
https://issues.apache.org/jira/browse/GEODE-7884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17065881#comment-17065881
]
ASF subversion and git services commented on GEODE-7884:
Commit 2d2a3f80bd5053749963889c1898df48e9aa0be7 in geode's branch
refs/heads/feature/GEODE-6008b from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=2d2a3f8 ]
GEODE-7884: server hangs due to IllegalStateException (#4822)
* GEODE-7884: server hangs due to IllegalStateException
Added cancellation check before scheduling an idle-timeout or
ack-wait-threshold timer task. I had to add a new method to
SystemTimerTask and then noticed there were no tests for SystemTimer, so
I cleaned up that class and added tests.
* adding missing copyright header to new test
* fixing LGTM issues
* reinstating 'continue' when encountering a null timer during a sweep
* addressing Bill's comments
renamed swarm everwhere
made the collection of timers associated with a DistributedSystem into a Set
made timer task variables in Connection volatile
added checks in tasks to cancel themselves if their Connection is closed
> server hangs due to IllegalStateException
> -
>
> Key: GEODE-7884
> URL: https://issues.apache.org/jira/browse/GEODE-7884
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Fix For: 1.13.0
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> An application hung on a cache operation:
> {noformat}
>java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xf61617b8> (a
> java.util.concurrent.CountDownLatch$Sync)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
> at
> org.apache.geode.internal.util.concurrent.StoppableCountDownLatch.await(StoppableCountDownLatch.java:72)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.basicWait(ReplyProcessor21.java:731)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:802)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:779)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:865)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation.waitForAckIfNeeded(DistributedCacheOperation.java:779)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation._distribute(DistributedCacheOperation.java:676)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation.startOperation(DistributedCacheOperation.java:277)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation.distribute(DistributedCacheOperation.java:318)
> at
> org.apache.geode.internal.cache.DistributedRegion.distributeUpdate(DistributedRegion.java:514)
> at
> org.apache.geode.internal.cache.DistributedRegion.basicPutPart3(DistributedRegion.java:492)
> at
> org.apache.geode.internal.cache.map.RegionMapPut.doAfterCompletionActions(RegionMapPut.java:307)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.doPut(AbstractRegionMapPut.java:185)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut$$Lambda$243/1152982325.run(Unknown
> Source)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.runWhileLockedForCacheModification(AbstractRegionMapPut.java:119)
> at
> org.apache.geode.internal.cache.map.RegionMapPut.runWhileLockedForCacheModification(RegionMapPut.java:161)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.put(AbstractRegionMapPut.java:169)
> at
> org.apache.geode.internal.cache.AbstractRegionMap.basicPut(AbstractRegionMap.java:2044)
> at
> org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5602)
> at
> org.apache.geode.internal.cache.DistributedRegion.virtualPut(DistributedRegion.java:387)
> at
> org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5580)
> at
> org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:156)
> at
> org.apache.geode.internal.cache.LocalRegion.basicPut(LocalRegion.java:5038)
>
[jira] [Commented] (GEODE-7852) Add client side configuration option to support a SNI proxy
[ https://issues.apache.org/jira/browse/GEODE-7852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17065883#comment-17065883 ] ASF subversion and git services commented on GEODE-7852: Commit 53f1e1a81c3b58989a835d37f94466eb3dfc752f in geode's branch refs/heads/feature/GEODE-6008b from Dan Smith [ https://gitbox.apache.org/repos/asf?p=geode.git;h=53f1e1a ] GEODE-7852: Adding a SocketFactory configuration for client Pools (#4830) Adding the ability to provide a SocketFactory to a client pool for use in creating sockets. Adding an implementation of this SocketFactory that configures the pool to use an SNI proxy. Adding an automated test of the SniSocketFactory that uses docker compose to use a real SNI proxy and geode servers that are not reachable without going through the proxy. Co-authored-by: Bill Burcham > Add client side configuration option to support a SNI proxy > --- > > Key: GEODE-7852 > URL: https://issues.apache.org/jira/browse/GEODE-7852 > Project: Geode > Issue Type: Improvement > Components: client/server, membership >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Fix For: 1.13.0 > > Time Spent: 1.5h > Remaining Estimate: 0h > > Add an option to the client side configuration to support a the use of a [SNI > proxy|https://www.bamsoftware.com/computers/sniproxy/]. > See also GEODE-7837, which adds a system property to support a SNI proxy. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[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=17065885#comment-17065885
]
ASF subversion and git services commented on GEODE-7889:
Commit e1949a40c35f9df5aae6bf54baa96a44623d2e69 in geode's branch
refs/heads/feature/GEODE-6008b 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
> 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)
[jira] [Commented] (GEODE-7893) geode-lucene POM dependencies are not correct
[ https://issues.apache.org/jira/browse/GEODE-7893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17065878#comment-17065878 ] ASF subversion and git services commented on GEODE-7893: Commit 9cddaec75a2cdfbc01d01cac26c9cb46a61e4692 in geode's branch refs/heads/feature/GEODE-6008b from Robert Houghton [ https://gitbox.apache.org/repos/asf?p=geode.git;h=9cddaec ] GEODE-7893: Fix Analyzer dependency in geode-lucene (#4829) * GEODE-7893: Fix Analyzer dependency in geode-lucene lucene-core and geode-core are `api` not `implementation` dependencies. > geode-lucene POM dependencies are not correct > - > > Key: GEODE-7893 > URL: https://issues.apache.org/jira/browse/GEODE-7893 > Project: Geode > Issue Type: Bug > Components: build, lucene >Reporter: Robert Houghton >Assignee: Robert Houghton >Priority: Major > Fix For: 1.13.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The LuceneIndexFactoryBean configures Lucene Analyser, which is not 'api' > dependency in geode-lucene -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7895) Create integration tests for Expire Command in Redis Adapter
[ https://issues.apache.org/jira/browse/GEODE-7895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17065879#comment-17065879 ] ASF subversion and git services commented on GEODE-7895: Commit f84d3e645d2b67e362534a01bacf31337896d186 in geode's branch refs/heads/feature/GEODE-6008b from John Hutchison [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f84d3e6 ] GEODE-7895:Create integration tests for EXPIRE command in Redis Adapter (#4831) Co-authored-by: John Hutchison > Create integration tests for Expire Command in Redis Adapter > > > Key: GEODE-7895 > URL: https://issues.apache.org/jira/browse/GEODE-7895 > Project: Geode > Issue Type: Test > Components: redis >Reporter: John Hutchison >Priority: Major > Fix For: 1.13.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[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=17065884#comment-17065884 ] ASF subversion and git services commented on GEODE-7851: Commit 578cb0756710cf18ba345e125601e057ec413ebf in geode's branch refs/heads/feature/GEODE-6008b 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 20m > 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-7873) CI Failure: DeployJarWithSSLDUnitTest.deployJarWithMultipleLocators
[
https://issues.apache.org/jira/browse/GEODE-7873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17065890#comment-17065890
]
ASF subversion and git services commented on GEODE-7873:
Commit d446cd620f2ebc32355594793b37d6ea437857a1 in geode's branch
refs/heads/feature/GEODE-6008b from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=d446cd6 ]
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-7886) Update strings tests to cover sad as well as happy paths
[ https://issues.apache.org/jira/browse/GEODE-7886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17065882#comment-17065882 ] ASF subversion and git services commented on GEODE-7886: Commit 39a8eaa76e7910f18a735342c34fdb82b7362ca2 in geode's branch refs/heads/feature/GEODE-6008b from Ray Ingles [ https://gitbox.apache.org/repos/asf?p=geode.git;h=39a8eaa ] GEODE-7886 Update strings tests to cover sad as well as happy paths (#4821) Co-authored-by: Sarah Abbey > Update strings tests to cover sad as well as happy paths > > > Key: GEODE-7886 > URL: https://issues.apache.org/jira/browse/GEODE-7886 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Raymond Ingles >Priority: Major > Fix For: 1.13.0 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > This patch updates the tests for the Redis String commands to cover error > conditions and edge cases, as well as concurrent executions. It updates the > command executor unit tests to cover low-level API errors (incorrect > arguments, etc.). -- 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=17065886#comment-17065886
]
ASF subversion and git services commented on GEODE-6008:
Commit d446cd620f2ebc32355594793b37d6ea437857a1 in geode's branch
refs/heads/feature/GEODE-6008b from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=d446cd6 ]
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: 0.5h
> 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.inv
[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=17065891#comment-17065891 ] ASF subversion and git services commented on GEODE-7806: Commit d446cd620f2ebc32355594793b37d6ea437857a1 in geode's branch refs/heads/feature/GEODE-6008b from Bruce Schuchardt [ https://gitbox.apache.org/repos/asf?p=geode.git;h=d446cd6 ] 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-7727) Geode P2P connection hanging
[
https://issues.apache.org/jira/browse/GEODE-7727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17065887#comment-17065887
]
ASF subversion and git services commented on GEODE-7727:
Commit d446cd620f2ebc32355594793b37d6ea437857a1 in geode's branch
refs/heads/feature/GEODE-6008b from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=d446cd6 ]
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-7884) server hangs due to IllegalStateException
[
https://issues.apache.org/jira/browse/GEODE-7884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17065880#comment-17065880
]
ASF subversion and git services commented on GEODE-7884:
Commit 2d2a3f80bd5053749963889c1898df48e9aa0be7 in geode's branch
refs/heads/feature/GEODE-6008b from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=2d2a3f8 ]
GEODE-7884: server hangs due to IllegalStateException (#4822)
* GEODE-7884: server hangs due to IllegalStateException
Added cancellation check before scheduling an idle-timeout or
ack-wait-threshold timer task. I had to add a new method to
SystemTimerTask and then noticed there were no tests for SystemTimer, so
I cleaned up that class and added tests.
* adding missing copyright header to new test
* fixing LGTM issues
* reinstating 'continue' when encountering a null timer during a sweep
* addressing Bill's comments
renamed swarm everwhere
made the collection of timers associated with a DistributedSystem into a Set
made timer task variables in Connection volatile
added checks in tasks to cancel themselves if their Connection is closed
> server hangs due to IllegalStateException
> -
>
> Key: GEODE-7884
> URL: https://issues.apache.org/jira/browse/GEODE-7884
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Fix For: 1.13.0
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> An application hung on a cache operation:
> {noformat}
>java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xf61617b8> (a
> java.util.concurrent.CountDownLatch$Sync)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
> at
> org.apache.geode.internal.util.concurrent.StoppableCountDownLatch.await(StoppableCountDownLatch.java:72)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.basicWait(ReplyProcessor21.java:731)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:802)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:779)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:865)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation.waitForAckIfNeeded(DistributedCacheOperation.java:779)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation._distribute(DistributedCacheOperation.java:676)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation.startOperation(DistributedCacheOperation.java:277)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation.distribute(DistributedCacheOperation.java:318)
> at
> org.apache.geode.internal.cache.DistributedRegion.distributeUpdate(DistributedRegion.java:514)
> at
> org.apache.geode.internal.cache.DistributedRegion.basicPutPart3(DistributedRegion.java:492)
> at
> org.apache.geode.internal.cache.map.RegionMapPut.doAfterCompletionActions(RegionMapPut.java:307)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.doPut(AbstractRegionMapPut.java:185)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut$$Lambda$243/1152982325.run(Unknown
> Source)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.runWhileLockedForCacheModification(AbstractRegionMapPut.java:119)
> at
> org.apache.geode.internal.cache.map.RegionMapPut.runWhileLockedForCacheModification(RegionMapPut.java:161)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.put(AbstractRegionMapPut.java:169)
> at
> org.apache.geode.internal.cache.AbstractRegionMap.basicPut(AbstractRegionMap.java:2044)
> at
> org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5602)
> at
> org.apache.geode.internal.cache.DistributedRegion.virtualPut(DistributedRegion.java:387)
> at
> org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5580)
> at
> org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:156)
> at
> org.apache.geode.internal.cache.LocalRegion.basicPut(LocalRegion.java:5038)
>
[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=17065889#comment-17065889
]
ASF subversion and git services commented on GEODE-7871:
Commit d446cd620f2ebc32355594793b37d6ea437857a1 in geode's branch
refs/heads/feature/GEODE-6008b from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=d446cd6 ]
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-7887) Remove references to long-ago-removed API from doc comments
[ https://issues.apache.org/jira/browse/GEODE-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17065908#comment-17065908 ] ASF subversion and git services commented on GEODE-7887: Commit bc404f32ac5732bb3922be7cebd713c8f768b24b in geode-native's branch refs/heads/develop from Blake Bender [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=bc404f3 ] GEODE-7887: Remove reference to nonexistent API from docs (#584) > Remove references to long-ago-removed API from doc comments > --- > > Key: GEODE-7887 > URL: https://issues.apache.org/jira/browse/GEODE-7887 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Blake Bender >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > RegionAttributesFactory::setClientNotificationEnabled is mentioned > prominently in the doc comments for Region on the C++ side, and > ISubscriptionService in .net. There is no such thing as > RegionAttributesFactory::setClientNotificationEnabled, and never has been, > according to our Git history. setClientNotificationEnabled is a protected > method on an internal class. These doc comments may reflect a reality that > existed at some point in time, but there's no evidence of it in the code > base, and they certainly aren't applicable at this time. Let's remove them. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7852) Add client side configuration option to support a SNI proxy
[ https://issues.apache.org/jira/browse/GEODE-7852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17065966#comment-17065966 ] ASF subversion and git services commented on GEODE-7852: Commit cf0e12856ddc8d5cd0c468d64c462b6bd29c42a2 in geode's branch refs/heads/develop from Dan Smith [ https://gitbox.apache.org/repos/asf?p=geode.git;h=cf0e128 ] GEODE-7852: Ignore ClientSNIAcceptanceTest on windows (#4838) The rule to mark this test ignored has to run before the docker compose rule, to prevent the test from failing first. > Add client side configuration option to support a SNI proxy > --- > > Key: GEODE-7852 > URL: https://issues.apache.org/jira/browse/GEODE-7852 > Project: Geode > Issue Type: Improvement > Components: client/server, membership >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Fix For: 1.13.0 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > Add an option to the client side configuration to support a the use of a [SNI > proxy|https://www.bamsoftware.com/computers/sniproxy/]. > See also GEODE-7837, which adds a system property to support a SNI proxy. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7826) met error when run rebalance by REST API on running 2 locators of 1 vm
[
https://issues.apache.org/jira/browse/GEODE-7826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17065991#comment-17065991
]
ASF subversion and git services commented on GEODE-7826:
Commit 9700bbc34549886c462ea520de861b827a6267d5 in geode's branch
refs/heads/develop from Darrel Schneider
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=9700bbc ]
GEODE-7826: start jmx-manager when the Management Rest Service is (#4820)
* Before the geode management rest service web app is added,
the code now starts the jmx-manager.
* Since the locator currently just logs a message if the management rest
service can not be started, this is now also the behavior if the
jmx-manager can not be started on behalf of the management rest service.
If that happens the management rest service will not be available and
you will get a warning logged describing why the jmx-manager could not
be started.
> met error when run rebalance by REST API on running 2 locators of 1 vm
> --
>
> Key: GEODE-7826
> URL: https://issues.apache.org/jira/browse/GEODE-7826
> Project: Geode
> Issue Type: Bug
> Components: management, rest (admin)
>Reporter: Gang Yan
>Assignee: Darrel Schneider
>Priority: Major
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> the reproduced steps:
> 1. gfsh start locator --port=0 --http-service-port=8081 --name=loc1
> 2. gfsh start locator --port=0 --name=loc2
> 3. gfsh start server --server-port=0 --name=s1
> 4. gfsh create region --name=/regionTest --type=PARTITION
> 5. java code to put 10 million data to regionTest
> 6. gfsh start server --server-port=0 --name=s2
> 7.run rebalance by [post] "
> http://127.0.0.1:7070/management/v1/operations/rebalances";
> 8. run [GET]"http://127.0.0.1:8081/management/v1/operations/rebalances";
> 9. met the following error
> {code:java}
> {
> "statusCode": "ERROR",
> "links": {
> "self":
> "http://127.0.0.1:7070/management/v1/operations/rebalances/3bb2f394-3d21-4076-8c24-3cf3ce7bbbea";,
> "list": "http://127.0.0.1:7070/management/v1/operations/rebalances";
> },
> "operationStart": "2020-02-26T22:06:44.601Z",
> "operationEnd": "2020-02-26T22:06:44.603Z",
> "operationId": "3bb2f394-3d21-4076-8c24-3cf3ce7bbbea",
> "operation": {
> "simulate": false
> },
> "throwable": {
> "stackTrace": [
> {
> "methodName": "getMemberRegionList",
> "fileName": "RebalanceOperationPerformer.java",
> "lineNumber": 208,
> "className":
> "org.apache.geode.management.internal.operation.RebalanceOperationPerformer",
> "nativeMethod": false
> },
> {
> "methodName": "executeRebalanceOnDS",
> "fileName": "RebalanceOperationPerformer.java",
> "lineNumber": 326,
> "className":
> "org.apache.geode.management.internal.operation.RebalanceOperationPerformer",
> "nativeMethod": false
> },
> {
> "methodName": "perform",
> "fileName": "RebalanceOperationPerformer.java",
> "lineNumber": 91,
> "className":
> "org.apache.geode.management.internal.operation.RebalanceOperationPerformer",
> "nativeMethod": false
> },
> {
> "methodName": "lambda$submit$0",
> "fileName": "OperationManager.java",
> "lineNumber": 67,
> "className":
> "org.apache.geode.management.internal.operation.OperationManager",
> "nativeMethod": false
> },
> {
> "methodName": "run",
> "fileName": "CompletableFuture.java",
> "lineNumber": 1590,
> "className":
> "java.util.concurrent.CompletableFuture$AsyncSupply",
> "nativeMethod": false
> },
> {
> "methodName": "run",
> "fileName": "Thread.java",
> "lineNumber": 748,
> "className": "java.lang.Thread",
> "nativeMethod": false
> }
> ]
> }
> }
> {code}
> expected things, 1 of the followings:
> 1. stop or forbid users to run rebalance on the non-jmxManager locator
> 2. return instructive info to let users find proper way to run rebalance
> 3. stop or forbid a REST API for Management to run , when there is no
> jmx-manager on the locator.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-7826) met error when run rebalance by REST API on running 2 locators of 1 vm
[
https://issues.apache.org/jira/browse/GEODE-7826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider resolved GEODE-7826.
-
Fix Version/s: 1.13.0
Resolution: Fixed
> met error when run rebalance by REST API on running 2 locators of 1 vm
> --
>
> Key: GEODE-7826
> URL: https://issues.apache.org/jira/browse/GEODE-7826
> Project: Geode
> Issue Type: Bug
> Components: management, rest (admin)
>Reporter: Gang Yan
>Assignee: Darrel Schneider
>Priority: Major
> Fix For: 1.13.0
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> the reproduced steps:
> 1. gfsh start locator --port=0 --http-service-port=8081 --name=loc1
> 2. gfsh start locator --port=0 --name=loc2
> 3. gfsh start server --server-port=0 --name=s1
> 4. gfsh create region --name=/regionTest --type=PARTITION
> 5. java code to put 10 million data to regionTest
> 6. gfsh start server --server-port=0 --name=s2
> 7.run rebalance by [post] "
> http://127.0.0.1:7070/management/v1/operations/rebalances";
> 8. run [GET]"http://127.0.0.1:8081/management/v1/operations/rebalances";
> 9. met the following error
> {code:java}
> {
> "statusCode": "ERROR",
> "links": {
> "self":
> "http://127.0.0.1:7070/management/v1/operations/rebalances/3bb2f394-3d21-4076-8c24-3cf3ce7bbbea";,
> "list": "http://127.0.0.1:7070/management/v1/operations/rebalances";
> },
> "operationStart": "2020-02-26T22:06:44.601Z",
> "operationEnd": "2020-02-26T22:06:44.603Z",
> "operationId": "3bb2f394-3d21-4076-8c24-3cf3ce7bbbea",
> "operation": {
> "simulate": false
> },
> "throwable": {
> "stackTrace": [
> {
> "methodName": "getMemberRegionList",
> "fileName": "RebalanceOperationPerformer.java",
> "lineNumber": 208,
> "className":
> "org.apache.geode.management.internal.operation.RebalanceOperationPerformer",
> "nativeMethod": false
> },
> {
> "methodName": "executeRebalanceOnDS",
> "fileName": "RebalanceOperationPerformer.java",
> "lineNumber": 326,
> "className":
> "org.apache.geode.management.internal.operation.RebalanceOperationPerformer",
> "nativeMethod": false
> },
> {
> "methodName": "perform",
> "fileName": "RebalanceOperationPerformer.java",
> "lineNumber": 91,
> "className":
> "org.apache.geode.management.internal.operation.RebalanceOperationPerformer",
> "nativeMethod": false
> },
> {
> "methodName": "lambda$submit$0",
> "fileName": "OperationManager.java",
> "lineNumber": 67,
> "className":
> "org.apache.geode.management.internal.operation.OperationManager",
> "nativeMethod": false
> },
> {
> "methodName": "run",
> "fileName": "CompletableFuture.java",
> "lineNumber": 1590,
> "className":
> "java.util.concurrent.CompletableFuture$AsyncSupply",
> "nativeMethod": false
> },
> {
> "methodName": "run",
> "fileName": "Thread.java",
> "lineNumber": 748,
> "className": "java.lang.Thread",
> "nativeMethod": false
> }
> ]
> }
> }
> {code}
> expected things, 1 of the followings:
> 1. stop or forbid users to run rebalance on the non-jmxManager locator
> 2. return instructive info to let users find proper way to run rebalance
> 3. stop or forbid a REST API for Management to run , when there is no
> jmx-manager on the locator.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7900) GfshHostNameVerificationDistributedTest > expectConnectionFailureWhenNoHostNameInLocatorKey failing on Windows
[
https://issues.apache.org/jira/browse/GEODE-7900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17066052#comment-17066052
]
ASF subversion and git services commented on GEODE-7900:
Commit a93a59eb7d55dbdc6b7f0e690555e32eaa7de8fd in geode's branch
refs/heads/develop from Dan Smith
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=a93a59e ]
GEODE-7900: Only set the SNI hostname if it is not present
It turns out the JDK sometimes automatically sets the SNI hostname and
sometimes does not. With openjdk 8, it only sets SNI hostname if there is a
dot in the hostname. See sun.security.ssl.Utilities#addToSNIServerNameList
For this reason, we need to only set the SNI hostname if the JDK did not.
Otherwise it will complain that there is a `Duplicated server name of type 0`
> 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
> Time Spent: 1h
> Remaining Estimate: 0h
>
> 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] [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=17066055#comment-17066055
]
ASF subversion and git services commented on GEODE-7727:
Commit 1dfc496da34916297258b881c5606944d26bfb8b in geode's branch
refs/heads/develop from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=1dfc496 ]
GEODE-6008: CI Failure: ClientServerHostNameVerificationDistributedTe… (#4839)
* 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.
* fixed failing test due to change in exceptions in NioSslEngine
> 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-6008) CI Failure: ClientServerHostNameVerificationDistributedTest.expectConnectionFailureWhenNoHostNameInServerKey failed
[
https://issues.apache.org/jira/browse/GEODE-6008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17066054#comment-17066054
]
ASF subversion and git services commented on GEODE-6008:
Commit 1dfc496da34916297258b881c5606944d26bfb8b in geode's branch
refs/heads/develop from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=1dfc496 ]
GEODE-6008: CI Failure: ClientServerHostNameVerificationDistributedTe… (#4839)
* 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.
* fixed failing test due to change in exceptions in NioSslEngine
> 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: 40m
> 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)
> a
[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=17066053#comment-17066053
]
ASF subversion and git services commented on GEODE-6008:
Commit 1dfc496da34916297258b881c5606944d26bfb8b in geode's branch
refs/heads/develop from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=1dfc496 ]
GEODE-6008: CI Failure: ClientServerHostNameVerificationDistributedTe… (#4839)
* 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.
* fixed failing test due to change in exceptions in NioSslEngine
> 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: 40m
> 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)
> a
[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=17066061#comment-17066061
]
ASF subversion and git services commented on GEODE-6008:
Commit d446cd620f2ebc32355594793b37d6ea437857a1 in geode's branch
refs/heads/feature/GEODE-6008b from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=d446cd6 ]
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: 40m
> 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-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=17066056#comment-17066056
]
ASF subversion and git services commented on GEODE-7894:
Commit 1dfc496da34916297258b881c5606944d26bfb8b in geode's branch
refs/heads/develop from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=1dfc496 ]
GEODE-6008: CI Failure: ClientServerHostNameVerificationDistributedTe… (#4839)
* 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.
* fixed failing test due to change in exceptions in NioSslEngine
> 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=17066065#comment-17066065
]
ASF subversion and git services commented on GEODE-7873:
Commit d446cd620f2ebc32355594793b37d6ea437857a1 in geode's branch
refs/heads/feature/GEODE-6008b from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=d446cd6 ]
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-7871) CI Failure: ClientServerHostNameVerificationDistributedTest.expectConnectionFailureWhenNoHostNameInLocatorKey Failed
[
https://issues.apache.org/jira/browse/GEODE-7871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17066064#comment-17066064
]
ASF subversion and git services commented on GEODE-7871:
Commit d446cd620f2ebc32355594793b37d6ea437857a1 in geode's branch
refs/heads/feature/GEODE-6008b from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=d446cd6 ]
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-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=17066063#comment-17066063
]
ASF subversion and git services commented on GEODE-7894:
Commit d446cd620f2ebc32355594793b37d6ea437857a1 in geode's branch
refs/heads/feature/GEODE-6008b from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=d446cd6 ]
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-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=17066066#comment-17066066 ] ASF subversion and git services commented on GEODE-7806: Commit d446cd620f2ebc32355594793b37d6ea437857a1 in geode's branch refs/heads/feature/GEODE-6008b from Bruce Schuchardt [ https://gitbox.apache.org/repos/asf?p=geode.git;h=d446cd6 ] 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-7873) CI Failure: DeployJarWithSSLDUnitTest.deployJarWithMultipleLocators
[
https://issues.apache.org/jira/browse/GEODE-7873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17066058#comment-17066058
]
ASF subversion and git services commented on GEODE-7873:
Commit 1dfc496da34916297258b881c5606944d26bfb8b in geode's branch
refs/heads/develop from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=1dfc496 ]
GEODE-6008: CI Failure: ClientServerHostNameVerificationDistributedTe… (#4839)
* 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.
* fixed failing test due to change in exceptions in NioSslEngine
> 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.Connect
[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=17066057#comment-17066057
]
ASF subversion and git services commented on GEODE-7871:
Commit 1dfc496da34916297258b881c5606944d26bfb8b in geode's branch
refs/heads/develop from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=1dfc496 ]
GEODE-6008: CI Failure: ClientServerHostNameVerificationDistributedTe… (#4839)
* 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.
* fixed failing test due to change in exceptions in NioSslEngine
> 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=17066062#comment-17066062
]
ASF subversion and git services commented on GEODE-7727:
Commit d446cd620f2ebc32355594793b37d6ea437857a1 in geode's branch
refs/heads/feature/GEODE-6008b from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=d446cd6 ]
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-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=17066059#comment-17066059 ] ASF subversion and git services commented on GEODE-7806: Commit 1dfc496da34916297258b881c5606944d26bfb8b in geode's branch refs/heads/develop from Bruce Schuchardt [ https://gitbox.apache.org/repos/asf?p=geode.git;h=1dfc496 ] GEODE-6008: CI Failure: ClientServerHostNameVerificationDistributedTe… (#4839) * 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. * fixed failing test due to change in exceptions in NioSslEngine > 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] [Assigned] (GEODE-6008) CI Failure: ClientServerHostNameVerificationDistributedTest.expectConnectionFailureWhenNoHostNameInServerKey failed
[
https://issues.apache.org/jira/browse/GEODE-6008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce J Schuchardt reassigned GEODE-6008:
-
Assignee: (was: Bruce J Schuchardt)
> 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
>Priority: Major
> Fix For: 1.9.0, 1.13.0
>
> Time Spent: 40m
> 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.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
> at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
> at
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:117)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:155)
> at
> org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:137)
> at
> org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:404)
> at
> org.gradle.internal.concurrent.ExecutorPolicy$C
[jira] [Resolved] (GEODE-6008) CI Failure: ClientServerHostNameVerificationDistributedTest.expectConnectionFailureWhenNoHostNameInServerKey failed
[
https://issues.apache.org/jira/browse/GEODE-6008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce J Schuchardt resolved GEODE-6008.
---
Fix Version/s: 1.13.0
Resolution: Fixed
The original problem was fixed in 1.9.0. The new problem was introduced by the
fix for GEODE-7727 and is fixed in develop for the next release off of that
branch.
> 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.13.0, 1.9.0
>
> Time Spent: 40m
> 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.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
> at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
> at
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:117)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:155)
> at
> org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.
[jira] [Resolved] (GEODE-7894) CustomSSLProviderDistributedTest hostNameIsValidatedWhenUsingDefaultContext fails with suspect uncaught DistributedSystemDisconnectedException
[
https://issues.apache.org/jira/browse/GEODE-7894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce J Schuchardt resolved GEODE-7894.
---
Fix Version/s: 1.13.0
Resolution: Fixed
fixed along with GEODE-6008 in 1dfc496da34916297258b881c5606944d26bfb8b
> 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
> Fix For: 1.13.0
>
>
> 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] [Resolved] (GEODE-7871) CI Failure: ClientServerHostNameVerificationDistributedTest.expectConnectionFailureWhenNoHostNameInLocatorKey Failed
[
https://issues.apache.org/jira/browse/GEODE-7871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce J Schuchardt resolved GEODE-7871.
---
Fix Version/s: 1.13.0
Resolution: Fixed
fixed along with GEODE-6008 in 1dfc496da34916297258b881c5606944d26bfb8b
> 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
>Priority: Major
> Fix For: 1.13.0
>
>
> 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] [Assigned] (GEODE-7871) CI Failure: ClientServerHostNameVerificationDistributedTest.expectConnectionFailureWhenNoHostNameInLocatorKey Failed
[
https://issues.apache.org/jira/browse/GEODE-7871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce J Schuchardt reassigned GEODE-7871:
-
Assignee: (was: Bruce J Schuchardt)
> 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
>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] [Updated] (GEODE-7871) CI Failure: ClientServerHostNameVerificationDistributedTest.expectConnectionFailureWhenNoHostNameInLocatorKey Failed
[
https://issues.apache.org/jira/browse/GEODE-7871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce J Schuchardt updated GEODE-7871:
--
Affects Version/s: (was: 1.12.0)
> CI Failure:
> ClientServerHostNameVerificationDistributedTest.expectConnectionFailureWhenNoHostNameInLocatorKey
> Failed
>
>
> Key: GEODE-7871
> URL: https://issues.apache.org/jira/browse/GEODE-7871
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Ivan Godwin
>Priority: Major
> Fix For: 1.13.0
>
>
> 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] [Resolved] (GEODE-7873) CI Failure: DeployJarWithSSLDUnitTest.deployJarWithMultipleLocators
[
https://issues.apache.org/jira/browse/GEODE-7873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce J Schuchardt resolved GEODE-7873.
---
Fix Version/s: 1.13.0
Resolution: Fixed
fixed along with GEODE-6008 in 1dfc496da34916297258b881c5606944d26bfb8b
> 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
> Fix For: 1.13.0
>
>
> 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/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/1637
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (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:all-tabpanel ] Bruce J Schuchardt resolved GEODE-7806. --- Fix Version/s: 1.13.0 Resolution: Fixed fixed along with GEODE-6008 in 1dfc496da34916297258b881c5606944d26bfb8b > 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 > Fix For: 1.13.0 > > > 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-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:comment-tabpanel&focusedCommentId=17066080#comment-17066080
]
Joris Melchior commented on GEODE-7901:
---
Failed again in build #1624
> 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
> Time Spent: 20m
> Remaining Estimate: 0h
>
> 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-7904) ClusterCommunicationsDUnitTest > performARollingUpgrade[UNSHARED_CONNECTIONS_WITH_SSL]
Joris Melchior created GEODE-7904:
-
Summary: ClusterCommunicationsDUnitTest >
performARollingUpgrade[UNSHARED_CONNECTIONS_WITH_SSL]
Key: GEODE-7904
URL: https://issues.apache.org/jira/browse/GEODE-7904
Project: Geode
Issue Type: Bug
Components: membership
Reporter: Joris Melchior
Failed CI job: [Distributed test
1654|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/1654#L5e3ace7f:641:656]
{noformat}
org.apache.geode.ClusterCommunicationsDUnitTest >
performARollingUpgrade[UNSHARED_CONNECTIONS_WITH_SSL] 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 3455
[fatal 2020/03/24 08:01:43.101 GMT tid=82] Uncaught
exception in thread Thread[unused p2p reader,10,RMI Runtime]
org.apache.geode.distributed.DistributedSystemDisconnectedException:
Distribution manager on 172.17.0.20(vm0:4181:locator):41001 started at
Tue Mar 24 08:01:24 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:1670)
at org.apache.geode.internal.tcp.Connection.run(Connection.java:1450)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-7904) ClusterCommunicationsDUnitTest > performARollingUpgrade[UNSHARED_CONNECTIONS_WITH_SSL]
[
https://issues.apache.org/jira/browse/GEODE-7904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce Schuchardt resolved GEODE-7904.
-
Fix Version/s: 1.13.0
Resolution: Fixed
fixed along with GEODE-6008 in 1dfc496da34916297258b881c5606944d26bfb8b
> ClusterCommunicationsDUnitTest >
> performARollingUpgrade[UNSHARED_CONNECTIONS_WITH_SSL]
> --
>
> Key: GEODE-7904
> URL: https://issues.apache.org/jira/browse/GEODE-7904
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Joris Melchior
>Priority: Major
> Fix For: 1.13.0
>
>
> Failed CI job: [Distributed test
> 1654|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/1654#L5e3ace7f:641:656]
> {noformat}
> org.apache.geode.ClusterCommunicationsDUnitTest >
> performARollingUpgrade[UNSHARED_CONNECTIONS_WITH_SSL] 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 3455
> [fatal 2020/03/24 08:01:43.101 GMT tid=82] Uncaught
> exception in thread Thread[unused p2p reader,10,RMI Runtime]
> org.apache.geode.distributed.DistributedSystemDisconnectedException:
> Distribution manager on 172.17.0.20(vm0:4181:locator):41001 started
> at Tue Mar 24 08:01:24 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:1670)
> at org.apache.geode.internal.tcp.Connection.run(Connection.java:1450)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-7905) RedisDistDUnitTest failing intermittently in CI
Sarah Abbey created GEODE-7905: -- Summary: RedisDistDUnitTest failing intermittently in CI Key: GEODE-7905 URL: https://issues.apache.org/jira/browse/GEODE-7905 Project: Geode Issue Type: Bug Components: redis Reporter: Sarah Abbey Fix RedisDistDUnitTest, which fails intermittently: https://concourse.apachegeode-ci.info/builds/141130 ``` org.apache.geode.redis.RedisDistDUnitTest > classMethod 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 5030 [error 2020/03/23 19:26:51.559 GMT tid=99] org.apache.geode.ToDataException: toData failed on DataSerializer with id=0 for class class java.util.HashSet 6 tests completed, 1 failed ``` -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7905) RedisDistDUnitTest failing intermittently in CI
[
https://issues.apache.org/jira/browse/GEODE-7905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sarah Abbey updated GEODE-7905:
---
Description:
Fix RedisDistDUnitTest, which fails intermittently:
[https://concourse.apachegeode-ci.info/builds/141130]
{code:java}
org.apache.geode.redis.RedisDistDUnitTest > classMethod 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 5030
[error 2020/03/23 19:26:51.559 GMT tid=99]
org.apache.geode.ToDataException: toData failed on DataSerializer with id=0 for
class class java.util.HashSet
6 tests completed, 1 failed
{code}
was:
Fix RedisDistDUnitTest, which fails intermittently:
https://concourse.apachegeode-ci.info/builds/141130
```
org.apache.geode.redis.RedisDistDUnitTest > classMethod 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 5030
[error 2020/03/23 19:26:51.559 GMT tid=99]
org.apache.geode.ToDataException: toData failed on DataSerializer with id=0 for
class class java.util.HashSet
6 tests completed, 1 failed
```
> RedisDistDUnitTest failing intermittently in CI
> ---
>
> Key: GEODE-7905
> URL: https://issues.apache.org/jira/browse/GEODE-7905
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Sarah Abbey
>Priority: Major
>
> Fix RedisDistDUnitTest, which fails intermittently:
> [https://concourse.apachegeode-ci.info/builds/141130]
>
> {code:java}
> org.apache.geode.redis.RedisDistDUnitTest > classMethod 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 5030
> [error 2020/03/23 19:26:51.559 GMT tid=99]
> org.apache.geode.ToDataException: toData failed on DataSerializer with id=0
> for class class java.util.HashSet
> 6 tests completed, 1 failed
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-7906) GfshCommandIntegrationTest failing in Windows testing JDK8 and JDK11
Joris Melchior created GEODE-7906:
-
Summary: GfshCommandIntegrationTest failing in Windows testing
JDK8 and JDK11
Key: GEODE-7906
URL: https://issues.apache.org/jira/browse/GEODE-7906
Project: Geode
Issue Type: Bug
Components: management
Reporter: Joris Melchior
Failed in CI:
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsIntegrationTestOpenJDK11/builds/1344#L5e3ada01:364:370
Test results:
http://files.apachegeode-ci.info/builds/apache-develop-main/1.13.0-SNAPSHOT.0115/test-results/integrationTest/1585078363/
{noformat}
org.apache.geode.management.internal.cli.commands.GfshCommandIntegrationTest >
invalidCommandWhenConnected FAILED
org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
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.test.junit.rules.GfshCommandRule.connectAndVerify(GfshCommandRule.java:163)
at
org.apache.geode.management.internal.cli.commands.GfshCommandIntegrationTest.invalidCommandWhenConnected(GfshCommandIntegrationTest.java:71)
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-7906) GfshCommandIntegrationTest failing in Windows testing JDK8 and JDK11
[
https://issues.apache.org/jira/browse/GEODE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joris Melchior reassigned GEODE-7906:
-
Assignee: Darrel Schneider
> GfshCommandIntegrationTest failing in Windows testing JDK8 and JDK11
>
>
> Key: GEODE-7906
> URL: https://issues.apache.org/jira/browse/GEODE-7906
> Project: Geode
> Issue Type: Bug
> Components: management
>Reporter: Joris Melchior
>Assignee: Darrel Schneider
>Priority: Major
>
> Failed in CI:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsIntegrationTestOpenJDK11/builds/1344#L5e3ada01:364:370
> Test results:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.13.0-SNAPSHOT.0115/test-results/integrationTest/1585078363/
> {noformat}
> org.apache.geode.management.internal.cli.commands.GfshCommandIntegrationTest
> > invalidCommandWhenConnected FAILED
> org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
> 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.test.junit.rules.GfshCommandRule.connectAndVerify(GfshCommandRule.java:163)
> at
> org.apache.geode.management.internal.cli.commands.GfshCommandIntegrationTest.invalidCommandWhenConnected(GfshCommandIntegrationTest.java:71)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-7907) GfshCommandIntegrationTest fails because port 1099 is already in use
[
https://issues.apache.org/jira/browse/GEODE-7907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider reassigned GEODE-7907:
---
Assignee: Darrel Schneider
> GfshCommandIntegrationTest fails because port 1099 is already in use
>
>
> Key: GEODE-7907
> URL: https://issues.apache.org/jira/browse/GEODE-7907
> Project: Geode
> Issue Type: Bug
> Components: management
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>Priority: Major
>
> Saw this failure on Windows:
> {noformat}
> org.apache.geode.management.internal.cli.commands.GfshCommandIntegrationTest
> > invalidCommandWhenConnected FAILED
> org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
> 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.test.junit.rules.GfshCommandRule.connectAndVerify(GfshCommandRule.java:163)
> at
> org.apache.geode.management.internal.cli.commands.GfshCommandIntegrationTest.invalidCommandWhenConnected(GfshCommandIntegrationTest.java:71)
> {noformat}
> The underlying cause was:
> {noformat}
> Connecting to Locator at [host=localhost, port=25690] ..
> Exception caused JMX Manager startup to fail because:
> 'java.rmi.server.ExportException: Port already in use: 1099; nested exception
> is:
> java.net.BindException: Failed to create server socket on
> 10.0.0.143[1099]'
> {noformat}
> This test starts a locator and does not configure the jmx manager port. So it
> will default to 1099. It should set it to a random port.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-7907) GfshCommandIntegrationTest fails because port 1099 is already in use
Darrel Schneider created GEODE-7907:
---
Summary: GfshCommandIntegrationTest fails because port 1099 is
already in use
Key: GEODE-7907
URL: https://issues.apache.org/jira/browse/GEODE-7907
Project: Geode
Issue Type: Bug
Components: management
Reporter: Darrel Schneider
Saw this failure on Windows:
{noformat}
org.apache.geode.management.internal.cli.commands.GfshCommandIntegrationTest >
invalidCommandWhenConnected FAILED
org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
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.test.junit.rules.GfshCommandRule.connectAndVerify(GfshCommandRule.java:163)
at
org.apache.geode.management.internal.cli.commands.GfshCommandIntegrationTest.invalidCommandWhenConnected(GfshCommandIntegrationTest.java:71)
{noformat}
The underlying cause was:
{noformat}
Connecting to Locator at [host=localhost, port=25690] ..
Exception caused JMX Manager startup to fail because:
'java.rmi.server.ExportException: Port already in use: 1099; nested exception
is:
java.net.BindException: Failed to create server socket on
10.0.0.143[1099]'
{noformat}
This test starts a locator and does not configure the jmx manager port. So it
will default to 1099. It should set it to a random port.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-7907) GfshCommandIntegrationTest fails because port 1099 is already in use
[
https://issues.apache.org/jira/browse/GEODE-7907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider updated GEODE-7907:
Priority: Minor (was: Major)
> GfshCommandIntegrationTest fails because port 1099 is already in use
>
>
> Key: GEODE-7907
> URL: https://issues.apache.org/jira/browse/GEODE-7907
> Project: Geode
> Issue Type: Bug
> Components: management
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>Priority: Minor
>
> Saw this failure on Windows:
> {noformat}
> org.apache.geode.management.internal.cli.commands.GfshCommandIntegrationTest
> > invalidCommandWhenConnected FAILED
> org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
> 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.test.junit.rules.GfshCommandRule.connectAndVerify(GfshCommandRule.java:163)
> at
> org.apache.geode.management.internal.cli.commands.GfshCommandIntegrationTest.invalidCommandWhenConnected(GfshCommandIntegrationTest.java:71)
> {noformat}
> The underlying cause was:
> {noformat}
> Connecting to Locator at [host=localhost, port=25690] ..
> Exception caused JMX Manager startup to fail because:
> 'java.rmi.server.ExportException: Port already in use: 1099; nested exception
> is:
> java.net.BindException: Failed to create server socket on
> 10.0.0.143[1099]'
> {noformat}
> This test starts a locator and does not configure the jmx manager port. So it
> will default to 1099. It should set it to a random port.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-7906) GfshCommandIntegrationTest failing in Windows testing JDK8 and JDK11
[
https://issues.apache.org/jira/browse/GEODE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider resolved GEODE-7906.
-
Resolution: Duplicate
> GfshCommandIntegrationTest failing in Windows testing JDK8 and JDK11
>
>
> Key: GEODE-7906
> URL: https://issues.apache.org/jira/browse/GEODE-7906
> Project: Geode
> Issue Type: Bug
> Components: management
>Reporter: Joris Melchior
>Assignee: Darrel Schneider
>Priority: Major
>
> Failed in CI:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsIntegrationTestOpenJDK11/builds/1344#L5e3ada01:364:370
> Test results:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.13.0-SNAPSHOT.0115/test-results/integrationTest/1585078363/
> {noformat}
> org.apache.geode.management.internal.cli.commands.GfshCommandIntegrationTest
> > invalidCommandWhenConnected FAILED
> org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
> 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.test.junit.rules.GfshCommandRule.connectAndVerify(GfshCommandRule.java:163)
> at
> org.apache.geode.management.internal.cli.commands.GfshCommandIntegrationTest.invalidCommandWhenConnected(GfshCommandIntegrationTest.java:71)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-6819) CI failure: PartitionedRegionSingleHopDUnitTest. testMetadataIsSameOnAllServersAndClients
[
https://issues.apache.org/jira/browse/GEODE-6819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Godwin reassigned GEODE-6819:
--
Assignee: Ivan Godwin
> CI failure: PartitionedRegionSingleHopDUnitTest.
> testMetadataIsSameOnAllServersAndClients
> -
>
> Key: GEODE-6819
> URL: https://issues.apache.org/jira/browse/GEODE-6819
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Reporter: Bruce J Schuchardt
>Assignee: Ivan Godwin
>Priority: Major
> Labels: flaky
> Fix For: 1.12.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {noformat}
> org.apache.geode.internal.cache.PartitionedRegionSingleHopDUnitTest >
> testMetadataIsSameOnAllServersAndClients FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined in public void
> org.apache.geode.internal.cache.PartitionedRegionSingleHopDUnitTest.testMetadataIsSameOnAllServersAndClients()
> bucket copies are not created within 300 seconds.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:145)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:122)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:902)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723)
> at
> org.apache.geode.internal.cache.PartitionedRegionSingleHopDUnitTest.testMetadataIsSameOnAllServersAndClients(PartitionedRegionSingleHopDUnitTest.java:849)
> Caused by:
> java.lang.AssertionError: bucket copies are not created{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7907) GfshCommandIntegrationTest fails because port 1099 is already in use
[
https://issues.apache.org/jira/browse/GEODE-7907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17066207#comment-17066207
]
Darrel Schneider commented on GEODE-7907:
-
InternalLocatorTest has the same issue
> GfshCommandIntegrationTest fails because port 1099 is already in use
>
>
> Key: GEODE-7907
> URL: https://issues.apache.org/jira/browse/GEODE-7907
> Project: Geode
> Issue Type: Bug
> Components: management
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>Priority: Minor
>
> Saw this failure on Windows:
> {noformat}
> org.apache.geode.management.internal.cli.commands.GfshCommandIntegrationTest
> > invalidCommandWhenConnected FAILED
> org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
> 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.test.junit.rules.GfshCommandRule.connectAndVerify(GfshCommandRule.java:163)
> at
> org.apache.geode.management.internal.cli.commands.GfshCommandIntegrationTest.invalidCommandWhenConnected(GfshCommandIntegrationTest.java:71)
> {noformat}
> The underlying cause was:
> {noformat}
> Connecting to Locator at [host=localhost, port=25690] ..
> Exception caused JMX Manager startup to fail because:
> 'java.rmi.server.ExportException: Port already in use: 1099; nested exception
> is:
> java.net.BindException: Failed to create server socket on
> 10.0.0.143[1099]'
> {noformat}
> This test starts a locator and does not configure the jmx manager port. So it
> will default to 1099. It should set it to a random port.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7812) PutAllClientServerDistributedTest.testEventIdMisorderInPRSingleHop is failing
[
https://issues.apache.org/jira/browse/GEODE-7812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17066219#comment-17066219
]
ASF subversion and git services commented on GEODE-7812:
Commit f7b79c9eba9a3f88198cc3d64d15c76cfcc3fd00 in geode's branch
refs/heads/develop from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=f7b79c9 ]
GEODE-7812: Fix PoolFactory usage in PutAllClientServerDistributedTest (#4835)
Subscription enabled must be true for the other subscription config
options on PoolFactory to do anything.
> PutAllClientServerDistributedTest.testEventIdMisorderInPRSingleHop is failing
> -
>
> Key: GEODE-7812
> URL: https://issues.apache.org/jira/browse/GEODE-7812
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Mark Hanson
>Assignee: Kirk Lund
>Priority: Major
> Labels: flaky
> Time Spent: 40m
> Remaining Estimate: 0h
>
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.PutAllClientServerDistributedTest$$Lambda$510/1407303081.run
> in VM 3 running on Host d8813bc515cd with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
> at
> org.apache.geode.internal.cache.PutAllClientServerDistributedTest.testEventIdMisorderInPRSingleHop(PutAllClientServerDistributedTest.java:2356)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at
> org.apache.geode.test.dunit.rules.AbstractDistributedRule$1.evaluate(AbstractDistributedRule.java:59)
> at
> org.apache.geode.test.dunit.rules.AbstractDistributedRule$1.evaluate(AbstractDistributedRule.java:59)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:449)
> at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:393)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> at
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispat
[jira] [Reopened] (GEODE-7739) Redundant JMX managers may not federate mbeans of other JMX managers
[ https://issues.apache.org/jira/browse/GEODE-7739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund reopened GEODE-7739: -- The fixes for this were reverted. > Redundant JMX managers may not federate mbeans of other JMX managers > > > Key: GEODE-7739 > URL: https://issues.apache.org/jira/browse/GEODE-7739 > Project: Geode > Issue Type: Bug > Components: jmx >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Fix For: 1.13.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Debugging with JMXMBeanReconnectDUnitTest revealed this bug. > The test starts two locators with jmx manager configured and started. > Locator1 always has all of locator2's mbeans, but locator2 is intermittently > missing the personal mbeans of locator1. > I think this is caused by some sort of race condition in the code that > creates the monitoring regions for other members in locator2. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (GEODE-7710) JMXMBeanReconnectDUnitTest fails intermittently because one locator is missing the LockServiceMXBean
[
https://issues.apache.org/jira/browse/GEODE-7710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund reopened GEODE-7710:
--
The fixes for this were reverted.
> JMXMBeanReconnectDUnitTest fails intermittently because one locator is
> missing the LockServiceMXBean
>
>
> Key: GEODE-7710
> URL: https://issues.apache.org/jira/browse/GEODE-7710
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: flaky
> Fix For: 1.13.0
>
> Time Spent: 4h 50m
> Remaining Estimate: 0h
>
> Multiple tests in JMXMBeanReconnectDUnitTest may fail an await due to one of
> the locators missing the LockServiceMXBean for the cluster config service.
> {noformat}
> but could not find:
>
> <[GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator1]>
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-7908) Generate error when user attempts to configure SNI without SSL
Ernest Burghardt created GEODE-7908: --- Summary: Generate error when user attempts to configure SNI without SSL Key: GEODE-7908 URL: https://issues.apache.org/jira/browse/GEODE-7908 Project: Geode Issue Type: Improvement Components: membership Reporter: Ernest Burghardt SNI is only usable in the context of (client-to-locator and client-to-server) TLS/SSL. But we're using system properties and Geode configuration properties to configure TLS/SSL. The possibility arises that a user may specify one without the other. When this story is done there will be a test that verifies that when a user configures SNI without (client-to-locator and client-to-server) SSL, an error/exception TBD is generated (thrown, logged) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (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 resolved GEODE-7900.
--
Fix Version/s: 1.13.0
Resolution: Fixed
> 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
> Fix For: 1.13.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> 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] [Commented] (GEODE-7907) GfshCommandIntegrationTest fails because port 1099 is already in use
[
https://issues.apache.org/jira/browse/GEODE-7907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17066303#comment-17066303
]
ASF subversion and git services commented on GEODE-7907:
Commit 521a45339f92fdb0ac1e36f573ef19717d0f481d in geode's branch
refs/heads/develop from Darrel Schneider
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=521a453 ]
GEODE-7907: change test to use non-default jmx-manager-port (#4844)
* test now configures a non-default jmx-manager-port
* InternalLocatorTest now uses random port and cleans up by stopping the locator
* removed try/catch from after method
> GfshCommandIntegrationTest fails because port 1099 is already in use
>
>
> Key: GEODE-7907
> URL: https://issues.apache.org/jira/browse/GEODE-7907
> Project: Geode
> Issue Type: Bug
> Components: management
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>Priority: Minor
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Saw this failure on Windows:
> {noformat}
> org.apache.geode.management.internal.cli.commands.GfshCommandIntegrationTest
> > invalidCommandWhenConnected FAILED
> org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
> 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.test.junit.rules.GfshCommandRule.connectAndVerify(GfshCommandRule.java:163)
> at
> org.apache.geode.management.internal.cli.commands.GfshCommandIntegrationTest.invalidCommandWhenConnected(GfshCommandIntegrationTest.java:71)
> {noformat}
> The underlying cause was:
> {noformat}
> Connecting to Locator at [host=localhost, port=25690] ..
> Exception caused JMX Manager startup to fail because:
> 'java.rmi.server.ExportException: Port already in use: 1099; nested exception
> is:
> java.net.BindException: Failed to create server socket on
> 10.0.0.143[1099]'
> {noformat}
> This test starts a locator and does not configure the jmx manager port. So it
> will default to 1099. It should set it to a random port.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-7710) JMXMBeanReconnectDUnitTest fails intermittently because one locator is missing the LockServiceMXBean
[
https://issues.apache.org/jira/browse/GEODE-7710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-7710:
Fix Version/s: (was: 1.13.0)
> JMXMBeanReconnectDUnitTest fails intermittently because one locator is
> missing the LockServiceMXBean
>
>
> Key: GEODE-7710
> URL: https://issues.apache.org/jira/browse/GEODE-7710
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: flaky
> Time Spent: 4h 50m
> Remaining Estimate: 0h
>
> Multiple tests in JMXMBeanReconnectDUnitTest may fail an await due to one of
> the locators missing the LockServiceMXBean for the cluster config service.
> {noformat}
> but could not find:
>
> <[GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator1]>
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-7907) GfshCommandIntegrationTest fails because port 1099 is already in use
[
https://issues.apache.org/jira/browse/GEODE-7907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider resolved GEODE-7907.
-
Fix Version/s: 1.13.0
Resolution: Fixed
> GfshCommandIntegrationTest fails because port 1099 is already in use
>
>
> Key: GEODE-7907
> URL: https://issues.apache.org/jira/browse/GEODE-7907
> Project: Geode
> Issue Type: Bug
> Components: management
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>Priority: Minor
> Fix For: 1.13.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Saw this failure on Windows:
> {noformat}
> org.apache.geode.management.internal.cli.commands.GfshCommandIntegrationTest
> > invalidCommandWhenConnected FAILED
> org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
> 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.test.junit.rules.GfshCommandRule.connectAndVerify(GfshCommandRule.java:163)
> at
> org.apache.geode.management.internal.cli.commands.GfshCommandIntegrationTest.invalidCommandWhenConnected(GfshCommandIntegrationTest.java:71)
> {noformat}
> The underlying cause was:
> {noformat}
> Connecting to Locator at [host=localhost, port=25690] ..
> Exception caused JMX Manager startup to fail because:
> 'java.rmi.server.ExportException: Port already in use: 1099; nested exception
> is:
> java.net.BindException: Failed to create server socket on
> 10.0.0.143[1099]'
> {noformat}
> This test starts a locator and does not configure the jmx manager port. So it
> will default to 1099. It should set it to a random port.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
