[jira] [Updated] (GEODE-5653) Race between put of parallel WAN sender event and distributed clear causes off-heap orphan
[
https://issues.apache.org/jira/browse/GEODE-5653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-5653:
--
Labels: pull-request-available (was: )
> Race between put of parallel WAN sender event and distributed clear causes
> off-heap orphan
> --
>
> Key: GEODE-5653
> URL: https://issues.apache.org/jira/browse/GEODE-5653
> Project: Geode
> Issue Type: Bug
> Components: offheap, regions, wan
>Reporter: Ryan McMahon
>Priority: Major
> Labels: pull-request-available
>
> A race resulting in an off-heap orphan can occur with Parallel WAN when
> off-heap is enabled on the cache and user's data region. It is the result of
> the put occurring in two distinct steps without proper synchronization. The
> initial value of the region entry is Token.REMOVED_PHASE_1 (step 1) then
> later is replaced with actual GatewaySenderEvent (step 2). If a distributed
> clear is processed between these two steps, it can result in an orphan. More
> details on the race are described below.
> The race is between:
> *Thread 1*. A put of a {{GatewaySenderEvent}} containing an off-heap value to
> one of the WAN "shadow" region's {{BucketRegionQueue}}
> and
> *Thread 2*. A distributed clear on the {{BucketRegionQueue}} containing that
> value
> The race occurs as follows:
> *Thread 1 (Put)*: Put results in a new region entry where the value is
> {{Token.REMOVED_PHASE1}} and put it into the {{CustomEntryConcurrentHashMap}}
> owned by the {{AbstractRegionMap}}.
> *Thread 2 (Clear)*: Iterates through bucket region's segments and clears the
> entries. At this time the value is still {{Token.REMOVED_PHASE_1}}.
> *Thread 1 (Put)*: The {{Token.REMOVED_PHASE_1}} is replaced with the actual
> {{GatewaySenderEvent}} in the region entry. However, the entry was removed
> via the clear above. When the entry is removed from the region, its off-heap
> is orphaned because it is no longer in the {{CustomEntryConcurrentHashMap}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5662) Flaky unit test ExecutorServiceRuleTest.threadCountTwoHasTwoThreads
[
https://issues.apache.org/jira/browse/GEODE-5662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16596925#comment-16596925
]
ASF subversion and git services commented on GEODE-5662:
Commit 9e4912f762887ed574e5fdbc819e970671a06e57 in geode's branch
refs/heads/develop from [~apa...@the9muses.net]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=9e4912f ]
GEODE-5662: improve timeouts in ExecutorServiceRuleTest
All calls requiring a timeout now use Awaitility. Timeout for all
calls are defined centrally with a value of 2 minutes.
Remove tests that were actually testing Executors/ExecutorService.
> Flaky unit test ExecutorServiceRuleTest.threadCountTwoHasTwoThreads
> ---
>
> Key: GEODE-5662
> URL: https://issues.apache.org/jira/browse/GEODE-5662
> Project: Geode
> Issue Type: Bug
>Reporter: Dan Smith
>Assignee: Kirk Lund
>Priority: Major
> Labels: pull-request-available, swat
> Time Spent: 50m
> Remaining Estimate: 0h
>
> This test failed in CI. To me it looks like this test seems to be assuming
> that if it schedules two tasks they will actually run concurrently, which may
> or may not happen depending on timing.
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/Build/builds/403
> {noformat}
> org.apache.geode.test.junit.rules.ExecutorServiceRuleTest >
> threadCountTwoHasTwoThreads FAILED
> 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.test.junit.rules.ExecutorServiceRuleTest.threadCountTwoHasTwoThreads(ExecutorServiceRuleTest.java:130)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5652) ExecutorServiceRule should use unlimited ThreadPoolExecutor
[ https://issues.apache.org/jira/browse/GEODE-5652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund updated GEODE-5652: - Description: ExecutorServiceRule currently defaults to creating a fixed ThreadPoolExecutor of size 1. Creating unlimited ThreadPoolExecutor is a better default. (was: ExecutorServiceRule currently defaults to creating a newFixedThreadPool of size 1. Creating a newCachedThreadPool is a better default.) > ExecutorServiceRule should use unlimited ThreadPoolExecutor > --- > > Key: GEODE-5652 > URL: https://issues.apache.org/jira/browse/GEODE-5652 > Project: Geode > Issue Type: Wish > Components: tests >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > ExecutorServiceRule currently defaults to creating a fixed ThreadPoolExecutor > of size 1. Creating unlimited ThreadPoolExecutor is a better default. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5652) ExecutorServiceRule should use unlimited ThreadPoolExecutor
[ https://issues.apache.org/jira/browse/GEODE-5652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund updated GEODE-5652: - Summary: ExecutorServiceRule should use unlimited ThreadPoolExecutor (was: ExecutorServiceRule should create newCachedThreadPool by default) > ExecutorServiceRule should use unlimited ThreadPoolExecutor > --- > > Key: GEODE-5652 > URL: https://issues.apache.org/jira/browse/GEODE-5652 > Project: Geode > Issue Type: Wish > Components: tests >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > ExecutorServiceRule currently defaults to creating a newFixedThreadPool of > size 1. Creating a newCachedThreadPool is a better default. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5660) Add ability to lookup the GEODE-WEB-API war file from the classpath
[ https://issues.apache.org/jira/browse/GEODE-5660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16596916#comment-16596916 ] ASF subversion and git services commented on GEODE-5660: Commit b24c94fac578c369f2a8df827de40726bf91a4d6 in geode's branch refs/heads/feature/GEODE-5660 from [~ukohlmeyer] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=b24c94f ] GEODE-5660: Added method to lookup war file from classpath within AgentUtil.java. This is to address problem where http server is started from Java API (Spring Data Geode specifically) Now, the application can reference the `geode-web-api` war from repo and not have to specifically set `GEODE-HOME` property > Add ability to lookup the GEODE-WEB-API war file from the classpath > --- > > Key: GEODE-5660 > URL: https://issues.apache.org/jira/browse/GEODE-5660 > Project: Geode > Issue Type: Improvement > Components: rest (admin), rest (dev) >Reporter: Udo Kohlmeyer >Assignee: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > Fix For: 1.8.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > The current AgentUtil class only makes provision to lookup the > `geode-web-api` and `geode-web` war files from known locations. > When referencing the `geode-web-api` and `geode-web` war's from a > repository, the HTTP Services will fail, due to the requirement of having set > `GEODE_HOME` to the locally deployed GEODE distribution. > A way is required to reference the relevant war files from a repository and > not requiring the `GEODE_HOME` property to be specifically set. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-5622) SUPERFLAKY: AlterRuntimeCommandDUnitTest is flaky due to port conflicts
[
https://issues.apache.org/jira/browse/GEODE-5622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith reassigned GEODE-5622:
Assignee: Dan Smith
> SUPERFLAKY: AlterRuntimeCommandDUnitTest is flaky due to port conflicts
> ---
>
> Key: GEODE-5622
> URL: https://issues.apache.org/jira/browse/GEODE-5622
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Dan Smith
>Assignee: Dan Smith
>Priority: Major
> Labels: swat
>
> All of the methods of this test are failing in CI with port conflicts:
> {noformat}
> org.apache.geode.management.internal.cli.commands.AlterRuntimeCommandDUnitTest:
> 5 failures (98.333% success rate)
> | .alterLogFileSizeLimitNegative_errorCanNotSet(true): 2 failures (99.333%
> success rate)
> | | Failed build 215 at
> https://concourse.apachegeode-ci.info/teams/staging/pipelines/concourse-staging/jobs/DistributedTest/builds/215
> | | Failed build 79 at
> https://concourse.apachegeode-ci.info/teams/staging/pipelines/concourse-staging/jobs/DistributedTest/builds/79
> | .testAlterUpdatesSharedConfig(false): 1 failures (99.667% success rate)
> | | Failed build 232 at
> https://concourse.apachegeode-ci.info/teams/staging/pipelines/concourse-staging/jobs/DistributedTest/builds/232
> | .alterMemberWithoutOptions_needsRelevantParameter(true): 1 failures
> (99.667% success rate)
> | | Failed build 110 at
> https://concourse.apachegeode-ci.info/teams/staging/pipelines/concourse-staging/jobs/DistributedTest/builds/110
> | .alterArchiveFileSizeLimitWithGroup_updatesSelectedServerConfigs(false):
> 1 failures (99.667% success rate)
> | | Failed build 124 at
> https://concourse.apachegeode-ci.info/teams/staging/pipelines/concourse-staging/jobs/DistributedTest/builds/124
> {noformat}
> {noformat}
> org.apache.geode.management.internal.cli.commands.AlterRuntimeCommandDUnitTest
> > alterLogFileSizeLimitNegative_errorCanNotSet(true) [0] 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 43[error 2018/08/17 09:26:45.259 UTC Connection(1)-172.17.0.14> tid=32] Jmx manager could not be started because
> java.rmi.server.ExportException: Port already in use: 20961; nested exception
> is: java.net.BindException: Failed to create server socket on
> null[20,961]org.apache.geode.management.ManagementException:
> java.rmi.server.ExportException: Port already in use: 20961; nested exception
> is: java.net.BindException: Failed to create server socket on
> null[20,961]
> at
> org.apache.geode.management.internal.ManagementAgent.startAgent(ManagementAgent.java:161)
> at
> org.apache.geode.management.internal.SystemManagementService.startManager(SystemManagementService.java:435)
> at
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheCreation(ManagementAdapter.java:173)
> at
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:118)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2201)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:591)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1218)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:793)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:779)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:177)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:224)
> at
> org.apache.geode.distributed.internal.InternalLocator.startCache(InternalLocator.java:662)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:649)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:311)
> at org.apache.geode.distributed.Locator.startLocator(Locator.java:253)
> at
> org.apache.geode.distributed.Locator.startLocatorAndDS(Locator.java:140)
> at
> org.apache.geode.test.junit.rules.LocatorStarterRule.startLocator(LocatorStarterRule.java:87)
> at
> org.apache.geode.test.junit.rules.LocatorStarterRule.before(LocatorStarterRule.java:68)
> at
>
[jira] [Resolved] (GEODE-5588) MemberStarterRule.withHttpService does not always work
[
https://issues.apache.org/jira/browse/GEODE-5588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe resolved GEODE-5588.
---
Resolution: Fixed
Fix Version/s: 1.7.0
> MemberStarterRule.withHttpService does not always work
> --
>
> Key: GEODE-5588
> URL: https://issues.apache.org/jira/browse/GEODE-5588
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> This method does not work as expected under some situations. For example,
> this code fails to start the http service:
> {noformat}
> @Rule
> public GfshCommandRule gfsh = new GfshCommandRule();
> @Test
> public void sanity() throws Exception {
> lRule.withJMXManager().withHttpService()
> .startLocator();
> gfsh.connectAndVerify(lRule.getHttpPort(), GfshCommandRule.PortType.http);
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5535) Upgrade fast-classpath-scanner to 4.x
[ https://issues.apache.org/jira/browse/GEODE-5535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-5535. --- Resolution: Fixed Fix Version/s: 1.7.0 > Upgrade fast-classpath-scanner to 4.x > - > > Key: GEODE-5535 > URL: https://issues.apache.org/jira/browse/GEODE-5535 > Project: Geode > Issue Type: Improvement > Components: gfsh >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 50m > Remaining Estimate: 0h > > The package has been renamed to 'ClassGraph'. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-5587) Randomize internal http service working directory
[
https://issues.apache.org/jira/browse/GEODE-5587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe resolved GEODE-5587.
---
Resolution: Fixed
Fix Version/s: 1.7.0
> Randomize internal http service working directory
> -
>
> Key: GEODE-5587
> URL: https://issues.apache.org/jira/browse/GEODE-5587
> Project: Geode
> Issue Type: Bug
> Components: pulse, rest (admin), rest (dev)
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When starting the http service a given webapp is extracted into a working
> directory of the form: {{__}}. As part of shutdown this
> directory is cleaned up. However the directory is only completely removed
> when the JVM exits.
> Occasionally subsequent tests will request to use the same port. This results
> in the same working directory being used. On Windows this will fail as the
> directory does not let itself be cleaned up before the webapp is redeployed
> to the same location as before.
> We can randomize the working directory a bit more by adding a short sequence
> of random chars as part of the directory name.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5661) Pulse does not work when legacy SSL options are used
[
https://issues.apache.org/jira/browse/GEODE-5661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe resolved GEODE-5661.
---
Resolution: Fixed
Fix Version/s: 1.7.0
> Pulse does not work when legacy SSL options are used
>
>
> Key: GEODE-5661
> URL: https://issues.apache.org/jira/browse/GEODE-5661
> Project: Geode
> Issue Type: Bug
> Components: pulse
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Similar to GEODE-5230, if the legacy SSL configuration options are used,
> ({{cluster-ssl-*}}, {{jmx-manager-ssl-*}}, etc.), then Pulse does not work
> correctly and a user will see an error similar to the following in the UI:
> {noformat}
> Failed to retrieve RMIServer stub: javax.naming.CommunicationException [Root
> exception is java.rmi.ConnectIOException: error during JRMP connection
> establishment; nested exception is: javax.net.ssl.SSLHandshakeException:
> sun.security.validator.ValidatorException: PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5613) Support Windows builds on 'heavy-lifter' instances
[ https://issues.apache.org/jira/browse/GEODE-5613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-5613. --- Resolution: Fixed Fix Version/s: 1.7.0 > Support Windows builds on 'heavy-lifter' instances > -- > > Key: GEODE-5613 > URL: https://issues.apache.org/jira/browse/GEODE-5613 > Project: Geode > Issue Type: Improvement > Components: build >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 3h 20m > Remaining Estimate: 0h > > In order for Windows builds to be consistent with the Linux build process. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-5636) DescribeClientCommandDUnitTest fails on Windows
[
https://issues.apache.org/jira/browse/GEODE-5636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe resolved GEODE-5636.
---
Resolution: Fixed
Fix Version/s: 1.7.0
> DescribeClientCommandDUnitTest fails on Windows
> ---
>
> Key: GEODE-5636
> URL: https://issues.apache.org/jira/browse/GEODE-5636
> Project: Geode
> Issue Type: Bug
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The test was making incorrect assumptions about the order of `list members`
> {noformat}
> org.apache.geode.management.internal.cli.commands.DescribeClientCommandDUnitTest
> > describeClient FAILED
> org.junit.ComparisonFailure:
> expected:<"10.0.0.4([locator-0:9816:locator):32773 [Coordinator]]">
> but was:<"10.0.0.4([server-1:9292):32772]">
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.management.internal.cli.commands.DescribeClientCommandDUnitTest.validateResults(DescribeClientCommandDUnitTest.java:144)
> at
> org.apache.geode.management.internal.cli.commands.DescribeClientCommandDUnitTest.describeClient(DescribeClientCommandDUnitTest.java:103)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5646) Client throws ToDataException when locator is shutting down
[
https://issues.apache.org/jira/browse/GEODE-5646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nabarun updated GEODE-5646:
---
Fix Version/s: (was: 1.8.0)
1.7.0
> Client throws ToDataException when locator is shutting down
> ---
>
> Key: GEODE-5646
> URL: https://issues.apache.org/jira/browse/GEODE-5646
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
>Priority: Major
> Fix For: 1.7.0
>
>
> This hasn't been seen in Geode but in an older version of Pivotal GemFire.
> The code in question hasn't changed so we ought to fix it.
> {noformat}
> ERROR util.TestException: doEntryOperations caught Exception
> com.gemstone.gemfire.ToDataException: toData failed on DataSerializable class
> com.gemstone.gemfire.distributed.internal.ServerLocation
> at
> com.gemstone.gemfire.internal.InternalDataSerializer.invokeToData(InternalDataSerializer.java:2424)
> at
> com.gemstone.gemfire.cache.client.internal.locator.SerializationHelper.writeServerLocations(SerializationHelper.java:39)
> at
> com.gemstone.gemfire.cache.client.internal.locator.SerializationHelper.writeServerLocationSet(SerializationHelper.java:75)
> at
> com.gemstone.gemfire.cache.client.internal.locator.ClientConnectionRequest.toData(ClientConnectionRequest.java:44)
> at
> com.gemstone.gemfire.internal.InternalDataSerializer.invokeToData(InternalDataSerializer.java:2411)
> at
> com.gemstone.gemfire.internal.InternalDataSerializer.writeDSFID(InternalDataSerializer.java:1382)
> at
> com.gemstone.gemfire.internal.InternalDataSerializer.basicWriteObject(InternalDataSerializer.java:2156)
> at
> com.gemstone.gemfire.DataSerializer.writeObject(DataSerializer.java:3181)
> at
> com.gemstone.org.jgroups.stack.tcpserver.TcpClient.requestToServer(TcpClient.java:115)
> at
> com.gemstone.org.jgroups.stack.tcpserver.TcpClient.requestToServer(TcpClient.java:78)
> at
> com.gemstone.gemfire.cache.client.internal.AutoConnectionSourceImpl.queryOneLocator(AutoConnectionSourceImpl.java:188)
> at
> com.gemstone.gemfire.cache.client.internal.AutoConnectionSourceImpl.queryLocators(AutoConnectionSourceImpl.java:220)
> at
> com.gemstone.gemfire.cache.client.internal.AutoConnectionSourceImpl.findServer(AutoConnectionSourceImpl.java:132)
> at
> com.gemstone.gemfire.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:227)
> at
> com.gemstone.gemfire.cache.client.internal.pooling.ConnectionManagerImpl.exchangeConnection(ConnectionManagerImpl.java:421)
> at
> com.gemstone.gemfire.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:173)
> at
> com.gemstone.gemfire.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:115)
> at
> com.gemstone.gemfire.cache.client.internal.PoolImpl.execute(PoolImpl.java:702)
> at
> com.gemstone.gemfire.cache.client.internal.KeySetOp.execute(KeySetOp.java:38)
> at
> com.gemstone.gemfire.cache.client.internal.ServerRegionProxy.keySet(ServerRegionProxy.java:348)
> at
> com.gemstone.gemfire.internal.cache.LocalRegion.keySetOnServer(LocalRegion.java:4159)
> {noformat}
> The client is trying to serialize ServerLocation objects and send them to a
> locator. AutoConnectionSourceImpl.queryOneLocator() has code to handle
> IOException and report the locator as being down but since ServerLocation
> isn't a DataSerializableFixedID instance the serialization code throws a
> ToDataException instead of an IOException. Adding ToDataException handling to
> queryOneLocator() should fix the problem.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5579) `./gradlew :test` target should be able to be repeated without using `clean` or `--rerun-tasks`
[
https://issues.apache.org/jira/browse/GEODE-5579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nabarun updated GEODE-5579:
---
Fix Version/s: (was: 1.8.0)
1.7.0
> `./gradlew :test` target should be able to be repeated without using `clean`
> or `--rerun-tasks`
> ---
>
> Key: GEODE-5579
> URL: https://issues.apache.org/jira/browse/GEODE-5579
> Project: Geode
> Issue Type: Improvement
> Components: build
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> The unit-test target {{:test}} is able to be UP-TO-DATE to reduce the time
> cost of {{:build}}. However, developers may wish to rerun {{:test}} without
> fully compiling and rebuilding the source, as would occur with both {{clean}}
> and {{--rerun-tasks}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5648) Native Client docs: Add a page describing Continuous Queries
[ https://issues.apache.org/jira/browse/GEODE-5648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nabarun updated GEODE-5648: --- Fix Version/s: (was: 1.8.0) 1.7.0 > Native Client docs: Add a page describing Continuous Queries > > > Key: GEODE-5648 > URL: https://issues.apache.org/jira/browse/GEODE-5648 > Project: Geode > Issue Type: New Feature > Components: docs >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-5654) ThreadsMonitoringIntegrationTest is run as a UnitTest despite implicitly being an IntegrationTest
[
https://issues.apache.org/jira/browse/GEODE-5654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg resolved GEODE-5654.
-
Resolution: Fixed
> ThreadsMonitoringIntegrationTest is run as a UnitTest despite implicitly
> being an IntegrationTest
> -
>
> Key: GEODE-5654
> URL: https://issues.apache.org/jira/browse/GEODE-5654
> Project: Geode
> Issue Type: Improvement
> Components: tests
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> This is causing failures as we attempt to reduce the infrastructure required
> by the {{Build}} task in Concourse.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5662) Flaky unit test ExecutorServiceRuleTest.threadCountTwoHasTwoThreads
[
https://issues.apache.org/jira/browse/GEODE-5662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-5662:
--
Labels: pull-request-available swat (was: swat)
> Flaky unit test ExecutorServiceRuleTest.threadCountTwoHasTwoThreads
> ---
>
> Key: GEODE-5662
> URL: https://issues.apache.org/jira/browse/GEODE-5662
> Project: Geode
> Issue Type: Bug
>Reporter: Dan Smith
>Assignee: Kirk Lund
>Priority: Major
> Labels: pull-request-available, swat
>
> This test failed in CI. To me it looks like this test seems to be assuming
> that if it schedules two tasks they will actually run concurrently, which may
> or may not happen depending on timing.
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/Build/builds/403
> {noformat}
> org.apache.geode.test.junit.rules.ExecutorServiceRuleTest >
> threadCountTwoHasTwoThreads FAILED
> 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.test.junit.rules.ExecutorServiceRuleTest.threadCountTwoHasTwoThreads(ExecutorServiceRuleTest.java:130)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5344) race condition between Queue Removal Thread and Message Dispatcher can prevent dispatching to client
[ https://issues.apache.org/jira/browse/GEODE-5344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shelley Lynn Hughes-Godfrey resolved GEODE-5344. Resolution: Duplicate Fix Version/s: 1.7.0 > race condition between Queue Removal Thread and Message Dispatcher can > prevent dispatching to client > > > Key: GEODE-5344 > URL: https://issues.apache.org/jira/browse/GEODE-5344 > Project: Geode > Issue Type: Bug > Components: client queues >Reporter: Shelley Lynn Hughes-Godfrey >Assignee: Ryan McMahon >Priority: Major > Fix For: 1.7.0 > > > If a secondary server becomes primary while handling a Queue Removal Message > (containing a list of events already processed by the client), the Queue > Removal Message can remove that entry from the HAContainer just prior to the > Message Dispatcher attempting to dispatch the message. > Once that occurs, the Message Dispatcher (peek) gets stuck on that event and > cannot dispatch any other messages to that client. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5665) Create a check for POM file changes
[ https://issues.apache.org/jira/browse/GEODE-5665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-5665: -- Labels: pull-request-available (was: ) > Create a check for POM file changes > --- > > Key: GEODE-5665 > URL: https://issues.apache.org/jira/browse/GEODE-5665 > Project: Geode > Issue Type: Task > Components: build >Reporter: Finn Southerland >Priority: Major > Labels: pull-request-available > > Currently, we have to check if grade changes have affected published POM > files manually, and can miss changes easily. It would be good to have a test > of some kind to alert us if a POM changes, especially if dependencies change. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (GEODE-5600) Property file creation occurs any time .git/index is updated (which is all the time)
[
https://issues.apache.org/jira/browse/GEODE-5600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg reopened GEODE-5600:
-
Critically, the \{{SOURCE_REPOSITORY}} was not correctly added to the
{{pull-request/jinja.template.yml}}.
> Property file creation occurs any time .git/index is updated (which is all
> the time)
>
>
> Key: GEODE-5600
> URL: https://issues.apache.org/jira/browse/GEODE-5600
> Project: Geode
> Issue Type: Improvement
> Components: build
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.8.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Because the property file is an input for the {{jar}} target, this causes a
> significant increase in build time, even when nothing significant has changed.
>
> As a standard development cycle, regeneration of the property file should be
> optional / skipped.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-5665) Create a check for POM file changes
Finn Southerland created GEODE-5665: --- Summary: Create a check for POM file changes Key: GEODE-5665 URL: https://issues.apache.org/jira/browse/GEODE-5665 Project: Geode Issue Type: Task Components: build Reporter: Finn Southerland Currently, we have to check if grade changes have affected published POM files manually, and can miss changes easily. It would be good to have a test of some kind to alert us if a POM changes, especially if dependencies change. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5536) Parallelize unit tests
[ https://issues.apache.org/jira/browse/GEODE-5536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16596829#comment-16596829 ] ASF subversion and git services commented on GEODE-5536: Commit 574530cf55cad5011754eaee6c598b6ef8934e2e in geode's branch refs/heads/develop from [~rhoughton] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=574530c ] GEODE-5536: Force unitTest compilation to be dependency of source classes (#2337) * This dependency is consistent with all other test targets. Co-authored-by: Robert Houghton Co-authored-by: Dick Cavender > Parallelize unit tests > -- > > Key: GEODE-5536 > URL: https://issues.apache.org/jira/browse/GEODE-5536 > Project: Geode > Issue Type: Task >Reporter: Finn Southerland >Priority: Major > Labels: pull-request-available > Time Spent: 2.5h > Remaining Estimate: 0h > > Unit tests should run in parallel within subprojects. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-5601) AcceptanceTests are run in parallel without using containers, resulting in port conflicts
[
https://issues.apache.org/jira/browse/GEODE-5601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe resolved GEODE-5601.
-
Resolution: Fixed
Fix Version/s: 1.7.0
Closing this as fixed, although there is still room for improving
AcceptanceTest runs. After merging this fix, the total runtime for this
category increased by about 4 min (22 -> 26).
> AcceptanceTests are run in parallel without using containers, resulting in
> port conflicts
> -
>
> Key: GEODE-5601
> URL: https://issues.apache.org/jira/browse/GEODE-5601
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Jacob S. Barrett
>Assignee: Kenneth Howe
>Priority: Major
> Labels: flaky, pull-request-available, swat
> Fix For: 1.7.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> {noformat}
> org.apache.geode.management.internal.cli.commands.DeployWithLargeJarTest >
> deployLargeSetOfJars FAILED
> org.junit.ComparisonFailure: expected:<[0]> 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.test.junit.rules.gfsh.GfshScript.awaitIfNecessary(GfshScript.java:117)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:135)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:106)
> at
> org.apache.geode.management.internal.cli.commands.DeployWithLargeJarTest.deployLargeSetOfJars(DeployWithLargeJarTest.java:41)
> {noformat}
> Passes:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/pr-develop/jobs/AcceptanceTest/builds/721
> Fails:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/pr-develop/jobs/AcceptanceTest/builds/728
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5660) Add ability to lookup the GEODE-WEB-API war file from the classpath
[ https://issues.apache.org/jira/browse/GEODE-5660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16596788#comment-16596788 ] ASF subversion and git services commented on GEODE-5660: Commit de1133297a0df6957ea5615d872f573a9329b613 in geode's branch refs/heads/feature/GEODE-5660 from [~ukohlmeyer] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=de11332 ] GEODE-5660: spotless > Add ability to lookup the GEODE-WEB-API war file from the classpath > --- > > Key: GEODE-5660 > URL: https://issues.apache.org/jira/browse/GEODE-5660 > Project: Geode > Issue Type: Improvement > Components: rest (admin), rest (dev) >Reporter: Udo Kohlmeyer >Assignee: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > Fix For: 1.8.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > The current AgentUtil class only makes provision to lookup the > `geode-web-api` and `geode-web` war files from known locations. > When referencing the `geode-web-api` and `geode-web` war's from a > repository, the HTTP Services will fail, due to the requirement of having set > `GEODE_HOME` to the locally deployed GEODE distribution. > A way is required to reference the relevant war files from a repository and > not requiring the `GEODE_HOME` property to be specifically set. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5501) CI Failure: NetSearchMessagingDUnitTest.testOneMessageWithReplicates
[
https://issues.apache.org/jira/browse/GEODE-5501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith updated GEODE-5501:
-
Labels: (was: swat)
> CI Failure: NetSearchMessagingDUnitTest.testOneMessageWithReplicates
>
>
> Key: GEODE-5501
> URL: https://issues.apache.org/jira/browse/GEODE-5501
> Project: Geode
> Issue Type: Bug
>Reporter: Dan Smith
>Priority: Major
>
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.NetSearchMessagingDUnitTest$14.run in VM 0
> running on Host 4fad81dffa5f with 4 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:443)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:412)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:355)
> at
> org.apache.geode.internal.cache.NetSearchMessagingDUnitTest.createReplicate(NetSearchMessagingDUnitTest.java:425)
> at
> org.apache.geode.internal.cache.NetSearchMessagingDUnitTest.testOneMessageWithReplicates(NetSearchMessagingDUnitTest.java:57)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:106)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> at
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:66)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
> at com.sun.proxy.$Proxy1.processTestClass(Unknown Source)
> at
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
>
[jira] [Updated] (GEODE-5422) Flaky PersistentColocatedPartitionedRegionDUnitTest.testReplaceOfflineMemberAndRestart region does not exist.
[
https://issues.apache.org/jira/browse/GEODE-5422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith updated GEODE-5422:
-
Labels: flaky (was: flaky swat)
> Flaky
> PersistentColocatedPartitionedRegionDUnitTest.testReplaceOfflineMemberAndRestart
> region does not exist.
> -
>
> Key: GEODE-5422
> URL: https://issues.apache.org/jira/browse/GEODE-5422
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Jacob S. Barrett
>Priority: Major
> Labels: flaky
>
> Flaky test failure in CI but run fine most runs and locally.
> {noformat}
> org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDUnitTest
> > testReplaceOfflineMemberAndRestart 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 3784
> [error 2018/07/11 22:24:00.904 UTC
> tid=1075] Unexpected exception during bucket recovery
> java.lang.IllegalStateException: Region specified in 'colocated-with'
> (PersistentColocatedPartitionedRegionDUnitTest_testReplaceOfflineMemberAndRestartRegion)
> for region /region2 does not exist. It should be created before setting
> 'colocated-with' attribute for this region.
> at
> org.apache.geode.internal.cache.ColocationHelper.getColocatedRegion(ColocationHelper.java:94)
> at
> org.apache.geode.internal.cache.ColocationHelper.getLeaderRegion(ColocationHelper.java:455)
> at
> org.apache.geode.internal.cache.partitioned.PartitionedRegionRebalanceOp.(PartitionedRegionRebalanceOp.java:134)
> at
> org.apache.geode.internal.cache.partitioned.PartitionedRegionRebalanceOp.(PartitionedRegionRebalanceOp.java:114)
> at
> org.apache.geode.internal.cache.PRHARedundancyProvider$3.run2(PRHARedundancyProvider.java:1586)
> at
> org.apache.geode.internal.cache.partitioned.RecoveryRunnable.run(RecoveryRunnable.java:58)
> at
> org.apache.geode.internal.OneTaskOnlyExecutor$DelegatingRunnable.run(OneTaskOnlyExecutor.java:134)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5418) Many flaky tests in children of MultiVMRegionTestCase
[
https://issues.apache.org/jira/browse/GEODE-5418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith updated GEODE-5418:
-
Labels: (was: swat)
> Many flaky tests in children of MultiVMRegionTestCase
> -
>
> Key: GEODE-5418
> URL: https://issues.apache.org/jira/browse/GEODE-5418
> Project: Geode
> Issue Type: Bug
>Reporter: Patrick Rhomberg
>Priority: Major
> Attachments: DistributedTest_metrics.txt
>
>
> When running DIstributedTest 200+ times, we observed that this group of tests
> has many methods that are flaky
> {noformat}
> org.apache.geode.cache30.DiskDistributedNoAckAsyncOverflowRegionDUnitTest.testDistributedRegionDestroy:
> 1 failures (99.55947136563876% success rate)
> org.apache.geode.cache30.DiskDistributedNoAckSyncOverflowRegionDUnitTest.testEntryIdleDestroy:
> 1 failures (99.55947136563876% success rate)
> org.apache.geode.cache30.DistributedAckOverflowRegionCCEOffHeapDUnitTest.testClearWithConcurrentEventsAsync:
> 1 failures (99.55947136563876% success rate)
> org.apache.geode.cache30.DistributedAckOverflowRegionCCEOffHeapDUnitTest.testConcurrentEventsOnNonReplicatedRegion:
> 2 failures (99.11894273127754% success rate)
> org.apache.geode.cache30.DistributedAckPersistentRegionCCEDUnitTest.testClearWithConcurrentEvents:
> 1 failures (99.55947136563876% success rate)
> org.apache.geode.cache30.DistributedAckPersistentRegionCCEOffHeapDUnitTest.testInvalidateEntry:
> 1 failures (99.55947136563876% success rate)
> org.apache.geode.cache30.DistributedAckPersistentRegionCCEOffHeapDUnitTest.testNBRegionDestructionDuringGetInitialImage:
> 1 failures (99.55947136563876% success rate)
> org.apache.geode.cache30.DistributedAckPersistentRegionCCEOffHeapDUnitTest.testNetSearchObservesIdleTime:
> 1 failures (99.55947136563876% success rate)
> org.apache.geode.cache30.DistributedAckPersistentRegionCCEOffHeapDUnitTest.testNonblockingGetInitialImage:
> 2 failures (99.11894273127754% success rate)
> org.apache.geode.cache30.DistributedAckPersistentRegionCCEOffHeapDUnitTest.testTombstones:
> 1 failures (99.55947136563876% success rate)
> org.apache.geode.cache30.DistributedNoAckRegionCCEDUnitTest.testEntryIdleDestroy:
> 1 failures (99.55947136563876% success rate)
> org.apache.geode.cache30.DistributedNoAckRegionCCEDUnitTest.testTXMultiRegion:
> 1 failures (99.55947136563876% success rate)
> org.apache.geode.cache30.DistributedNoAckRegionCCEDUnitTest.testTXRmtMirror:
> 3 failures (98.6784140969163% success rate)
> org.apache.geode.cache30.DistributedNoAckRegionCCEOffHeapDUnitTest.testConcurrentEventsOnNonReplicatedRegion:
> 2 failures (99.11894273127754% success rate)
> org.apache.geode.cache30.DistributedNoAckRegionCCEOffHeapDUnitTest.testRegionIdleInvalidate:
> 1 failures (99.55947136563876% success rate)
> org.apache.geode.cache30.DistributedNoAckRegionCCEOffHeapDUnitTest.testTXRmtMirror:
> 3 failures (98.6784140969163% success rate)
> org.apache.geode.cache30.DistributedNoAckRegionCCEOffHeapDUnitTest.testTombstones:
> 1 failures (99.55947136563876% success rate)
> org.apache.geode.cache30.DistributedNoAckRegionDUnitTest.testTXRmtMirror: 5
> failures (97.79735682819384% success rate)
> org.apache.geode.cache30.DistributedNoAckRegionOffHeapDUnitTest.testMirroredLocalLoad:
> 1 failures (99.55947136563876% success rate)
> org.apache.geode.cache30.DistributedNoAckRegionOffHeapDUnitTest.testTXRmtMirror:
> 8 failures (96.47577092511013% success rate)
> org.apache.geode.cache30.PartitionedRegionOffHeapDUnitTest.testDistributedUpdate:
> 7 failures (96.91629955947137% success rate)
> {noformat}
> Whoever picks this up can split these out if they are not related, but
> leaving them as a single ticket here in case they have a common cause.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5419) PersistentPartitionedRegionDistributedTest is brittle to other disk failures
[
https://issues.apache.org/jira/browse/GEODE-5419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith updated GEODE-5419:
-
Labels: (was: swat)
> PersistentPartitionedRegionDistributedTest is brittle to other disk failures
>
>
> Key: GEODE-5419
> URL: https://issues.apache.org/jira/browse/GEODE-5419
> Project: Geode
> Issue Type: Bug
>Reporter: Patrick Rhomberg
>Priority: Major
>
> In this concourse run it looks like
> PersistentPartitionedRegionDistributedTest had multiple failures after a
> previous failed test. We suspect some disk files were left around between
> test runs that caused these failures.
> We should fix these tests to be more robust and clean up their environment
> before starting.
> [Failure
> results|http://staging-files.apachegeode-ci.info/builds/1.8.0-1.3.0/test-results/disitributedTest/1531274835/]
> [Concourse
> run|https://concourse.apachegeode-ci.info/teams/staging/pipelines/mass-dist/jobs/DistributedTest/builds/153],
> requiring access to {{staging}}. If desired, contact d...@geode.apache.org.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-4934) CI Failure: GfshScript timing out intermittently waiting for execution to complete
[
https://issues.apache.org/jira/browse/GEODE-4934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith resolved GEODE-4934.
--
Resolution: Won't Fix
We had systematic issues with the acceptance tests due to GEODE-5601. We can
reopen this issue if we still see failures after that bug is fixed.
> CI Failure: GfshScript timing out intermittently waiting for execution to
> complete
> --
>
> Key: GEODE-4934
> URL: https://issues.apache.org/jira/browse/GEODE-4934
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Affects Versions: 1.5.0
>Reporter: Kenneth Howe
>Priority: Major
> Labels: CI, pull-request-available, swat
> Time Spent: 40m
> Remaining Estimate: 0h
>
> GfshScript.awaitIfNecessary native method call to determine if the process
> executing the script is alive hangs. This is not a hard failure, but it can
> be reproduced with frequently running selected tests from command line. This
> following set of tests produces failures when run on a Linux host (tested on
> CentOS 7).
> {code}
> ./gradlew clean geode-lucene:precheckin --parallel -x rat -x javadoc -x
> spotlessCheck{code}
> {code}
> {code:title=Typical failure stack}
> org.apache.geode.management.internal.cli.commands.StopServerAcceptanceTest >
> cannotStopServerByNameWhenNotConnected FAILED
> org.junit.ComparisonFailure: expected:<[0]> 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.test.junit.rules.gfsh.GfshScript.awaitIfNecessary(GfshScript.java:116)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:98)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:87)
> at
> org.apache.geode.management.internal.cli.commands.StopServerAcceptanceTest.startCluster(StopServerAcceptanceTest.java:35)
> {code}
> All failures show the same stack from {{at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:98)}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-4887) ci Failure: PartitionedRegionOffHeapDUnitTest.testDistributedUpdate
[
https://issues.apache.org/jira/browse/GEODE-4887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith updated GEODE-4887:
-
Labels: (was: swat)
> ci Failure: PartitionedRegionOffHeapDUnitTest.testDistributedUpdate
> ---
>
> Key: GEODE-4887
> URL: https://issues.apache.org/jira/browse/GEODE-4887
> Project: Geode
> Issue Type: Bug
> Components: offheap
>Affects Versions: 1.5.0
>Reporter: Eric Shu
>Priority: Major
>
> org.apache.geode.cache30.PartitionedRegionOffHeapDUnitTest >
> testDistributedUpdate FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache30.PartitionedRegionOffHeapDUnitTest$1.run in VM 1
> running on Host 34d5b30e2f93 with 4 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:401)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:370)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:313)
> at org.apache.geode.test.dunit.Invoke.invokeInEveryVM(Invoke.java:59)
> at org.apache.geode.test.dunit.Invoke.invokeInEveryVM(Invoke.java:48)
> at
> org.apache.geode.cache30.PartitionedRegionOffHeapDUnitTest.preTearDownAssertions(PartitionedRegionOffHeapDUnitTest.java:49)
> Caused by:
> java.lang.AssertionError:
> Expecting empty but was:<[MemoryBlock{MemoryAddress=139834149486752,
> State=ALLOCATED, BlockSize=24, SlabId=0, FreeListId=NONE, RefCount=1,
> isSerialized=true, isCompressed=false, DataType=java.lang.String,
> DataValue=NEW_VALUE}]>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-4128) CI failure: org.apache.geode.session.tests.Jetty9Test > newContainersShouldShareDataAccess
[ https://issues.apache.org/jira/browse/GEODE-4128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith resolved GEODE-4128. -- Resolution: Duplicate > CI failure: org.apache.geode.session.tests.Jetty9Test > > newContainersShouldShareDataAccess > -- > > Key: GEODE-4128 > URL: https://issues.apache.org/jira/browse/GEODE-4128 > Project: Geode > Issue Type: Bug > Components: http session >Affects Versions: 1.4.0 >Reporter: Shelley Lynn Hughes-Godfrey >Priority: Major > Labels: swat > > org.apache.geode.session.tests.Jetty9Test > > newContainersShouldShareDataAccess FAILED > org.codehaus.cargo.container.ContainerException: Failed to stop the Jetty > 9.4.5.v20170502 container. Check the > [/tmp/build/ae3c03f4/built-gemfire/test/geode/geode-assembly/build/distributedTest28/cargo_logs/JETTY9_peer-to-peer_newContainersShouldShareDataAccess_1_6875641539702712/container.log] > file containing the container logs for more details. > Caused by: > org.codehaus.cargo.container.ContainerException: Server port 21013 > did not shutdown within the timeout period [12] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5394) ClientServerMiscBCDUnitTest.testRegionClose failed in CI
[
https://issues.apache.org/jira/browse/GEODE-5394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith updated GEODE-5394:
-
Labels: pull-request-available (was: pull-request-available swat)
> ClientServerMiscBCDUnitTest.testRegionClose failed in CI
>
>
> Key: GEODE-5394
> URL: https://issues.apache.org/jira/browse/GEODE-5394
> Project: Geode
> Issue Type: Bug
>Reporter: Dan Smith
>Priority: Major
> Labels: pull-request-available
> Attachments: Test results - Class
> org.apache.geode.internal.cache.tier.sockets.ClientServerMiscBCDUnitTest.html
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> This test failed in a recent CI run on
> 10d8dabdfa39dde490ae2ebf7a5ece4786cea661
>
> {noformat}
> org.apache.geode.internal.cache.tier.sockets.ClientServerMiscBCDUnitTest >
> testRegionClose[3] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.tier.sockets.ClientServerMiscDUnitTest$$Lambda$111/993337154.run
> in VM 2 running on Host fe6abf8a5e6f with 5 VMs
> Caused by:
> java.lang.AssertionError: Event never occurred after 4 ms: null
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-3506) LocatorLauncherRemoteFileIntegrationTest.startDeletesStaleControlFiles fails intermittently with IllegalStateException: Failed to read status file
[
https://issues.apache.org/jira/browse/GEODE-3506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith updated GEODE-3506:
-
Labels: CI (was: CI swat)
> LocatorLauncherRemoteFileIntegrationTest.startDeletesStaleControlFiles fails
> intermittently with IllegalStateException: Failed to read status file
> --
>
> Key: GEODE-3506
> URL: https://issues.apache.org/jira/browse/GEODE-3506
> Project: Geode
> Issue Type: Bug
> Components: gfsh, management
>Reporter: Kirk Lund
>Priority: Major
> Labels: CI
>
> {noformat}
> org.apache.geode.distributed.LocatorLauncherRemoteFileIntegrationTest >
> startDeletesStaleControlFiles FAILED
> java.lang.IllegalStateException: Failed to read status file
> {noformat}
> Full stack trace:
> {noformat}
> java.lang.IllegalStateException: Failed to read status file
> at
> org.apache.geode.internal.process.FileProcessController.status(FileProcessController.java:152)
> at
> org.apache.geode.internal.process.FileProcessController.status(FileProcessController.java:89)
> at
> org.apache.geode.distributed.LocatorLauncher.statusWithWorkingDirectory(LocatorLauncher.java:940)
> at
> org.apache.geode.distributed.LocatorLauncher.status(LocatorLauncher.java:868)
> at
> org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase.lambda$awaitStart$1(LocatorLauncherRemoteIntegrationTestCase.java:196)
> at
> org.awaitility.core.AssertionCondition$1.eval(AssertionCondition.java:55)
> at
> org.awaitility.core.ConditionAwaiter$ConditionPoller.run(ConditionAwaiter.java:215)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5395) LuceneSearchWithRollingUpgradeDUnit.luceneQueryReturnsCorrectResultAfterTwoLocatorsWithTwoServersAreRolled failed in CI
[
https://issues.apache.org/jira/browse/GEODE-5395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith updated GEODE-5395:
-
Labels: (was: swat)
> LuceneSearchWithRollingUpgradeDUnit.luceneQueryReturnsCorrectResultAfterTwoLocatorsWithTwoServersAreRolled
> failed in CI
> ---
>
> Key: GEODE-5395
> URL: https://issues.apache.org/jira/browse/GEODE-5395
> Project: Geode
> Issue Type: Bug
>Reporter: Dan Smith
>Priority: Major
> Attachments: Test results - Class
> org.apache.geode.cache.lucene.LuceneSearchWithRollingUpgradeDUnit.html
>
>
> This test failed in a recent CI run on rev
> 10d8dabdfa39dde490ae2ebf7a5ece4786cea661
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/98]
>
> {noformat}
> org.apache.geode.cache.lucene.LuceneSearchWithRollingUpgradeDUnit >
> luceneQueryReturnsCorrectResultAfterTwoLocatorsWithTwoServersAreRolled[from_v130]
> 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 15631
> [fatal 2018/07/06 00:50:18.077 UTC
> tid=0xab] Possible loss of quorum due to the loss of 1 cache processes:
> [172.17.0.2(11555):32772]
> ---
> Found suspect string in log4j at line 15640
> [fatal 2018/07/06 00:50:19.080 UTC
> tid=0xab] Membership service failure: Exiting due to possible network
> partition event due to loss of 1 cache processes:
> [172.17.0.2(11555):32772]
> org.apache.geode.ForcedDisconnectException: Exiting due to possible
> network partition event due to loss of 1 cache processes:
> [172.17.0.2(11555):32772]
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.forceDisconnect(GMSMembershipManager.java:2543)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.forceDisconnect(GMSJoinLeave.java:1044)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.access$1500(GMSJoinLeave.java:91)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave$ViewCreator.prepareAndSendView(GMSJoinLeave.java:2484)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave$ViewCreator.sendInitialView(GMSJoinLeave.java:2115)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave$ViewCreator.run(GMSJoinLeave.java:2193)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5662) Flaky unit test ExecutorServiceRuleTest.threadCountTwoHasTwoThreads
[
https://issues.apache.org/jira/browse/GEODE-5662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16596755#comment-16596755
]
Kirk Lund commented on GEODE-5662:
--
ExecutorServiceRuleTest.singleThreadedByDefault is also flaky. It's caused by
awaiting maximum of 30 seconds for submitted tasks to countDown a
CountDownLatch. The CPU has to be very overloaded to hit these failures.
{noformat}
org.apache.geode.test.junit.rules.ExecutorServiceRuleTest >
singleThreadedByDefault FAILED
org.junit.ComparisonFailure: expected:<[1]> but was:<[2]>
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.test.junit.rules.ExecutorServiceRuleTest.singleThreadedByDefault(ExecutorServiceRuleTest.java:122)
{noformat}
> Flaky unit test ExecutorServiceRuleTest.threadCountTwoHasTwoThreads
> ---
>
> Key: GEODE-5662
> URL: https://issues.apache.org/jira/browse/GEODE-5662
> Project: Geode
> Issue Type: Bug
>Reporter: Dan Smith
>Assignee: Kirk Lund
>Priority: Major
> Labels: swat
>
> This test failed in CI. To me it looks like this test seems to be assuming
> that if it schedules two tasks they will actually run concurrently, which may
> or may not happen depending on timing.
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/Build/builds/403
> {noformat}
> org.apache.geode.test.junit.rules.ExecutorServiceRuleTest >
> threadCountTwoHasTwoThreads FAILED
> 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.test.junit.rules.ExecutorServiceRuleTest.threadCountTwoHasTwoThreads(ExecutorServiceRuleTest.java:130)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5564) Flaky tes ConcurrentIndexInitOnOverflowRegionDUnitTest > testIndexUpdateWithRegionClea
[
https://issues.apache.org/jira/browse/GEODE-5564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith updated GEODE-5564:
-
Labels: flaky (was: flaky swat)
> Flaky tes ConcurrentIndexInitOnOverflowRegionDUnitTest >
> testIndexUpdateWithRegionClea
> --
>
> Key: GEODE-5564
> URL: https://issues.apache.org/jira/browse/GEODE-5564
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.8.0
>Reporter: Jacob S. Barrett
>Priority: Major
> Labels: flaky
>
> {noformat}
> org.apache.geode.cache.query.internal.index.ConcurrentIndexInitOnOverflowRegionDUnitTest
> > testIndexUpdateWithRegionClear FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.query.internal.index.ConcurrentIndexInitOnOverflowRegionDUnitTest$12.run
> in VM 0 running on Host 92f89c21d1b0 with 4 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:443)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:412)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:355)
> at
> org.apache.geode.cache.query.internal.index.ConcurrentIndexInitOnOverflowRegionDUnitTest.testIndexUpdateWithRegionClear(ConcurrentIndexInitOnOverflowRegionDUnitTest.java:411)
> Caused by:
> java.lang.AssertionError: After clear region size is supposed to be
> zero as all index updates are blocked. Current region size is: 13
> at org.junit.Assert.fail(Assert.java:88)
> at
> org.apache.geode.cache.query.internal.index.ConcurrentIndexInitOnOverflowRegionDUnitTest$12.run2(ConcurrentIndexInitOnOverflowRegionDUnitTest.java:430)
> {noformat}
> Failing:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/pr-develop/jobs/DistributedTest/builds/556
> Passing:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/pr-develop/jobs/DistributedTest/builds/547
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-5662) Flaky unit test ExecutorServiceRuleTest.threadCountTwoHasTwoThreads
[
https://issues.apache.org/jira/browse/GEODE-5662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund reassigned GEODE-5662:
Assignee: Kirk Lund
> Flaky unit test ExecutorServiceRuleTest.threadCountTwoHasTwoThreads
> ---
>
> Key: GEODE-5662
> URL: https://issues.apache.org/jira/browse/GEODE-5662
> Project: Geode
> Issue Type: Bug
>Reporter: Dan Smith
>Assignee: Kirk Lund
>Priority: Major
> Labels: swat
>
> This test failed in CI. To me it looks like this test seems to be assuming
> that if it schedules two tasks they will actually run concurrently, which may
> or may not happen depending on timing.
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/Build/builds/403
> {noformat}
> org.apache.geode.test.junit.rules.ExecutorServiceRuleTest >
> threadCountTwoHasTwoThreads FAILED
> 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.test.junit.rules.ExecutorServiceRuleTest.threadCountTwoHasTwoThreads(ExecutorServiceRuleTest.java:130)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5601) AcceptanceTests are run in parallel without using containers, resulting in port conflicts
[
https://issues.apache.org/jira/browse/GEODE-5601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16596742#comment-16596742
]
ASF subversion and git services commented on GEODE-5601:
Commit ad37e34eaf00b94f13cbf4dd0f9e435a987af86b in geode's branch
refs/heads/windows-heavy-lifter from [~khowe]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=ad37e34 ]
GEODE-5601: Serialize running of acceptance tests in lieu of containerizing
them (#2389)
* GEODE-5601: Serialize running of acceptance tests in lieu of containerizing
them
Fix flaky AccpetanceTest runs by running them serially. Note that this does
make a
hit on the runtime (~ 10% in testing) for this category of test.
> AcceptanceTests are run in parallel without using containers, resulting in
> port conflicts
> -
>
> Key: GEODE-5601
> URL: https://issues.apache.org/jira/browse/GEODE-5601
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Jacob S. Barrett
>Assignee: Kenneth Howe
>Priority: Major
> Labels: flaky, pull-request-available, swat
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> {noformat}
> org.apache.geode.management.internal.cli.commands.DeployWithLargeJarTest >
> deployLargeSetOfJars FAILED
> org.junit.ComparisonFailure: expected:<[0]> 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.test.junit.rules.gfsh.GfshScript.awaitIfNecessary(GfshScript.java:117)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:135)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:106)
> at
> org.apache.geode.management.internal.cli.commands.DeployWithLargeJarTest.deployLargeSetOfJars(DeployWithLargeJarTest.java:41)
> {noformat}
> Passes:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/pr-develop/jobs/AcceptanceTest/builds/721
> Fails:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/pr-develop/jobs/AcceptanceTest/builds/728
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5654) ThreadsMonitoringIntegrationTest is run as a UnitTest despite implicitly being an IntegrationTest
[
https://issues.apache.org/jira/browse/GEODE-5654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16596744#comment-16596744
]
ASF subversion and git services commented on GEODE-5654:
Commit 7c57aefe3e44379920868459cc0b71f3b8d13338 in geode's branch
refs/heads/windows-heavy-lifter from [~dcavender]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=7c57aef ]
Merge pull request #2396 from PurelyApplied/geode-5654
GEODE-5654: Move integration test out of unitTest directory.
> ThreadsMonitoringIntegrationTest is run as a UnitTest despite implicitly
> being an IntegrationTest
> -
>
> Key: GEODE-5654
> URL: https://issues.apache.org/jira/browse/GEODE-5654
> Project: Geode
> Issue Type: Improvement
> Components: tests
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> This is causing failures as we attempt to reduce the infrastructure required
> by the {{Build}} task in Concourse.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5599) Flaky: Pipeline failure AlterRuntimeCommandDUnitTest.alterStatArchiveFile_updatesAllServerConfigs
[
https://issues.apache.org/jira/browse/GEODE-5599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith resolved GEODE-5599.
--
Resolution: Duplicate
> Flaky: Pipeline failure
> AlterRuntimeCommandDUnitTest.alterStatArchiveFile_updatesAllServerConfigs
> -
>
> Key: GEODE-5599
> URL: https://issues.apache.org/jira/browse/GEODE-5599
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Mark Hanson
>Priority: Major
> Labels: swat
> Attachments: Archive.zip
>
>
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.rules.ClusterStartupRule$$Lambda$41/1739841203.call
> in VM 0 running on Host 074d29a069db with 4 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:443)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:412)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:378)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.startLocatorVM(ClusterStartupRule.java:188)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.startLocatorVM(ClusterStartupRule.java:181)
> at
> org.apache.geode.management.internal.cli.commands.AlterRuntimeCommandDUnitTest.alterStatArchiveFile_updatesAllServerConfigs(AlterRuntimeCommandDUnitTest.java:428)
> 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
> junitparams.internal.InvokeParameterisedMethod.evaluate(InvokeParameterisedMethod.java:234)
> at
> org.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:40)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at
> junitparams.internal.ParameterisedTestMethodRunner.runMethodInvoker(ParameterisedTestMethodRunner.java:47)
> at
> junitparams.internal.ParameterisedTestMethodRunner.runTestMethod(ParameterisedTestMethodRunner.java:40)
> at
> junitparams.internal.ParameterisedTestClassRunner.runParameterisedTest(ParameterisedTestClassRunner.java:146)
> at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:446)
> at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:393)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:106)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> at
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:66)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
> at
[jira] [Commented] (GEODE-5530) Extract shared test code from test in to frameworks
[
https://issues.apache.org/jira/browse/GEODE-5530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16596743#comment-16596743
]
ASF subversion and git services commented on GEODE-5530:
Commit 8ae1bdbde6dee657e7603b5da37b39101c24ddb5 in geode's branch
refs/heads/windows-heavy-lifter from Jacob Barrett
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=8ae1bdb ]
GEODE-5530: Moves more shared test code into the DUnit framework.
> Extract shared test code from test in to frameworks
> ---
>
> Key: GEODE-5530
> URL: https://issues.apache.org/jira/browse/GEODE-5530
> Project: Geode
> Issue Type: Improvement
> Components: tests
>Reporter: Jacob S. Barrett
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 8h 50m
> Remaining Estimate: 0h
>
> Many tests between modules share code. Move this code into common frameworks,
> {{geode-junit}} and {{geode-dunit}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5661) Pulse does not work when legacy SSL options are used
[
https://issues.apache.org/jira/browse/GEODE-5661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16596745#comment-16596745
]
ASF subversion and git services commented on GEODE-5661:
Commit 7aee737d89a6e9cbec7c7759a75a83ab9ba29965 in geode's branch
refs/heads/windows-heavy-lifter from [~jens.deppe]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=7aee737 ]
GEODE-5661: Pulse does not work when legacy SSL options are used (#2401)
> Pulse does not work when legacy SSL options are used
>
>
> Key: GEODE-5661
> URL: https://issues.apache.org/jira/browse/GEODE-5661
> Project: Geode
> Issue Type: Bug
> Components: pulse
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Similar to GEODE-5230, if the legacy SSL configuration options are used,
> ({{cluster-ssl-*}}, {{jmx-manager-ssl-*}}, etc.), then Pulse does not work
> correctly and a user will see an error similar to the following in the UI:
> {noformat}
> Failed to retrieve RMIServer stub: javax.naming.CommunicationException [Root
> exception is java.rmi.ConnectIOException: error during JRMP connection
> establishment; nested exception is: javax.net.ssl.SSLHandshakeException:
> sun.security.validator.ValidatorException: PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5601) AcceptanceTests are run in parallel without using containers, resulting in port conflicts
[
https://issues.apache.org/jira/browse/GEODE-5601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16596741#comment-16596741
]
ASF subversion and git services commented on GEODE-5601:
Commit ad37e34eaf00b94f13cbf4dd0f9e435a987af86b in geode's branch
refs/heads/windows-heavy-lifter from [~khowe]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=ad37e34 ]
GEODE-5601: Serialize running of acceptance tests in lieu of containerizing
them (#2389)
* GEODE-5601: Serialize running of acceptance tests in lieu of containerizing
them
Fix flaky AccpetanceTest runs by running them serially. Note that this does
make a
hit on the runtime (~ 10% in testing) for this category of test.
> AcceptanceTests are run in parallel without using containers, resulting in
> port conflicts
> -
>
> Key: GEODE-5601
> URL: https://issues.apache.org/jira/browse/GEODE-5601
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Jacob S. Barrett
>Assignee: Kenneth Howe
>Priority: Major
> Labels: flaky, pull-request-available, swat
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> {noformat}
> org.apache.geode.management.internal.cli.commands.DeployWithLargeJarTest >
> deployLargeSetOfJars FAILED
> org.junit.ComparisonFailure: expected:<[0]> 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.test.junit.rules.gfsh.GfshScript.awaitIfNecessary(GfshScript.java:117)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:135)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:106)
> at
> org.apache.geode.management.internal.cli.commands.DeployWithLargeJarTest.deployLargeSetOfJars(DeployWithLargeJarTest.java:41)
> {noformat}
> Passes:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/pr-develop/jobs/AcceptanceTest/builds/721
> Fails:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/pr-develop/jobs/AcceptanceTest/builds/728
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5636) DescribeClientCommandDUnitTest fails on Windows
[
https://issues.apache.org/jira/browse/GEODE-5636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16596739#comment-16596739
]
ASF subversion and git services commented on GEODE-5636:
Commit 238706c1c851a6ae8c11ed216354cf2599917256 in geode's branch
refs/heads/windows-heavy-lifter from [~jens.deppe]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=238706c ]
GEODE-5636: DescribeClientCommandDUnitTest fails on Windows (#2382)
> DescribeClientCommandDUnitTest fails on Windows
> ---
>
> Key: GEODE-5636
> URL: https://issues.apache.org/jira/browse/GEODE-5636
> Project: Geode
> Issue Type: Bug
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The test was making incorrect assumptions about the order of `list members`
> {noformat}
> org.apache.geode.management.internal.cli.commands.DescribeClientCommandDUnitTest
> > describeClient FAILED
> org.junit.ComparisonFailure:
> expected:<"10.0.0.4([locator-0:9816:locator):32773 [Coordinator]]">
> but was:<"10.0.0.4([server-1:9292):32772]">
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.management.internal.cli.commands.DescribeClientCommandDUnitTest.validateResults(DescribeClientCommandDUnitTest.java:144)
> at
> org.apache.geode.management.internal.cli.commands.DescribeClientCommandDUnitTest.describeClient(DescribeClientCommandDUnitTest.java:103)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5656) Upgrade build to use Gradle 4.10
[ https://issues.apache.org/jira/browse/GEODE-5656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16596740#comment-16596740 ] ASF subversion and git services commented on GEODE-5656: Commit be5430d92966733fbdfe9d63e60bc7ef0168ea76 in geode's branch refs/heads/windows-heavy-lifter from Jacob Barrett [ https://gitbox.apache.org/repos/asf?p=geode.git;h=be5430d ] GEODE-5656: Upgrades Gradle to 4.10 (#2397) > Upgrade build to use Gradle 4.10 > > > Key: GEODE-5656 > URL: https://issues.apache.org/jira/browse/GEODE-5656 > Project: Geode > Issue Type: Improvement > Components: build >Reporter: Jacob S. Barrett >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 50m > Remaining Estimate: 0h > > https://docs.gradle.org/4.10/release-notes.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5637) Flaky: SingleHopClientExecutorSubmitTaskWithExceptionTest fails intermittently
[
https://issues.apache.org/jira/browse/GEODE-5637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16596738#comment-16596738
]
ASF subversion and git services commented on GEODE-5637:
Commit 34ec00147c01b043ebc5094e6e699469756245b4 in geode's branch
refs/heads/windows-heavy-lifter from [~apa...@the9muses.net]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=34ec001 ]
GEODE-5637: disable SingleHopClientExecutorWithLoggingIntegrationTest
This test is super flaky and seems to consistently fail on Windows. It's
trying to use SystemErrRule to test logging which doesn't really work
very well. I think the test needs to be rewritten with a Log4J2 Appender
instead of trying to use stdout or stderr. I'm going to disable it with
Ignore until I can get this rewritten.
Discussed with and reviewed by Sai.
> Flaky: SingleHopClientExecutorSubmitTaskWithExceptionTest fails intermittently
> --
>
> Key: GEODE-5637
> URL: https://issues.apache.org/jira/browse/GEODE-5637
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: flaky, pull-request-available, swat
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> This test should also be an integration test but it's in the test src set.
> {noformat}
> > Task :geode-core:test
> org.apache.geode.cache.client.internal.SingleHopClientExecutorSubmitTaskWithExceptionTest
> > submittedTaskShouldLogFailure FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.cache.client.internal.SingleHopClientExecutorSubmitTaskWithExceptionTest
>
> Expecting:
> <"">
> to contain:
> <"I am expecting this to be logged"> within 2 minutes.
> 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:890)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:711)
> at
> org.apache.geode.cache.client.internal.SingleHopClientExecutorSubmitTaskWithExceptionTest.submittedTaskShouldLogFailure(SingleHopClientExecutorSubmitTaskWithExceptionTest.java:54)
> Caused by:
> java.lang.AssertionError:
> Expecting:
> <"">
> to contain:
> <"I am expecting this to be logged">
> at
> org.apache.geode.cache.client.internal.SingleHopClientExecutorSubmitTaskWithExceptionTest.lambda$submittedTaskShouldLogFailure$1(SingleHopClientExecutorSubmitTaskWithExceptionTest.java:54)
> 4490 tests completed, 1 failed, 9 skipped
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5655) Flaky: org.apache.geode.session.tests.Jetty9Test.containersShouldShareDataRemovals fails intermittently
[
https://issues.apache.org/jira/browse/GEODE-5655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith resolved GEODE-5655.
--
Resolution: Duplicate
Fix Version/s: GEODE-3613
> Flaky:
> org.apache.geode.session.tests.Jetty9Test.containersShouldShareDataRemovals
> fails intermittently
> ---
>
> Key: GEODE-5655
> URL: https://issues.apache.org/jira/browse/GEODE-5655
> Project: Geode
> Issue Type: Bug
> Components: http session, tests
>Reporter: Kirk Lund
>Priority: Major
> Labels: Flaky, swat
> Fix For: GEODE-3613
>
>
> Failed in build
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/321
> {noformat}
> > Task :geode-assembly:distributedTest
> org.apache.geode.session.tests.Jetty9Test > containersShouldShareDataRemovals
> FAILED
> org.codehaus.cargo.container.ContainerException: Failed to stop the Jetty
> 9.4.8.v20171121 container. Check the
> [/home/geode/geode/geode-assembly/build/distributedTest108/cargo_logs/JETTY9_peer-to-peer_containersShouldShareDataRemovals_0_835922884062/container.log]
> file containing the container logs for more details.
> Caused by:
> org.codehaus.cargo.container.ContainerException: Server port 21121
> did not shutdown within the timeout period [12]
> 166 tests completed, 1 failed
> > Task :geode-assembly:distributedTest FAILED
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5594) Enable endpoint validation during using SSL handshake
[ https://issues.apache.org/jira/browse/GEODE-5594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16596708#comment-16596708 ] ASF subversion and git services commented on GEODE-5594: Commit 64845ab35f8c231e258993b36656f1c5b03b3934 in geode's branch refs/heads/develop from [~sai.boorlaga...@gmail.com] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=64845ab ] GEODE-5594: Rename SSL hostname validation property name (#2398) renamed ssl-enable-endpoint-identification to ssl-endpoint-identification-enabled. > Enable endpoint validation during using SSL handshake > - > > Key: GEODE-5594 > URL: https://issues.apache.org/jira/browse/GEODE-5594 > Project: Geode > Issue Type: Improvement > Components: client/server, docs >Reporter: Sai Boorlagadda >Assignee: Sai Boorlagadda >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Users can set `ssl-endpoint-identification-enabled` to true to enable > validation of hostname in server's identity when using SSL to harden against > certain man-in-the-middle attacks -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-5664) Start instance script fails if instance somehow already exists
Sean Goller created GEODE-5664: -- Summary: Start instance script fails if instance somehow already exists Key: GEODE-5664 URL: https://issues.apache.org/jira/browse/GEODE-5664 Project: Geode Issue Type: Bug Components: ci Reporter: Sean Goller When a CI build job involving heavy lifters is executed, if an instance already exists with the same calculated name, the job will fail permanently. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5645) Client cache misses invalidate
[
https://issues.apache.org/jira/browse/GEODE-5645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16596698#comment-16596698
]
ASF subversion and git services commented on GEODE-5645:
Commit bccd84e4d96db0669e8b74fd115b4f49a70621e3 in geode's branch
refs/heads/feature/GEODE-5645 from [~bschuchardt]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=bccd84e ]
GEODE-5645 Client cache misses invalidate
Extracted common code to a new method
> Client cache misses invalidate
> --
>
> Key: GEODE-5645
> URL: https://issues.apache.org/jira/browse/GEODE-5645
> Project: Geode
> Issue Type: Bug
> Components: client queues
>Reporter: Bruce Schuchardt
>Priority: Major
> Labels: pull-request-available
> Time Spent: 40m
> Remaining Estimate: 0h
>
> In a test with four clients and four servers with the clients performing
> concurrent operations on the same keys one of the clients missed an
> "invalidate" event and ended up being inconsistent.
> There was a cache entry in the servers sitting at version 2. Client4 is the
> cache that ends up being inconsistent by way of its subscription feed.
> client1 does v3 invalidate with server1
> client2 does v4 update with server2
> client3 does v5 invalidate with server3
> server4 receives v3 invalidate and informs clients
> client4 gets v3 invalidate through subscription
> server4 receives v5 invalidate and ignores it because its already invalidated
> server4 receives v4 update from server2
> server4 throws concurrency conflict exception for v4 update
> client4 gets v4 update (applied as a create) from server4 through subscription
> Clients with queues on other servers get the ops in order and end up with an
> invalidated entry.
> client4 does not get the final invalidate event and is inconsistent wrt other
> clients and the servers.
> With fine level logging the log statement that shows the problem happening is
> this:
> {noformat}
> mapInvalidate: Entry already invalid: 'Object_1683'
> {noformat}
> Where Object_1683 is the key for the entry we're dealing with.
> The code doing this is in AbstractRegionMap's invalidate() method:
> {code}
> if (oldRe.isInvalid()) {
> // was already invalid, do not invoke listeners or
> increment stat
> if (isDebugEnabled) {
> logger.debug("mapInvalidate: Entry already invalid:
> '{}'",
> event.getKey());
> }
> processVersionTag(oldRe, event);
> try {
> oldRe.setValue(owner, oldRe.getValueInVM(owner));
> // OFFHEAP noop setting
>
> // an already invalid to
>
> // invalid; No need to
>
> // call
>
> // prepareValueForCache
>
> // since it is an
>
> // invalid token.
> } catch (RegionClearedException e) {
> // that's okay - when writing an invalid into a
> disk, the
> // region has been cleared (including this token)
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5663) Flaky: LoginHandlerInterceptorJUnitTest.testHandlerInterceptorThreadSafety intermittent failures
[
https://issues.apache.org/jira/browse/GEODE-5663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe resolved GEODE-5663.
-
Resolution: Duplicate
> Flaky: LoginHandlerInterceptorJUnitTest.testHandlerInterceptorThreadSafety
> intermittent failures
>
>
> Key: GEODE-5663
> URL: https://issues.apache.org/jira/browse/GEODE-5663
> Project: Geode
> Issue Type: Test
> Components: ci
>Affects Versions: 1.7.0
>Reporter: Kenneth Howe
>Priority: Major
> Labels: flaky, swat
>
> This test has failed in the CI Build pipeline 3 times in the last ~6 days.
> {code:java}
> > Task :geode-web:test
> org.apache.geode.management.internal.web.controllers.support.LoginHandlerInterceptorJUnitTest
> > testHandlerInterceptorThreadSafety FAILED
> junit.framework.AssertionFailedError: expected:<0> but was:<3>
> not all expectations were satisfied
> expectations:
> ! expected once, never invoked:
> testHandlerInterceptorThreadSafety.HttpServletRequest.1.getParameterNames();
> returns
>
> ! expected once, never invoked:
> testHandlerInterceptorThreadSafety.HttpServletRequest.1.getHeader("security-username");
> returns "admin"
> ! expected once, never invoked:
> testHandlerInterceptorThreadSafety.HttpServletRequest.1.getHeader("security-password");
> returns "password"
> ! expected once, never invoked:
> testHandlerInterceptorThreadSafety.HttpServletRequest.1.getParameter("vf.gf.env.STAGE");
> returns "test"
> ! expected once, never invoked:
> testHandlerInterceptorThreadSafety.HttpServletRequest.1.getParameter("vf.gf.env.GEODE_HOME");
> returns "/path/to/gemfire/700"
> expected once, already invoked 1 time: securityService.login(not null);
> returns a default value
> ! expected once, never invoked: securityService.logout()
> expected once, already invoked 1 time:
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameterNames();
> returns
>
> expected once, already invoked 1 time:
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getHeader("security-username");
> returns "admin"
> expected once, already invoked 1 time:
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getHeader("security-password");
> returns "password"
> expected once, already invoked 1 time:
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameter("vf.gf.env.HOST");
> returns "localhost"
> expected once, already invoked 1 time:
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameter("vf.gf.env.GEODE_HOME");
> returns "/path/to/gemfire/75"
> ! expected once, never invoked: securityService.login(not null);
> returns a default value
> ! expected once, never invoked: securityService.logout()
> what happened before this:
>
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameterNames()
>
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameter("vf.gf.env.HOST")
>
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameter("vf.gf.env.GEODE_HOME")
>
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getHeader("security-username")
>
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getHeader("security-password")
> securityService.login(<{security-username=admin,
> security-password=password}>)
> at
> org.jmock.api.ExpectationError.notAllSatisfied(ExpectationError.java:27)
> at org.jmock.Mockery.assertIsSatisfied(Mockery.java:215)
> at
> org.apache.geode.management.internal.web.controllers.support.LoginHandlerInterceptorJUnitTest.tearDown(LoginHandlerInterceptorJUnitTest.java:70)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5649) getAll() does not trigger client metadata refresh when primary bucket not known
[ https://issues.apache.org/jira/browse/GEODE-5649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-5649: -- Labels: pull-request-available (was: ) > getAll() does not trigger client metadata refresh when primary bucket not > known > --- > > Key: GEODE-5649 > URL: https://issues.apache.org/jira/browse/GEODE-5649 > Project: Geode > Issue Type: Bug > Components: client/server >Reporter: Bruce Schuchardt >Priority: Major > Labels: pull-request-available > > We observed in a test system that getAll() would suddenly become slow in one > client cache while remaining fast in others. Adding some debug logging > showed that the client stopped doing single-hop operations and never > recovered the ability to do them again. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5663) Flaky: LoginHandlerInterceptorJUnitTest.testHandlerInterceptorThreadSafety intermittent failures
[
https://issues.apache.org/jira/browse/GEODE-5663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe updated GEODE-5663:
Affects Version/s: 1.7.0
Labels: flaky swat (was: )
> Flaky: LoginHandlerInterceptorJUnitTest.testHandlerInterceptorThreadSafety
> intermittent failures
>
>
> Key: GEODE-5663
> URL: https://issues.apache.org/jira/browse/GEODE-5663
> Project: Geode
> Issue Type: Test
> Components: ci
>Affects Versions: 1.7.0
>Reporter: Kenneth Howe
>Priority: Major
> Labels: flaky, swat
>
> This test has failed in the CI Build pipeline 3 times in the last ~6 days.
> {code:java}
> > Task :geode-web:test
> org.apache.geode.management.internal.web.controllers.support.LoginHandlerInterceptorJUnitTest
> > testHandlerInterceptorThreadSafety FAILED
> junit.framework.AssertionFailedError: expected:<0> but was:<3>
> not all expectations were satisfied
> expectations:
> ! expected once, never invoked:
> testHandlerInterceptorThreadSafety.HttpServletRequest.1.getParameterNames();
> returns
>
> ! expected once, never invoked:
> testHandlerInterceptorThreadSafety.HttpServletRequest.1.getHeader("security-username");
> returns "admin"
> ! expected once, never invoked:
> testHandlerInterceptorThreadSafety.HttpServletRequest.1.getHeader("security-password");
> returns "password"
> ! expected once, never invoked:
> testHandlerInterceptorThreadSafety.HttpServletRequest.1.getParameter("vf.gf.env.STAGE");
> returns "test"
> ! expected once, never invoked:
> testHandlerInterceptorThreadSafety.HttpServletRequest.1.getParameter("vf.gf.env.GEODE_HOME");
> returns "/path/to/gemfire/700"
> expected once, already invoked 1 time: securityService.login(not null);
> returns a default value
> ! expected once, never invoked: securityService.logout()
> expected once, already invoked 1 time:
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameterNames();
> returns
>
> expected once, already invoked 1 time:
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getHeader("security-username");
> returns "admin"
> expected once, already invoked 1 time:
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getHeader("security-password");
> returns "password"
> expected once, already invoked 1 time:
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameter("vf.gf.env.HOST");
> returns "localhost"
> expected once, already invoked 1 time:
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameter("vf.gf.env.GEODE_HOME");
> returns "/path/to/gemfire/75"
> ! expected once, never invoked: securityService.login(not null);
> returns a default value
> ! expected once, never invoked: securityService.logout()
> what happened before this:
>
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameterNames()
>
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameter("vf.gf.env.HOST")
>
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameter("vf.gf.env.GEODE_HOME")
>
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getHeader("security-username")
>
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getHeader("security-password")
> securityService.login(<{security-username=admin,
> security-password=password}>)
> at
> org.jmock.api.ExpectationError.notAllSatisfied(ExpectationError.java:27)
> at org.jmock.Mockery.assertIsSatisfied(Mockery.java:215)
> at
> org.apache.geode.management.internal.web.controllers.support.LoginHandlerInterceptorJUnitTest.tearDown(LoginHandlerInterceptorJUnitTest.java:70)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5663) Flaky: LoginHandlerInterceptorJUnitTest.testHandlerInterceptorThreadSafety intermittent failures
[
https://issues.apache.org/jira/browse/GEODE-5663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe updated GEODE-5663:
Summary: Flaky:
LoginHandlerInterceptorJUnitTest.testHandlerInterceptorThreadSafety
intermittent failures (was: Flaky: LoginHandlerInterceptorJUnitTest >
testHandlerInterceptorThreadSafety)
> Flaky: LoginHandlerInterceptorJUnitTest.testHandlerInterceptorThreadSafety
> intermittent failures
>
>
> Key: GEODE-5663
> URL: https://issues.apache.org/jira/browse/GEODE-5663
> Project: Geode
> Issue Type: Test
> Components: ci
>Reporter: Kenneth Howe
>Priority: Major
>
> This test has failed in the CI Build pipeline 3 times in the last ~6 days.
> {code:java}
> > Task :geode-web:test
> org.apache.geode.management.internal.web.controllers.support.LoginHandlerInterceptorJUnitTest
> > testHandlerInterceptorThreadSafety FAILED
> junit.framework.AssertionFailedError: expected:<0> but was:<3>
> not all expectations were satisfied
> expectations:
> ! expected once, never invoked:
> testHandlerInterceptorThreadSafety.HttpServletRequest.1.getParameterNames();
> returns
>
> ! expected once, never invoked:
> testHandlerInterceptorThreadSafety.HttpServletRequest.1.getHeader("security-username");
> returns "admin"
> ! expected once, never invoked:
> testHandlerInterceptorThreadSafety.HttpServletRequest.1.getHeader("security-password");
> returns "password"
> ! expected once, never invoked:
> testHandlerInterceptorThreadSafety.HttpServletRequest.1.getParameter("vf.gf.env.STAGE");
> returns "test"
> ! expected once, never invoked:
> testHandlerInterceptorThreadSafety.HttpServletRequest.1.getParameter("vf.gf.env.GEODE_HOME");
> returns "/path/to/gemfire/700"
> expected once, already invoked 1 time: securityService.login(not null);
> returns a default value
> ! expected once, never invoked: securityService.logout()
> expected once, already invoked 1 time:
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameterNames();
> returns
>
> expected once, already invoked 1 time:
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getHeader("security-username");
> returns "admin"
> expected once, already invoked 1 time:
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getHeader("security-password");
> returns "password"
> expected once, already invoked 1 time:
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameter("vf.gf.env.HOST");
> returns "localhost"
> expected once, already invoked 1 time:
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameter("vf.gf.env.GEODE_HOME");
> returns "/path/to/gemfire/75"
> ! expected once, never invoked: securityService.login(not null);
> returns a default value
> ! expected once, never invoked: securityService.logout()
> what happened before this:
>
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameterNames()
>
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameter("vf.gf.env.HOST")
>
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameter("vf.gf.env.GEODE_HOME")
>
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getHeader("security-username")
>
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getHeader("security-password")
> securityService.login(<{security-username=admin,
> security-password=password}>)
> at
> org.jmock.api.ExpectationError.notAllSatisfied(ExpectationError.java:27)
> at org.jmock.Mockery.assertIsSatisfied(Mockery.java:215)
> at
> org.apache.geode.management.internal.web.controllers.support.LoginHandlerInterceptorJUnitTest.tearDown(LoginHandlerInterceptorJUnitTest.java:70)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-5663) Flaky: LoginHandlerInterceptorJUnitTest > testHandlerInterceptorThreadSafety
Kenneth Howe created GEODE-5663:
---
Summary: Flaky: LoginHandlerInterceptorJUnitTest >
testHandlerInterceptorThreadSafety
Key: GEODE-5663
URL: https://issues.apache.org/jira/browse/GEODE-5663
Project: Geode
Issue Type: Test
Components: ci
Reporter: Kenneth Howe
This test has failed in the CI Build pipeline 3 times in the last ~6 days.
{code:java}
> Task :geode-web:test
org.apache.geode.management.internal.web.controllers.support.LoginHandlerInterceptorJUnitTest
> testHandlerInterceptorThreadSafety FAILED
junit.framework.AssertionFailedError: expected:<0> but was:<3>
not all expectations were satisfied
expectations:
! expected once, never invoked:
testHandlerInterceptorThreadSafety.HttpServletRequest.1.getParameterNames();
returns
! expected once, never invoked:
testHandlerInterceptorThreadSafety.HttpServletRequest.1.getHeader("security-username");
returns "admin"
! expected once, never invoked:
testHandlerInterceptorThreadSafety.HttpServletRequest.1.getHeader("security-password");
returns "password"
! expected once, never invoked:
testHandlerInterceptorThreadSafety.HttpServletRequest.1.getParameter("vf.gf.env.STAGE");
returns "test"
! expected once, never invoked:
testHandlerInterceptorThreadSafety.HttpServletRequest.1.getParameter("vf.gf.env.GEODE_HOME");
returns "/path/to/gemfire/700"
expected once, already invoked 1 time: securityService.login(not null);
returns a default value
! expected once, never invoked: securityService.logout()
expected once, already invoked 1 time:
testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameterNames();
returns
expected once, already invoked 1 time:
testHandlerInterceptorThreadSafety.HttpServletRequest.2.getHeader("security-username");
returns "admin"
expected once, already invoked 1 time:
testHandlerInterceptorThreadSafety.HttpServletRequest.2.getHeader("security-password");
returns "password"
expected once, already invoked 1 time:
testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameter("vf.gf.env.HOST");
returns "localhost"
expected once, already invoked 1 time:
testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameter("vf.gf.env.GEODE_HOME");
returns "/path/to/gemfire/75"
! expected once, never invoked: securityService.login(not null); returns
a default value
! expected once, never invoked: securityService.logout()
what happened before this:
testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameterNames()
testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameter("vf.gf.env.HOST")
testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameter("vf.gf.env.GEODE_HOME")
testHandlerInterceptorThreadSafety.HttpServletRequest.2.getHeader("security-username")
testHandlerInterceptorThreadSafety.HttpServletRequest.2.getHeader("security-password")
securityService.login(<{security-username=admin,
security-password=password}>)
at
org.jmock.api.ExpectationError.notAllSatisfied(ExpectationError.java:27)
at org.jmock.Mockery.assertIsSatisfied(Mockery.java:215)
at
org.apache.geode.management.internal.web.controllers.support.LoginHandlerInterceptorJUnitTest.tearDown(LoginHandlerInterceptorJUnitTest.java:70)
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5238) CI failure: SerialWANPropagationsFeatureDUnitTest.testSerialPropagationWithFilter fails with Possible loss of quorum suspect string
[
https://issues.apache.org/jira/browse/GEODE-5238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith resolved GEODE-5238.
--
Resolution: Fixed
We reduced the parallelism of DistributedTest in 1d8c322574f52ca35. That was
causing some of these loss of quorum issues.
> CI failure:
> SerialWANPropagationsFeatureDUnitTest.testSerialPropagationWithFilter fails
> with Possible loss of quorum suspect string
> ---
>
> Key: GEODE-5238
> URL: https://issues.apache.org/jira/browse/GEODE-5238
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Barry Oglesby
>Priority: Major
> Labels: swat
> Attachments:
> TEST-org.apache.geode.internal.cache.wan.serial.SerialWANPropagationsFeatureDUnitTest.xml
>
>
> The members startup:
> {noformat}
> [vm1] [info 2018/05/19 02:18:54.055 UTC
> tid=27] Starting DistributionManager 172.17.0.5(154:locator):32771.
> (took 49 ms)
> [vm2] [info 2018/05/19 02:18:54.479 UTC
> tid=27] Starting DistributionManager 172.17.0.5(159):32772. (took 336 ms)
> [vm3] [info 2018/05/19 02:18:55.477 UTC
> tid=27] Starting DistributionManager 172.17.0.5(168):32773. (took 401 ms)
> [vm3] [info 2018/05/19 02:18:55.478 UTC
> tid=27] Initial (distribution manager) view =
> View[172.17.0.5(154:locator):32771|2] members:
> [172.17.0.5(154:locator):32771, 172.17.0.5(159):32772\{lead},
> 172.17.0.5(168):32773]
> {noformat}
> So the members are:
> {noformat}
> vm1 - locator, coordinator (weight=3)
> vm2 - lead member (weight=15)
> vm3 - member (weight=10)``
> vm1 - locator, coordinator (weight=3)
> vm2 - lead member (weight=15)
> vm3 - member (weight=10)
> {noformat}
> The WANTestBase cleanupVM method shuts down the members simultaneously.
> Log messages show vm1 (locator) shutting down first (and the other two
> members realize it):
> {noformat}
> [vm1] [info 2018/05/19 02:19:10.400 UTC
> tid=27] Shutting down DistributionManager
> 172.17.0.5(154:locator):32771.
> [vm1] [info 2018/05/19 02:19:10.513 UTC
> tid=27] Now closing distribution for 172.17.0.5(154:locator):32771
> [vm1] [info 2018/05/19 02:19:10.513 UTC
> tid=27] Stopping membership services
> [vm1] [info 2018/05/19 02:19:10.513 UTC
> tid=27] Now closing distribution for 172.17.0.5(154:locator):32771
> [vm2] [info 2018/05/19 02:19:10.420 UTC Processor 1> tid=310] Member at 172.17.0.5(154:locator):32771
> gracefully left the distributed cache: shutdown message received
> [vm3] [info 2018/05/19 02:19:10.622 UTC Processor 1> tid=310] Member at 172.17.0.5(154:locator):32771
> gracefully left the distributed cache: shutdown message received
> {noformat}
> Then vm2 becomes coordinator:
> {noformat}
> [vm2] [info 2018/05/19 02:19:10.402 UTC Processor 1> tid=310] This member is becoming the membership coordinator with
> address 172.17.0.5(159):32772
> {noformat}
> Then vm2 shuts down its DistributionManager:
> {noformat}
> [vm2] [info 2018/05/19 02:19:11.239 UTC
> tid=27] Shutting down DistributionManager 172.17.0.5(159):32772.
> [vm2] [info 2018/05/19 02:19:11.352 UTC
> tid=27] Now closing distribution for 172.17.0.5(159):32772
> [vm2] [info 2018/05/19 02:19:11.352 UTC
> tid=27] Stopping membership services
> [vm2] [info 2018/05/19 02:19:11.377 UTC
> tid=27] DistributionManager stopped in 138ms.
> [vm2] [info 2018/05/19 02:19:11.377 UTC
> tid=27] Marking DistributionManager 172.17.0.5(159):32772 as closed.
> {noformat}
> Then vm3 does some suspect checking and logs the quorum loss warning:
> {noformat}
> [vm3] [info 2018/05/19 02:19:11.414 UTC 172.17.0.5(159):32772 shared unordered uid=14 port=35502> tid=296]
> Performing final check for suspect member 172.17.0.5(159):32772
> reason=member unexpectedly shut down shared, unordered connection
> [vm3] [info 2018/05/19 02:19:11.434 UTC 172.17.0.5(159):32772 shared unordered uid=14 port=35502> tid=296] This
> member is becoming the membership coordinator with address
> 172.17.0.5(168):32773
> [vm3] [info 2018/05/19 02:19:11.436 UTC
> tid=360] View Creator thread is starting
> [vm3] [info 2018/05/19 02:19:11.436 UTC
> tid=360] 172.17.0.5(159):32772 had a weight of 15
> [vm3] [warn 2018/05/19 02:19:11.436 UTC
> tid=360] total weight lost in this view change is 15 of 25. Quorum has been
> lost!
> [vm3] [fatal 2018/05/19 02:19:11.438 UTC
> tid=360] Possible loss of quorum due to the loss of 1 cache processes:
> [172.17.0.5(159):32772]
> {noformat}
> Then vm3 shuts down its DistributionManager:
> {noformat}
> [vm3] [info 2018/05/19 02:19:11.448 UTC
> tid=27] Shutting down DistributionManager 172.17.0.5(168):32773.
> [vm3] [info 2018/05/19 02:19:11.588 UTC
> tid=27] Now closing distribution for 172.17.0.5(168):32773
> [vm3] [info
[jira] [Updated] (GEODE-5238) CI failure: SerialWANPropagationsFeatureDUnitTest.testSerialPropagationWithFilter fails with Possible loss of quorum suspect string
[
https://issues.apache.org/jira/browse/GEODE-5238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith updated GEODE-5238:
-
Labels: swat (was: )
> CI failure:
> SerialWANPropagationsFeatureDUnitTest.testSerialPropagationWithFilter fails
> with Possible loss of quorum suspect string
> ---
>
> Key: GEODE-5238
> URL: https://issues.apache.org/jira/browse/GEODE-5238
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Barry Oglesby
>Priority: Major
> Labels: swat
> Attachments:
> TEST-org.apache.geode.internal.cache.wan.serial.SerialWANPropagationsFeatureDUnitTest.xml
>
>
> The members startup:
> {noformat}
> [vm1] [info 2018/05/19 02:18:54.055 UTC
> tid=27] Starting DistributionManager 172.17.0.5(154:locator):32771.
> (took 49 ms)
> [vm2] [info 2018/05/19 02:18:54.479 UTC
> tid=27] Starting DistributionManager 172.17.0.5(159):32772. (took 336 ms)
> [vm3] [info 2018/05/19 02:18:55.477 UTC
> tid=27] Starting DistributionManager 172.17.0.5(168):32773. (took 401 ms)
> [vm3] [info 2018/05/19 02:18:55.478 UTC
> tid=27] Initial (distribution manager) view =
> View[172.17.0.5(154:locator):32771|2] members:
> [172.17.0.5(154:locator):32771, 172.17.0.5(159):32772\{lead},
> 172.17.0.5(168):32773]
> {noformat}
> So the members are:
> {noformat}
> vm1 - locator, coordinator (weight=3)
> vm2 - lead member (weight=15)
> vm3 - member (weight=10)``
> vm1 - locator, coordinator (weight=3)
> vm2 - lead member (weight=15)
> vm3 - member (weight=10)
> {noformat}
> The WANTestBase cleanupVM method shuts down the members simultaneously.
> Log messages show vm1 (locator) shutting down first (and the other two
> members realize it):
> {noformat}
> [vm1] [info 2018/05/19 02:19:10.400 UTC
> tid=27] Shutting down DistributionManager
> 172.17.0.5(154:locator):32771.
> [vm1] [info 2018/05/19 02:19:10.513 UTC
> tid=27] Now closing distribution for 172.17.0.5(154:locator):32771
> [vm1] [info 2018/05/19 02:19:10.513 UTC
> tid=27] Stopping membership services
> [vm1] [info 2018/05/19 02:19:10.513 UTC
> tid=27] Now closing distribution for 172.17.0.5(154:locator):32771
> [vm2] [info 2018/05/19 02:19:10.420 UTC Processor 1> tid=310] Member at 172.17.0.5(154:locator):32771
> gracefully left the distributed cache: shutdown message received
> [vm3] [info 2018/05/19 02:19:10.622 UTC Processor 1> tid=310] Member at 172.17.0.5(154:locator):32771
> gracefully left the distributed cache: shutdown message received
> {noformat}
> Then vm2 becomes coordinator:
> {noformat}
> [vm2] [info 2018/05/19 02:19:10.402 UTC Processor 1> tid=310] This member is becoming the membership coordinator with
> address 172.17.0.5(159):32772
> {noformat}
> Then vm2 shuts down its DistributionManager:
> {noformat}
> [vm2] [info 2018/05/19 02:19:11.239 UTC
> tid=27] Shutting down DistributionManager 172.17.0.5(159):32772.
> [vm2] [info 2018/05/19 02:19:11.352 UTC
> tid=27] Now closing distribution for 172.17.0.5(159):32772
> [vm2] [info 2018/05/19 02:19:11.352 UTC
> tid=27] Stopping membership services
> [vm2] [info 2018/05/19 02:19:11.377 UTC
> tid=27] DistributionManager stopped in 138ms.
> [vm2] [info 2018/05/19 02:19:11.377 UTC
> tid=27] Marking DistributionManager 172.17.0.5(159):32772 as closed.
> {noformat}
> Then vm3 does some suspect checking and logs the quorum loss warning:
> {noformat}
> [vm3] [info 2018/05/19 02:19:11.414 UTC 172.17.0.5(159):32772 shared unordered uid=14 port=35502> tid=296]
> Performing final check for suspect member 172.17.0.5(159):32772
> reason=member unexpectedly shut down shared, unordered connection
> [vm3] [info 2018/05/19 02:19:11.434 UTC 172.17.0.5(159):32772 shared unordered uid=14 port=35502> tid=296] This
> member is becoming the membership coordinator with address
> 172.17.0.5(168):32773
> [vm3] [info 2018/05/19 02:19:11.436 UTC
> tid=360] View Creator thread is starting
> [vm3] [info 2018/05/19 02:19:11.436 UTC
> tid=360] 172.17.0.5(159):32772 had a weight of 15
> [vm3] [warn 2018/05/19 02:19:11.436 UTC
> tid=360] total weight lost in this view change is 15 of 25. Quorum has been
> lost!
> [vm3] [fatal 2018/05/19 02:19:11.438 UTC
> tid=360] Possible loss of quorum due to the loss of 1 cache processes:
> [172.17.0.5(159):32772]
> {noformat}
> Then vm3 shuts down its DistributionManager:
> {noformat}
> [vm3] [info 2018/05/19 02:19:11.448 UTC
> tid=27] Shutting down DistributionManager 172.17.0.5(168):32773.
> [vm3] [info 2018/05/19 02:19:11.588 UTC
> tid=27] Now closing distribution for 172.17.0.5(168):32773
> [vm3] [info 2018/05/19 02:19:11.588 UTC
> tid=27] Stopping membership services
> [vm3] [info 2018/05/19 02:19:11.617 UTC
> tid=27]
[jira] [Updated] (GEODE-5238) CI failure: SerialWANPropagationsFeatureDUnitTest.testSerialPropagationWithFilter fails with Possible loss of quorum suspect string
[
https://issues.apache.org/jira/browse/GEODE-5238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith updated GEODE-5238:
-
Component/s: (was: swat)
> CI failure:
> SerialWANPropagationsFeatureDUnitTest.testSerialPropagationWithFilter fails
> with Possible loss of quorum suspect string
> ---
>
> Key: GEODE-5238
> URL: https://issues.apache.org/jira/browse/GEODE-5238
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Barry Oglesby
>Priority: Major
> Labels: swat
> Attachments:
> TEST-org.apache.geode.internal.cache.wan.serial.SerialWANPropagationsFeatureDUnitTest.xml
>
>
> The members startup:
> {noformat}
> [vm1] [info 2018/05/19 02:18:54.055 UTC
> tid=27] Starting DistributionManager 172.17.0.5(154:locator):32771.
> (took 49 ms)
> [vm2] [info 2018/05/19 02:18:54.479 UTC
> tid=27] Starting DistributionManager 172.17.0.5(159):32772. (took 336 ms)
> [vm3] [info 2018/05/19 02:18:55.477 UTC
> tid=27] Starting DistributionManager 172.17.0.5(168):32773. (took 401 ms)
> [vm3] [info 2018/05/19 02:18:55.478 UTC
> tid=27] Initial (distribution manager) view =
> View[172.17.0.5(154:locator):32771|2] members:
> [172.17.0.5(154:locator):32771, 172.17.0.5(159):32772\{lead},
> 172.17.0.5(168):32773]
> {noformat}
> So the members are:
> {noformat}
> vm1 - locator, coordinator (weight=3)
> vm2 - lead member (weight=15)
> vm3 - member (weight=10)``
> vm1 - locator, coordinator (weight=3)
> vm2 - lead member (weight=15)
> vm3 - member (weight=10)
> {noformat}
> The WANTestBase cleanupVM method shuts down the members simultaneously.
> Log messages show vm1 (locator) shutting down first (and the other two
> members realize it):
> {noformat}
> [vm1] [info 2018/05/19 02:19:10.400 UTC
> tid=27] Shutting down DistributionManager
> 172.17.0.5(154:locator):32771.
> [vm1] [info 2018/05/19 02:19:10.513 UTC
> tid=27] Now closing distribution for 172.17.0.5(154:locator):32771
> [vm1] [info 2018/05/19 02:19:10.513 UTC
> tid=27] Stopping membership services
> [vm1] [info 2018/05/19 02:19:10.513 UTC
> tid=27] Now closing distribution for 172.17.0.5(154:locator):32771
> [vm2] [info 2018/05/19 02:19:10.420 UTC Processor 1> tid=310] Member at 172.17.0.5(154:locator):32771
> gracefully left the distributed cache: shutdown message received
> [vm3] [info 2018/05/19 02:19:10.622 UTC Processor 1> tid=310] Member at 172.17.0.5(154:locator):32771
> gracefully left the distributed cache: shutdown message received
> {noformat}
> Then vm2 becomes coordinator:
> {noformat}
> [vm2] [info 2018/05/19 02:19:10.402 UTC Processor 1> tid=310] This member is becoming the membership coordinator with
> address 172.17.0.5(159):32772
> {noformat}
> Then vm2 shuts down its DistributionManager:
> {noformat}
> [vm2] [info 2018/05/19 02:19:11.239 UTC
> tid=27] Shutting down DistributionManager 172.17.0.5(159):32772.
> [vm2] [info 2018/05/19 02:19:11.352 UTC
> tid=27] Now closing distribution for 172.17.0.5(159):32772
> [vm2] [info 2018/05/19 02:19:11.352 UTC
> tid=27] Stopping membership services
> [vm2] [info 2018/05/19 02:19:11.377 UTC
> tid=27] DistributionManager stopped in 138ms.
> [vm2] [info 2018/05/19 02:19:11.377 UTC
> tid=27] Marking DistributionManager 172.17.0.5(159):32772 as closed.
> {noformat}
> Then vm3 does some suspect checking and logs the quorum loss warning:
> {noformat}
> [vm3] [info 2018/05/19 02:19:11.414 UTC 172.17.0.5(159):32772 shared unordered uid=14 port=35502> tid=296]
> Performing final check for suspect member 172.17.0.5(159):32772
> reason=member unexpectedly shut down shared, unordered connection
> [vm3] [info 2018/05/19 02:19:11.434 UTC 172.17.0.5(159):32772 shared unordered uid=14 port=35502> tid=296] This
> member is becoming the membership coordinator with address
> 172.17.0.5(168):32773
> [vm3] [info 2018/05/19 02:19:11.436 UTC
> tid=360] View Creator thread is starting
> [vm3] [info 2018/05/19 02:19:11.436 UTC
> tid=360] 172.17.0.5(159):32772 had a weight of 15
> [vm3] [warn 2018/05/19 02:19:11.436 UTC
> tid=360] total weight lost in this view change is 15 of 25. Quorum has been
> lost!
> [vm3] [fatal 2018/05/19 02:19:11.438 UTC
> tid=360] Possible loss of quorum due to the loss of 1 cache processes:
> [172.17.0.5(159):32772]
> {noformat}
> Then vm3 shuts down its DistributionManager:
> {noformat}
> [vm3] [info 2018/05/19 02:19:11.448 UTC
> tid=27] Shutting down DistributionManager 172.17.0.5(168):32773.
> [vm3] [info 2018/05/19 02:19:11.588 UTC
> tid=27] Now closing distribution for 172.17.0.5(168):32773
> [vm3] [info 2018/05/19 02:19:11.588 UTC
> tid=27] Stopping membership services
> [vm3] [info 2018/05/19 02:19:11.617 UTC
> tid=27]
[jira] [Updated] (GEODE-5595) CI: DeltaPropagationDUnit.testBug40165ClientReconnects - NoSubscriptionServersAvailableException
[
https://issues.apache.org/jira/browse/GEODE-5595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith updated GEODE-5595:
-
Component/s: (was: swat)
> CI: DeltaPropagationDUnit.testBug40165ClientReconnects -
> NoSubscriptionServersAvailableException
>
>
> Key: GEODE-5595
> URL: https://issues.apache.org/jira/browse/GEODE-5595
> Project: Geode
> Issue Type: Bug
>Reporter: Kenneth Howe
>Priority: Major
> Labels: swat
>
> {code:java}
> org.apache.geode.internal.cache.DeltaPropagationDUnitTest >
> testBug40165ClientReconnects FAILED
>
> org.apache.geode.cache.NoSubscriptionServersAvailableException:
> org.apache.geode.cache.NoSubscriptionServersAvailableException: Could not
> initialize a primary queue on startup. No queue servers available.
>
> at
> org.apache.geode.cache.client.internal.QueueManagerImpl.getAllConnections(QueueManagerImpl.java:187)
>
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.executeOnQueuesAndReturnPrimaryResult(OpExecutorImpl.java:548)
>
> at
> org.apache.geode.cache.client.internal.PoolImpl.executeOnQueuesAndReturnPrimaryResult(PoolImpl.java:855)
>
> at
> org.apache.geode.cache.client.internal.RegisterInterestOp.execute(RegisterInterestOp.java:58)
>
> at
> org.apache.geode.cache.client.internal.ServerRegionProxy.registerInterest(ServerRegionProxy.java:355)
>
> at
> org.apache.geode.internal.cache.LocalRegion.processSingleInterest(LocalRegion.java:3797)
>
> at
> org.apache.geode.internal.cache.LocalRegion.registerInterest(LocalRegion.java:3888)
>
> at
> org.apache.geode.internal.cache.LocalRegion.registerInterest(LocalRegion.java:3686)
>
> at
> org.apache.geode.internal.cache.LocalRegion.registerInterest(LocalRegion.java:3681)
>
> at
> org.apache.geode.internal.cache.LocalRegion.registerInterest(LocalRegion.java:3676)
>
> at
> org.apache.geode.internal.cache.DeltaPropagationDUnitTest.createDurableCacheClient(DeltaPropagationDUnitTest.java:1305)
>
> at
> org.apache.geode.internal.cache.DeltaPropagationDUnitTest.testBug40165ClientReconnects(DeltaPropagationDUnitTest.java:647)
>
>
> Caused by:
>
> org.apache.geode.cache.NoSubscriptionServersAvailableException: Could
> not initialize a primary queue on startup. No queue servers available.
>
> at
> org.apache.geode.cache.client.internal.QueueManagerImpl.initializeConnections(QueueManagerImpl.java:585)
>
> at
> org.apache.geode.cache.client.internal.QueueManagerImpl.start(QueueManagerImpl.java:296)
>
> at
> org.apache.geode.cache.client.internal.PoolImpl.start(PoolImpl.java:352)
>
> at
> org.apache.geode.cache.client.internal.PoolImpl.finishCreate(PoolImpl.java:176)
>
> at
> org.apache.geode.cache.client.internal.PoolImpl.create(PoolImpl.java:162)
>
> at
> org.apache.geode.internal.cache.PoolFactoryImpl.create(PoolFactoryImpl.java:349)
>
> at
> org.apache.geode.internal.cache.DeltaPropagationDUnitTest.createDurableCacheClient(DeltaPropagationDUnitTest.java:1295)
>
> ... 1 more
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5595) CI: DeltaPropagationDUnit.testBug40165ClientReconnects - NoSubscriptionServersAvailableException
[
https://issues.apache.org/jira/browse/GEODE-5595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith updated GEODE-5595:
-
Labels: swat (was: )
> CI: DeltaPropagationDUnit.testBug40165ClientReconnects -
> NoSubscriptionServersAvailableException
>
>
> Key: GEODE-5595
> URL: https://issues.apache.org/jira/browse/GEODE-5595
> Project: Geode
> Issue Type: Bug
>Reporter: Kenneth Howe
>Priority: Major
> Labels: swat
>
> {code:java}
> org.apache.geode.internal.cache.DeltaPropagationDUnitTest >
> testBug40165ClientReconnects FAILED
>
> org.apache.geode.cache.NoSubscriptionServersAvailableException:
> org.apache.geode.cache.NoSubscriptionServersAvailableException: Could not
> initialize a primary queue on startup. No queue servers available.
>
> at
> org.apache.geode.cache.client.internal.QueueManagerImpl.getAllConnections(QueueManagerImpl.java:187)
>
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.executeOnQueuesAndReturnPrimaryResult(OpExecutorImpl.java:548)
>
> at
> org.apache.geode.cache.client.internal.PoolImpl.executeOnQueuesAndReturnPrimaryResult(PoolImpl.java:855)
>
> at
> org.apache.geode.cache.client.internal.RegisterInterestOp.execute(RegisterInterestOp.java:58)
>
> at
> org.apache.geode.cache.client.internal.ServerRegionProxy.registerInterest(ServerRegionProxy.java:355)
>
> at
> org.apache.geode.internal.cache.LocalRegion.processSingleInterest(LocalRegion.java:3797)
>
> at
> org.apache.geode.internal.cache.LocalRegion.registerInterest(LocalRegion.java:3888)
>
> at
> org.apache.geode.internal.cache.LocalRegion.registerInterest(LocalRegion.java:3686)
>
> at
> org.apache.geode.internal.cache.LocalRegion.registerInterest(LocalRegion.java:3681)
>
> at
> org.apache.geode.internal.cache.LocalRegion.registerInterest(LocalRegion.java:3676)
>
> at
> org.apache.geode.internal.cache.DeltaPropagationDUnitTest.createDurableCacheClient(DeltaPropagationDUnitTest.java:1305)
>
> at
> org.apache.geode.internal.cache.DeltaPropagationDUnitTest.testBug40165ClientReconnects(DeltaPropagationDUnitTest.java:647)
>
>
> Caused by:
>
> org.apache.geode.cache.NoSubscriptionServersAvailableException: Could
> not initialize a primary queue on startup. No queue servers available.
>
> at
> org.apache.geode.cache.client.internal.QueueManagerImpl.initializeConnections(QueueManagerImpl.java:585)
>
> at
> org.apache.geode.cache.client.internal.QueueManagerImpl.start(QueueManagerImpl.java:296)
>
> at
> org.apache.geode.cache.client.internal.PoolImpl.start(PoolImpl.java:352)
>
> at
> org.apache.geode.cache.client.internal.PoolImpl.finishCreate(PoolImpl.java:176)
>
> at
> org.apache.geode.cache.client.internal.PoolImpl.create(PoolImpl.java:162)
>
> at
> org.apache.geode.internal.cache.PoolFactoryImpl.create(PoolFactoryImpl.java:349)
>
> at
> org.apache.geode.internal.cache.DeltaPropagationDUnitTest.createDurableCacheClient(DeltaPropagationDUnitTest.java:1295)
>
> ... 1 more
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5595) CI: DeltaPropagationDUnit.testBug40165ClientReconnects - NoSubscriptionServersAvailableException
[
https://issues.apache.org/jira/browse/GEODE-5595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith updated GEODE-5595:
-
Component/s: (was: ci)
> CI: DeltaPropagationDUnit.testBug40165ClientReconnects -
> NoSubscriptionServersAvailableException
>
>
> Key: GEODE-5595
> URL: https://issues.apache.org/jira/browse/GEODE-5595
> Project: Geode
> Issue Type: Bug
> Components: swat
>Reporter: Kenneth Howe
>Priority: Major
>
> {code:java}
> org.apache.geode.internal.cache.DeltaPropagationDUnitTest >
> testBug40165ClientReconnects FAILED
>
> org.apache.geode.cache.NoSubscriptionServersAvailableException:
> org.apache.geode.cache.NoSubscriptionServersAvailableException: Could not
> initialize a primary queue on startup. No queue servers available.
>
> at
> org.apache.geode.cache.client.internal.QueueManagerImpl.getAllConnections(QueueManagerImpl.java:187)
>
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.executeOnQueuesAndReturnPrimaryResult(OpExecutorImpl.java:548)
>
> at
> org.apache.geode.cache.client.internal.PoolImpl.executeOnQueuesAndReturnPrimaryResult(PoolImpl.java:855)
>
> at
> org.apache.geode.cache.client.internal.RegisterInterestOp.execute(RegisterInterestOp.java:58)
>
> at
> org.apache.geode.cache.client.internal.ServerRegionProxy.registerInterest(ServerRegionProxy.java:355)
>
> at
> org.apache.geode.internal.cache.LocalRegion.processSingleInterest(LocalRegion.java:3797)
>
> at
> org.apache.geode.internal.cache.LocalRegion.registerInterest(LocalRegion.java:3888)
>
> at
> org.apache.geode.internal.cache.LocalRegion.registerInterest(LocalRegion.java:3686)
>
> at
> org.apache.geode.internal.cache.LocalRegion.registerInterest(LocalRegion.java:3681)
>
> at
> org.apache.geode.internal.cache.LocalRegion.registerInterest(LocalRegion.java:3676)
>
> at
> org.apache.geode.internal.cache.DeltaPropagationDUnitTest.createDurableCacheClient(DeltaPropagationDUnitTest.java:1305)
>
> at
> org.apache.geode.internal.cache.DeltaPropagationDUnitTest.testBug40165ClientReconnects(DeltaPropagationDUnitTest.java:647)
>
>
> Caused by:
>
> org.apache.geode.cache.NoSubscriptionServersAvailableException: Could
> not initialize a primary queue on startup. No queue servers available.
>
> at
> org.apache.geode.cache.client.internal.QueueManagerImpl.initializeConnections(QueueManagerImpl.java:585)
>
> at
> org.apache.geode.cache.client.internal.QueueManagerImpl.start(QueueManagerImpl.java:296)
>
> at
> org.apache.geode.cache.client.internal.PoolImpl.start(PoolImpl.java:352)
>
> at
> org.apache.geode.cache.client.internal.PoolImpl.finishCreate(PoolImpl.java:176)
>
> at
> org.apache.geode.cache.client.internal.PoolImpl.create(PoolImpl.java:162)
>
> at
> org.apache.geode.internal.cache.PoolFactoryImpl.create(PoolFactoryImpl.java:349)
>
> at
> org.apache.geode.internal.cache.DeltaPropagationDUnitTest.createDurableCacheClient(DeltaPropagationDUnitTest.java:1295)
>
> ... 1 more
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5595) CI: DeltaPropagationDUnit.testBug40165ClientReconnects - NoSubscriptionServersAvailableException
[
https://issues.apache.org/jira/browse/GEODE-5595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith updated GEODE-5595:
-
Issue Type: Bug (was: Test)
> CI: DeltaPropagationDUnit.testBug40165ClientReconnects -
> NoSubscriptionServersAvailableException
>
>
> Key: GEODE-5595
> URL: https://issues.apache.org/jira/browse/GEODE-5595
> Project: Geode
> Issue Type: Bug
> Components: ci, swat
>Reporter: Kenneth Howe
>Priority: Major
>
> {code:java}
> org.apache.geode.internal.cache.DeltaPropagationDUnitTest >
> testBug40165ClientReconnects FAILED
>
> org.apache.geode.cache.NoSubscriptionServersAvailableException:
> org.apache.geode.cache.NoSubscriptionServersAvailableException: Could not
> initialize a primary queue on startup. No queue servers available.
>
> at
> org.apache.geode.cache.client.internal.QueueManagerImpl.getAllConnections(QueueManagerImpl.java:187)
>
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.executeOnQueuesAndReturnPrimaryResult(OpExecutorImpl.java:548)
>
> at
> org.apache.geode.cache.client.internal.PoolImpl.executeOnQueuesAndReturnPrimaryResult(PoolImpl.java:855)
>
> at
> org.apache.geode.cache.client.internal.RegisterInterestOp.execute(RegisterInterestOp.java:58)
>
> at
> org.apache.geode.cache.client.internal.ServerRegionProxy.registerInterest(ServerRegionProxy.java:355)
>
> at
> org.apache.geode.internal.cache.LocalRegion.processSingleInterest(LocalRegion.java:3797)
>
> at
> org.apache.geode.internal.cache.LocalRegion.registerInterest(LocalRegion.java:3888)
>
> at
> org.apache.geode.internal.cache.LocalRegion.registerInterest(LocalRegion.java:3686)
>
> at
> org.apache.geode.internal.cache.LocalRegion.registerInterest(LocalRegion.java:3681)
>
> at
> org.apache.geode.internal.cache.LocalRegion.registerInterest(LocalRegion.java:3676)
>
> at
> org.apache.geode.internal.cache.DeltaPropagationDUnitTest.createDurableCacheClient(DeltaPropagationDUnitTest.java:1305)
>
> at
> org.apache.geode.internal.cache.DeltaPropagationDUnitTest.testBug40165ClientReconnects(DeltaPropagationDUnitTest.java:647)
>
>
> Caused by:
>
> org.apache.geode.cache.NoSubscriptionServersAvailableException: Could
> not initialize a primary queue on startup. No queue servers available.
>
> at
> org.apache.geode.cache.client.internal.QueueManagerImpl.initializeConnections(QueueManagerImpl.java:585)
>
> at
> org.apache.geode.cache.client.internal.QueueManagerImpl.start(QueueManagerImpl.java:296)
>
> at
> org.apache.geode.cache.client.internal.PoolImpl.start(PoolImpl.java:352)
>
> at
> org.apache.geode.cache.client.internal.PoolImpl.finishCreate(PoolImpl.java:176)
>
> at
> org.apache.geode.cache.client.internal.PoolImpl.create(PoolImpl.java:162)
>
> at
> org.apache.geode.internal.cache.PoolFactoryImpl.create(PoolFactoryImpl.java:349)
>
> at
> org.apache.geode.internal.cache.DeltaPropagationDUnitTest.createDurableCacheClient(DeltaPropagationDUnitTest.java:1295)
>
> ... 1 more
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5662) Flaky unit test ExecutorServiceRuleTest.threadCountTwoHasTwoThreads
[
https://issues.apache.org/jira/browse/GEODE-5662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith updated GEODE-5662:
-
Summary: Flaky unit test
ExecutorServiceRuleTest.threadCountTwoHasTwoThreads (was: Flaky unit test
ExecutorServiceRuleTest)
> Flaky unit test ExecutorServiceRuleTest.threadCountTwoHasTwoThreads
> ---
>
> Key: GEODE-5662
> URL: https://issues.apache.org/jira/browse/GEODE-5662
> Project: Geode
> Issue Type: Bug
>Reporter: Dan Smith
>Priority: Major
> Labels: swat
>
> This test failed in CI. To me it looks like this test seems to be assuming
> that if it schedules two tasks they will actually run concurrently, which may
> or may not happen depending on timing.
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/Build/builds/403
> {noformat}
> org.apache.geode.test.junit.rules.ExecutorServiceRuleTest >
> threadCountTwoHasTwoThreads FAILED
> 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.test.junit.rules.ExecutorServiceRuleTest.threadCountTwoHasTwoThreads(ExecutorServiceRuleTest.java:130)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-5662) Flaky unit test ExecutorServiceRuleTest
Dan Smith created GEODE-5662:
Summary: Flaky unit test ExecutorServiceRuleTest
Key: GEODE-5662
URL: https://issues.apache.org/jira/browse/GEODE-5662
Project: Geode
Issue Type: Bug
Reporter: Dan Smith
This test failed in CI. To me it looks like this test seems to be assuming that
if it schedules two tasks they will actually run concurrently, which may or may
not happen depending on timing.
https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/Build/builds/403
{noformat}
org.apache.geode.test.junit.rules.ExecutorServiceRuleTest >
threadCountTwoHasTwoThreads FAILED
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.test.junit.rules.ExecutorServiceRuleTest.threadCountTwoHasTwoThreads(ExecutorServiceRuleTest.java:130)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5662) Flaky unit test ExecutorServiceRuleTest
[
https://issues.apache.org/jira/browse/GEODE-5662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith updated GEODE-5662:
-
Labels: swat (was: )
> Flaky unit test ExecutorServiceRuleTest
> ---
>
> Key: GEODE-5662
> URL: https://issues.apache.org/jira/browse/GEODE-5662
> Project: Geode
> Issue Type: Bug
>Reporter: Dan Smith
>Priority: Major
> Labels: swat
>
> This test failed in CI. To me it looks like this test seems to be assuming
> that if it schedules two tasks they will actually run concurrently, which may
> or may not happen depending on timing.
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/Build/builds/403
> {noformat}
> org.apache.geode.test.junit.rules.ExecutorServiceRuleTest >
> threadCountTwoHasTwoThreads FAILED
> 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.test.junit.rules.ExecutorServiceRuleTest.threadCountTwoHasTwoThreads(ExecutorServiceRuleTest.java:130)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5654) ThreadsMonitoringIntegrationTest is run as a UnitTest despite implicitly being an IntegrationTest
[
https://issues.apache.org/jira/browse/GEODE-5654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16596558#comment-16596558
]
ASF subversion and git services commented on GEODE-5654:
Commit 7c57aefe3e44379920868459cc0b71f3b8d13338 in geode's branch
refs/heads/develop from [~dcavender]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=7c57aef ]
Merge pull request #2396 from PurelyApplied/geode-5654
GEODE-5654: Move integration test out of unitTest directory.
> ThreadsMonitoringIntegrationTest is run as a UnitTest despite implicitly
> being an IntegrationTest
> -
>
> Key: GEODE-5654
> URL: https://issues.apache.org/jira/browse/GEODE-5654
> Project: Geode
> Issue Type: Improvement
> Components: tests
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> This is causing failures as we attempt to reduce the infrastructure required
> by the {{Build}} task in Concourse.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5530) Extract shared test code from test in to frameworks
[
https://issues.apache.org/jira/browse/GEODE-5530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16596536#comment-16596536
]
ASF subversion and git services commented on GEODE-5530:
Commit 8ae1bdbde6dee657e7603b5da37b39101c24ddb5 in geode's branch
refs/heads/develop from Jacob Barrett
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=8ae1bdb ]
GEODE-5530: Moves more shared test code into the DUnit framework.
> Extract shared test code from test in to frameworks
> ---
>
> Key: GEODE-5530
> URL: https://issues.apache.org/jira/browse/GEODE-5530
> Project: Geode
> Issue Type: Improvement
> Components: tests
>Reporter: Jacob S. Barrett
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 8h 50m
> Remaining Estimate: 0h
>
> Many tests between modules share code. Move this code into common frameworks,
> {{geode-junit}} and {{geode-dunit}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5601) AcceptanceTests are run in parallel without using containers, resulting in port conflicts
[
https://issues.apache.org/jira/browse/GEODE-5601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16596534#comment-16596534
]
ASF subversion and git services commented on GEODE-5601:
Commit ad37e34eaf00b94f13cbf4dd0f9e435a987af86b in geode's branch
refs/heads/develop from [~khowe]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=ad37e34 ]
GEODE-5601: Serialize running of acceptance tests in lieu of containerizing
them (#2389)
* GEODE-5601: Serialize running of acceptance tests in lieu of containerizing
them
Fix flaky AccpetanceTest runs by running them serially. Note that this does
make a
hit on the runtime (~ 10% in testing) for this category of test.
> AcceptanceTests are run in parallel without using containers, resulting in
> port conflicts
> -
>
> Key: GEODE-5601
> URL: https://issues.apache.org/jira/browse/GEODE-5601
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Jacob S. Barrett
>Assignee: Kenneth Howe
>Priority: Major
> Labels: flaky, pull-request-available, swat
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> {noformat}
> org.apache.geode.management.internal.cli.commands.DeployWithLargeJarTest >
> deployLargeSetOfJars FAILED
> org.junit.ComparisonFailure: expected:<[0]> 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.test.junit.rules.gfsh.GfshScript.awaitIfNecessary(GfshScript.java:117)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:135)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:106)
> at
> org.apache.geode.management.internal.cli.commands.DeployWithLargeJarTest.deployLargeSetOfJars(DeployWithLargeJarTest.java:41)
> {noformat}
> Passes:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/pr-develop/jobs/AcceptanceTest/builds/721
> Fails:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/pr-develop/jobs/AcceptanceTest/builds/728
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5601) AcceptanceTests are run in parallel without using containers, resulting in port conflicts
[
https://issues.apache.org/jira/browse/GEODE-5601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16596533#comment-16596533
]
ASF subversion and git services commented on GEODE-5601:
Commit ad37e34eaf00b94f13cbf4dd0f9e435a987af86b in geode's branch
refs/heads/develop from [~khowe]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=ad37e34 ]
GEODE-5601: Serialize running of acceptance tests in lieu of containerizing
them (#2389)
* GEODE-5601: Serialize running of acceptance tests in lieu of containerizing
them
Fix flaky AccpetanceTest runs by running them serially. Note that this does
make a
hit on the runtime (~ 10% in testing) for this category of test.
> AcceptanceTests are run in parallel without using containers, resulting in
> port conflicts
> -
>
> Key: GEODE-5601
> URL: https://issues.apache.org/jira/browse/GEODE-5601
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Jacob S. Barrett
>Assignee: Kenneth Howe
>Priority: Major
> Labels: flaky, pull-request-available, swat
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> {noformat}
> org.apache.geode.management.internal.cli.commands.DeployWithLargeJarTest >
> deployLargeSetOfJars FAILED
> org.junit.ComparisonFailure: expected:<[0]> 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.test.junit.rules.gfsh.GfshScript.awaitIfNecessary(GfshScript.java:117)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:135)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:106)
> at
> org.apache.geode.management.internal.cli.commands.DeployWithLargeJarTest.deployLargeSetOfJars(DeployWithLargeJarTest.java:41)
> {noformat}
> Passes:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/pr-develop/jobs/AcceptanceTest/builds/721
> Fails:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/pr-develop/jobs/AcceptanceTest/builds/728
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-4805) Support a broad range of hostname port notations
[ https://issues.apache.org/jira/browse/GEODE-4805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller updated GEODE-4805: --- Component/s: docs > Support a broad range of hostname port notations > > > Key: GEODE-4805 > URL: https://issues.apache.org/jira/browse/GEODE-4805 > Project: Geode > Issue Type: Improvement > Components: configuration, docs >Reporter: Swapnil Bawaskar >Priority: Minor > Labels: EaseOfUse > > In addition to hostname[port] notation, we should support hostname:port and a > host of other notations commonly used. Here are a few commonly used examples: > https://github.com/google/guava/blob/master/guava/src/com/google/common/net/HostAndPort.java -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-5656) Upgrade build to use Gradle 4.10
[ https://issues.apache.org/jira/browse/GEODE-5656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob S. Barrett resolved GEODE-5656. - Resolution: Fixed Fix Version/s: 1.7.0 > Upgrade build to use Gradle 4.10 > > > Key: GEODE-5656 > URL: https://issues.apache.org/jira/browse/GEODE-5656 > Project: Geode > Issue Type: Improvement > Components: build >Reporter: Jacob S. Barrett >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 50m > Remaining Estimate: 0h > > https://docs.gradle.org/4.10/release-notes.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-5618) FunctionService.onServer() and FunctionService.onRegion() fail when multiuser-authentication=true
[
https://issues.apache.org/jira/browse/GEODE-5618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella resolved GEODE-5618.
-
Resolution: Fixed
Fix Version/s: 1.7.0
> FunctionService.onServer() and FunctionService.onRegion() fail when
> multiuser-authentication=true
> -
>
> Key: GEODE-5618
> URL: https://issues.apache.org/jira/browse/GEODE-5618
> Project: Geode
> Issue Type: Bug
> Components: functions, security
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The problem resides within the {{ServerFunctionExecutor}} class, specifically
> in the following section of code:
> {code:title=ServerFunctionExecutor.java|borderStyle=solid}
> public ResultCollector execute(final String functionName) {
> (...)
> byte[] functionAttributes = getFunctionAttributes(functionName);
> if (functionAttributes == null) {
> Object obj = GetFunctionAttributeOp.execute(this.pool, functionName);
> functionAttributes = (byte[]) obj;
> addFunctionAttributes(functionName, functionAttributes);
> }
> (..)
> }
> {code}
> We are specifically executing an internal function (namely
> {{GetFunctionAttributeOp}}) to retrieve the metadata for the function
> executed by the client *without setting the user attributes* required by the
> authentication mechanism and, as such, the execution fails for this
> particular function instead of the one executed by the client (it's not even
> part of the stack trace):
> {noformat}
> Exception in thread "main" java.lang.UnsupportedOperationException: Use Pool
> APIs for doing operations when multiuser-secure-mode-enabled is set to true.
> at
> org.apache.geode.cache.client.internal.PoolImpl.authenticateIfRequired(PoolImpl.java:1549)
> at
> org.apache.geode.cache.client.internal.PoolImpl.authenticateIfRequired(PoolImpl.java:1531)
> at org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:781)
> at
> org.apache.geode.cache.client.internal.GetFunctionAttributeOp.execute(GetFunctionAttributeOp.java:24)
> at
> org.apache.geode.internal.cache.execute.ServerFunctionExecutor.execute(ServerFunctionExecutor.java:310)
> {noformat}
> The other top-level methods from {{ServerFunctionExecutor}} and
> {{ServerRegionFunctionExecutor}} configure the user attributes before
> actually executing the function, that's why (as a workaround), the user can
> use {{FunctionService.onServer(regionService).execute(new MyFunction())}},
> works as expected:
> {code}
> if (proxyCache != null) {
> if (this.proxyCache.isClosed()) {
> throw proxyCache.getCacheClosedException("Cache is closed for this user.");
> }
> UserAttributes.userAttributes.set(this.proxyCache.getUserAttributes());
> }
> {code}
> The solution would be to add the same _pre-operation logic_ to the buggy
> method.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-3209) Standard output is not redirected to log file
[
https://issues.apache.org/jira/browse/GEODE-3209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16596044#comment-16596044
]
Juan José Ramos Cassella commented on GEODE-3209:
-
This is fixed through GEODE-4101. When the member stats, if the
{{--redirect-output}} parameter is configured as {{true}}, all output sent to
{{standard error}} and {{standard output}} (including the callbacks) will go to
the member's log file.
> Standard output is not redirected to log file
> -
>
> Key: GEODE-3209
> URL: https://issues.apache.org/jira/browse/GEODE-3209
> Project: Geode
> Issue Type: Bug
> Components: logging
>Reporter: Swapnil Bawaskar
>Priority: Minor
> Labels: EaseOfUse
>
> Standard output from Callbacks (CacheListeners, CacheWriters etc) should be
> redirected to the log file.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
