[jira] [Created] (GEODE-6274) CreateRegionCommand.java:248 Produces a build error
Peter Tran created GEODE-6274:
-
Summary: CreateRegionCommand.java:248 Produces a build error
Key: GEODE-6274
URL: https://issues.apache.org/jira/browse/GEODE-6274
Project: Geode
Issue Type: Bug
Reporter: Peter Tran
When building geode, the following error occurs for the CreateRegionCommand
/Users/pivotal/workspace/geode/geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/CreateRegionCommand.java:248:
warning: non-varargs call of varargs method with inexact argument type for
last parameter;
new String[] {prColocatedWith}));
^
cast to Object for a varargs call
cast to Object[] for a non-varargs call and to suppress this warning
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-6271) Unknown pdx type error occurs when a single client is connected to two separate clusters
[ https://issues.apache.org/jira/browse/GEODE-6271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith updated GEODE-6271: - Description: If * A client is connected through two different pools to two different geode clusters * The clusters are not connected by WAN * The same pdx serialized class is used in both clusters * and the client puts into one or more clusters Then it is possible that the client put will result in a value in one of the clusters that will fail deserialization with "java.lang.IllegalStateException: Unknown pdx type." This is because the client will use a type id that is generated in one cluster but is not known to the other cluster. I've attached a test case that replicates this scenario. The client used to have some logic that copied PDX types from one cluster to another in some cases. That logic was removed with cf0b378429b643513366ce90226e4f6472056c7b. However, other cases were still not copying the type. In the attached test case, one of the tests will pass if the changes from cf0b3784 are reverted, but the others still fail. was: If * A client is connected through two different pools to two different geode clusters * The clusters are not connected by WAN * The same pdx serialized class is used in both clusters * and the client puts into one more more clusters Then it is possible that the client put will result in a value in on of the clusters that will fail deserialization with "java.lang.IllegalStateException: Unknown pdx type." because the client will use a type id that is generated in one cluster but is not known to the other cluster. I've attached a test case that replicates this scenario. The client used to have some logic that copied PDX types from one cluster to another in some cases. That logic was removed with cf0b378429b643513366ce90226e4f6472056c7b. However, other cases were still not copying the type. In the attached test case, one of the tests will pass if the changes from cf0b3784 are reverted, but the others still fail. > Unknown pdx type error occurs when a single client is connected to two > separate clusters > > > Key: GEODE-6271 > URL: https://issues.apache.org/jira/browse/GEODE-6271 > Project: Geode > Issue Type: Bug > Components: serialization >Reporter: Dan Smith >Priority: Major > Attachments: > 0001-GEODE-6271-Test-of-client-connected-to-multiple-clus.patch > > > If > * A client is connected through two different pools to two different geode > clusters > * The clusters are not connected by WAN > * The same pdx serialized class is used in both clusters > * and the client puts into one or more clusters > Then it is possible that the client put will result in a value in one of the > clusters that will fail deserialization with > "java.lang.IllegalStateException: Unknown pdx type." This is because the > client will use a type id that is generated in one cluster but is not known > to the other cluster. > I've attached a test case that replicates this scenario. > The client used to have some logic that copied PDX types from one cluster to > another in some cases. That logic was removed with > cf0b378429b643513366ce90226e4f6472056c7b. However, other cases were still not > copying the type. In the attached test case, one of the tests will pass if > the changes from cf0b3784 are reverted, but the others still fail. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6217) Region created with --group option does NOT get saved in cluster config
[
https://issues.apache.org/jira/browse/GEODE-6217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16743251#comment-16743251
]
Jinmei Liao commented on GEODE-6217:
Darrel is correct, if you don't specify a "group", it assumes you want to
export the "cluster" level configuration,
> Region created with --group option does NOT get saved in cluster config
> ---
>
> Key: GEODE-6217
> URL: https://issues.apache.org/jira/browse/GEODE-6217
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Affects Versions: 1.8.0
>Reporter: Diane Hardman
>Priority: Major
>
> I have created a server in a group and then created a region to only be put
> on servers in that group. When I then export cluster config to my screen, the
> region is not shown.
> Here are the steps to reproduce:
> {panel:title=gfsh Session}
> gfsh>start locator --name=locator1
> gfsh>configure pdx --read-serialized=true
> --auto-serializable-classes=io.pivotal.gemfire.demo.entity.*
> gfsh>start server --name=server1 --group=PersonGroup
> #NOTE: this second server is NOT in the group
> gfsh>start server --name=server2 --server-port=40405
> #NOTE: the describe server commands show one server is in the group, the
> other not
> gfsh>describe member --name=server1
> Name : server1
> Id : 172.17.0.2(server1:1257):41001
> Host : gpdb.pivotal.io
> Regions :
> PID : 1257
> Groups : PersonGroup
> Used Heap : 74M
> Max Heap : 1324M
> Working Dir : /root/demo/server1
> Log file : /root/demo/server1/server1.log
> Locators : 172.17.0.2[10334]
>
> Cache Server Information
> Server Bind :
> Server Port : 40404
> Running : true
> Client Connections : 0
>
> gfsh>describe member --name=server2
> Name : server2
> Id : 172.17.0.2(server2:1348):41002
> Host : gpdb.pivotal.io
> Regions :
> PID : 1348
> Groups :
> Used Heap : 50M
> Max Heap : 1324M
> Working Dir : /root/demo/server2
> Log file : /root/demo/server2/server2.log
> Locators : 172.17.0.2[10334]
>
> Cache Server Information
> Server Bind :
> Server Port : 40405
> Running : true
> Client Connections : 0
> #Now create a new region for the server group; i.e. only add the region to
> server1
> gfsh>create region --name=Parent --type=PARTITION --redundant-copies=1
> --group=PersonGroup
> Member | Status | Message
> --- | -- | -
> server1 | OK | Region "/Parent" created on "server1"
>
>
>
>
> Changes to configuration for group 'PersonGroup' are persisted.
> gfsh>describe region --name=Parent
> ..
> Name : Parent
> Data Policy : partition
> Hosting Members : server1
>
> Non-Default Attributes Shared By Hosting Members
>
> Type | Name | Value
> - | | -
> Region | size | 0
> | data-policy | PARTITION
> Partition | redundant-copies | 1
> #Add another region without the server group so it's stored on both servers
> gfsh>create region --name=LargeRegion --type=PARTITION --redundant-copies=0
> Member | Status | Message
> --- | -- | --
> server1 | OK | Region "/LargeRegion" created on "server1"
> server2 | OK | Region "/LargeRegion" created on "server2"
>
>
>
>
> Changes to configuration for group 'cluster' are persisted.
> #Now export cluster config to the screen:
> gfsh>export cluster-configuration
> cluster.xml:
> xsi:schemaLocation="http://geode.apache.org/schema/lucene
> [http://geode.apache.org/schema/lucene/lucene-1.0.xsd]
> [http://geode.apache.org/schema/cache]
> [http://geode.apache.org/schema/cache/cache-1.0.xsd]
> [http://geode.apache.org/schema/jdbc]
> [http://geode.apache.org/schema/jdbc/jdbc-1.0.xsd] gpdb
> [http://schema.pivotal.io/gemfire/gpdb/gpdb-3.3.xsd] gpdb
> [http://schema.pivotal.io/gemfire/gpdb/gpdb-3.3.xsd]";
> xmlns="http://geode.apache.org/schema/cache";
> xmlns:gpdb="http://schema.pivotal.io/gemfire/gpdb";
> xmlns:lucene="http://geode.apache.org/schema/lucene";
> xmlns:jdbc="http://geode.apache.org/schema/jdbc";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
> persistent="false">
>
>
> org.apache.geode.pdx.ReflectionBasedAutoSerializer
>
> io.pivotal.gemfire.demo.entity.*
>
>
>
>
> connection-url="jdbc:postgresql://localhost:5432/gemfire_db"
> jndi-name="datasource" password="changeme" type="SimpleDataSource"
> user-name="g2c_user"/>
>
>
[jira] [Commented] (GEODE-6174) Create Region REST API
[ https://issues.apache.org/jira/browse/GEODE-6174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16743258#comment-16743258 ] ASF subversion and git services commented on GEODE-6174: Commit 8c1629a25280604465715ccfe4c75b9611ab618b in geode's branch refs/heads/develop from jinmeiliao [ https://gitbox.apache.org/repos/asf?p=geode.git;h=8c1629a ] GEODE-6174: Added rest controller to process post request to /geode-m… (#3066) * GEODE-6174: Added rest controller to process post request to /geode-management/v2/regions Co-authored-by: Jens Deppe Co-authored-by: Peter Tran * add geode-web-management module to process the management rest api * inject security service into the authProvider instead of static lookup > Create Region REST API > -- > > Key: GEODE-6174 > URL: https://issues.apache.org/jira/browse/GEODE-6174 > Project: Geode > Issue Type: New Feature > Components: docs, management >Reporter: Peter Tran >Priority: Major > Labels: pull-request-available > Time Spent: 2.5h > Remaining Estimate: 0h > > I want to be able to interact with the cluster without having to be on the > cluster in order to effect the configuration. Either as a developer, I want > to develop code in my IDE and as part of developing that code, I need to > create regions. Or as a data operator, I need to perform configurations on > the cluster and I want to interact with the cluster. > > As a Developer > I want to create a region in the cluster using the JAVA API on the cluster > when I am not located on the cluster (I do not need to be be on a node on the > cluster) > when I am authenticated and authorized for create region > So that a region is created on the cluster > So that I can put and get data in that region -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6174) Create Region REST API
[ https://issues.apache.org/jira/browse/GEODE-6174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16743259#comment-16743259 ] ASF subversion and git services commented on GEODE-6174: Commit 8c1629a25280604465715ccfe4c75b9611ab618b in geode's branch refs/heads/develop from jinmeiliao [ https://gitbox.apache.org/repos/asf?p=geode.git;h=8c1629a ] GEODE-6174: Added rest controller to process post request to /geode-m… (#3066) * GEODE-6174: Added rest controller to process post request to /geode-management/v2/regions Co-authored-by: Jens Deppe Co-authored-by: Peter Tran * add geode-web-management module to process the management rest api * inject security service into the authProvider instead of static lookup > Create Region REST API > -- > > Key: GEODE-6174 > URL: https://issues.apache.org/jira/browse/GEODE-6174 > Project: Geode > Issue Type: New Feature > Components: docs, management >Reporter: Peter Tran >Priority: Major > Labels: pull-request-available > Time Spent: 2.5h > Remaining Estimate: 0h > > I want to be able to interact with the cluster without having to be on the > cluster in order to effect the configuration. Either as a developer, I want > to develop code in my IDE and as part of developing that code, I need to > create regions. Or as a data operator, I need to perform configurations on > the cluster and I want to interact with the cluster. > > As a Developer > I want to create a region in the cluster using the JAVA API on the cluster > when I am not located on the cluster (I do not need to be be on a node on the > cluster) > when I am authenticated and authorized for create region > So that a region is created on the cluster > So that I can put and get data in that region -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6275) Benchmarks CI job silently fails
Helena Bales created GEODE-6275: --- Summary: Benchmarks CI job silently fails Key: GEODE-6275 URL: https://issues.apache.org/jira/browse/GEODE-6275 Project: Geode Issue Type: Bug Reporter: Helena Bales The benchmark task in CI silently fails when it fails to build geode or get resources. The benchmark job should go red when it fails to build geode or fails to get resources from Maven. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6184) Create a java API for createRegion
[ https://issues.apache.org/jira/browse/GEODE-6184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16743276#comment-16743276 ] ASF subversion and git services commented on GEODE-6184: Commit 87e65ea366df87f35f7817aacf11381e2aa3c9ae in geode's branch refs/heads/develop from Aditya Anchuri [ https://gitbox.apache.org/repos/asf?p=geode.git;h=87e65ea ] GEODE-6184 Added internal implementation of ClusterManagementService Java API to create a region (#3059) Signed-off-by: Jinmei Liao Signed-off-by: Aditya Anchuri Signed-off-by: Jens Deppe Signed-off-by: Peter Tran Signed-off-by: Kenneth Howe * Define ClusterManagementService interface * created ClusterManagementService's implementation on the locator * implemented RegionConfig's realizer and mutator so that the ClusterManagementService can use that to create the region and persist the configuration. > Create a java API for createRegion > -- > > Key: GEODE-6184 > URL: https://issues.apache.org/jira/browse/GEODE-6184 > Project: Geode > Issue Type: Sub-task > Components: management >Reporter: Peter Tran >Priority: Major > Labels: pull-request-available > Time Spent: 7.5h > Remaining Estimate: 0h > > Implement the a java API for createRegion > h1. Inputs > * RegionConfig > * group > h1. Output > which includes: > * if the region is created on all applicable servers > * if the configuration is updated > * if failed, what's the reason of failure > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6275) Benchmarks CI job silently fails
[ https://issues.apache.org/jira/browse/GEODE-6275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Helena Bales updated GEODE-6275: Component/s: benchmarks > Benchmarks CI job silently fails > > > Key: GEODE-6275 > URL: https://issues.apache.org/jira/browse/GEODE-6275 > Project: Geode > Issue Type: Bug > Components: benchmarks >Reporter: Helena Bales >Assignee: Helena Bales >Priority: Major > > The benchmark task in CI silently fails when it fails to build geode or get > resources. The benchmark job should go red when it fails to build geode or > fails to get resources from Maven. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6275) Benchmarks CI job silently fails
[ https://issues.apache.org/jira/browse/GEODE-6275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-6275: -- Labels: pull-request-available (was: ) > Benchmarks CI job silently fails > > > Key: GEODE-6275 > URL: https://issues.apache.org/jira/browse/GEODE-6275 > Project: Geode > Issue Type: Bug > Components: benchmarks >Reporter: Helena Bales >Assignee: Helena Bales >Priority: Major > Labels: pull-request-available > > The benchmark task in CI silently fails when it fails to build geode or get > resources. The benchmark job should go red when it fails to build geode or > fails to get resources from Maven. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-6275) Benchmarks CI job silently fails
[ https://issues.apache.org/jira/browse/GEODE-6275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Helena Bales reassigned GEODE-6275: --- Assignee: Helena Bales > Benchmarks CI job silently fails > > > Key: GEODE-6275 > URL: https://issues.apache.org/jira/browse/GEODE-6275 > Project: Geode > Issue Type: Bug >Reporter: Helena Bales >Assignee: Helena Bales >Priority: Major > > The benchmark task in CI silently fails when it fails to build geode or get > resources. The benchmark job should go red when it fails to build geode or > fails to get resources from Maven. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-6268) initializeUniquePortRange_willReturnUniquePortsForUniqueRanges seems flaky on Windows
[ https://issues.apache.org/jira/browse/GEODE-6268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon reassigned GEODE-6268: --- Assignee: Kenneth Howe > initializeUniquePortRange_willReturnUniquePortsForUniqueRanges seems flaky on > Windows > - > > Key: GEODE-6268 > URL: https://issues.apache.org/jira/browse/GEODE-6268 > Project: Geode > Issue Type: Bug > Components: ci >Reporter: Sean Goller >Assignee: Kenneth Howe >Priority: Major > > org.apache.geode.internal.AvailablePortHelperIntegrationTest.initializeUniquePortRange_willReturnUniquePortsForUniqueRanges > periodically fails on windows. It seems like there's some flakiness being > introduced that may be platform specfic. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6274) CreateRegionCommand.java:248 Produces a build warning
[
https://issues.apache.org/jira/browse/GEODE-6274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Tran updated GEODE-6274:
--
Summary: CreateRegionCommand.java:248 Produces a build warning (was:
CreateRegionCommand.java:248 Produces a build error)
> CreateRegionCommand.java:248 Produces a build warning
> -
>
> Key: GEODE-6274
> URL: https://issues.apache.org/jira/browse/GEODE-6274
> Project: Geode
> Issue Type: Bug
>Reporter: Peter Tran
>Priority: Major
>
> When building geode, the following error occurs for the CreateRegionCommand
>
>
> /Users/pivotal/workspace/geode/geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/CreateRegionCommand.java:248:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> new String[] {prColocatedWith}));
> ^
> cast to Object for a varargs call
> cast to Object[] for a non-varargs call and to suppress this warning
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-6274) CreateRegionCommand.java:248 Produces a build warning
[
https://issues.apache.org/jira/browse/GEODE-6274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Tran updated GEODE-6274:
--
Issue Type: Improvement (was: Bug)
> CreateRegionCommand.java:248 Produces a build warning
> -
>
> Key: GEODE-6274
> URL: https://issues.apache.org/jira/browse/GEODE-6274
> Project: Geode
> Issue Type: Improvement
>Reporter: Peter Tran
>Priority: Major
>
> When building geode, the following error occurs for the CreateRegionCommand
>
>
> /Users/pivotal/workspace/geode/geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/CreateRegionCommand.java:248:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> new String[] {prColocatedWith}));
> ^
> cast to Object for a varargs call
> cast to Object[] for a non-varargs call and to suppress this warning
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-6147) Fail benchmark junit tests if their numbers deviate too far from a baseline
[ https://issues.apache.org/jira/browse/GEODE-6147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Goller reassigned GEODE-6147: -- Assignee: Sean Goller > Fail benchmark junit tests if their numbers deviate too far from a baseline > --- > > Key: GEODE-6147 > URL: https://issues.apache.org/jira/browse/GEODE-6147 > Project: Geode > Issue Type: Improvement > Components: benchmarks >Reporter: Dan Smith >Assignee: Sean Goller >Priority: Major > > We want to fail tests if performance gets worse. We also want a signal to > create a new baseline if performance gets better, so perhaps we should fail > tests in that case as well. > One way to do this would be to add a new system property to the > TestRunners.defaultRunner() that takes in a baseline directory. The test > itself could compare it's results with the baseline after running and fail if > it deviates too far from the baseline. > Using that, we could a new flag to the benchmark task to pass in that > baseline and cause tests that deviate to fail. > Eg > ./gradlew benchmark -Pbaseline=/some/dir > Acceptance: > run_against_baseline.sh generates a failure report if benchmarks deviate too > far from the baseline. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6134) Generate summary of benchmarks result as part of running the benchmarks
[ https://issues.apache.org/jira/browse/GEODE-6134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Goller resolved GEODE-6134. Resolution: Fixed > Generate summary of benchmarks result as part of running the benchmarks > --- > > Key: GEODE-6134 > URL: https://issues.apache.org/jira/browse/GEODE-6134 > Project: Geode > Issue Type: Improvement > Components: benchmarks >Reporter: Dan Smith >Assignee: Sean Goller >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > We currently have a separate ./gradlew analyzeRun task. We should generate > the analysis as part of the run_against_baseline.sh script so we don't have > to keep rerunning it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6275) Benchmarks CI job silently fails
[ https://issues.apache.org/jira/browse/GEODE-6275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16743296#comment-16743296 ] ASF subversion and git services commented on GEODE-6275: Commit 3a190d31b41e64d2c2464605b2eb3d3852e21c96 in geode's branch refs/heads/develop from Helena Bales [ https://gitbox.apache.org/repos/asf?p=geode.git;h=3a190d3 ] GEODE-6275: Fail when benchmark pipes fails. (#3077) * Increase timeout when fetch artifacts. Co-authored-by: Helena A. Bales Co-authored-by: Jacob Barrett > Benchmarks CI job silently fails > > > Key: GEODE-6275 > URL: https://issues.apache.org/jira/browse/GEODE-6275 > Project: Geode > Issue Type: Bug > Components: benchmarks >Reporter: Helena Bales >Assignee: Helena Bales >Priority: Major > Labels: pull-request-available > Time Spent: 40m > Remaining Estimate: 0h > > The benchmark task in CI silently fails when it fails to build geode or get > resources. The benchmark job should go red when it fails to build geode or > fails to get resources from Maven. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-6276) Benchmark CI should fetch versions and build develop
[ https://issues.apache.org/jira/browse/GEODE-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Helena Bales reassigned GEODE-6276: --- Assignee: Helena Bales > Benchmark CI should fetch versions and build develop > > > Key: GEODE-6276 > URL: https://issues.apache.org/jira/browse/GEODE-6276 > Project: Geode > Issue Type: Bug >Reporter: Helena Bales >Assignee: Helena Bales >Priority: Major > > The benchmark ci job should build all non-release branches and fetch geode > releases. This avoids the cost of rebuilding released versions of Geode and > illiminates the challenge of the build parameters diverging between old > versions and develop. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6276) Benchmark CI should fetch versions and build develop
Helena Bales created GEODE-6276: --- Summary: Benchmark CI should fetch versions and build develop Key: GEODE-6276 URL: https://issues.apache.org/jira/browse/GEODE-6276 Project: Geode Issue Type: Bug Reporter: Helena Bales The benchmark ci job should build all non-release branches and fetch geode releases. This avoids the cost of rebuilding released versions of Geode and illiminates the challenge of the build parameters diverging between old versions and develop. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6274) CreateRegionCommand.java:248 Produces a build warning
[
https://issues.apache.org/jira/browse/GEODE-6274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-6274:
--
Labels: pull-request-available (was: )
> CreateRegionCommand.java:248 Produces a build warning
> -
>
> Key: GEODE-6274
> URL: https://issues.apache.org/jira/browse/GEODE-6274
> Project: Geode
> Issue Type: Improvement
>Reporter: Peter Tran
>Priority: Major
> Labels: pull-request-available
>
> When building geode, the following error occurs for the CreateRegionCommand
>
>
> /Users/pivotal/workspace/geode/geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/CreateRegionCommand.java:248:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> new String[] {prColocatedWith}));
> ^
> cast to Object for a varargs call
> cast to Object[] for a non-varargs call and to suppress this warning
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-5526) CI Failure: ParallelWANStatsDUnitTest.testParallelPropagationHA fails with AssertionError for Queue Size
[
https://issues.apache.org/jira/browse/GEODE-5526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McMahon reassigned GEODE-5526:
---
Assignee: Ryan McMahon
> CI Failure: ParallelWANStatsDUnitTest.testParallelPropagationHA fails with
> AssertionError for Queue Size
>
>
> Key: GEODE-5526
> URL: https://issues.apache.org/jira/browse/GEODE-5526
> Project: Geode
> Issue Type: Bug
>Reporter: Helena Bales
>Assignee: Ryan McMahon
>Priority: Major
> Labels: swat
>
> Failed in Geode DistributedTests on August 3rd, 2018 with:
> {{org.apache.geode.internal.cache.wan.parallel.ParallelWANStatsDUnitTest >
> testParallelPropagationHA FAILED}}
> {{java.lang.AssertionError: expected:<0> but was:<-3>}}
> {{at org.junit.Assert.fail(Assert.java:88)}}
> {{at org.junit.Assert.failNotEquals(Assert.java:834)}}
> {{at org.junit.Assert.assertEquals(Assert.java:645)}}
> {{at org.junit.Assert.assertEquals(Assert.java:631)}}
> {{at
> org.apache.geode.internal.cache.wan.parallel.ParallelWANStatsDUnitTest.testParallelPropagationHA(ParallelWANStatsDUnitTest.java:429)}}
> On the assertion:
> {{assertEquals(0, v5List.get(0) + v6List.get(0) + v7List.get(0)); // queue
> size}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-6275) Benchmarks CI job silently fails
[ https://issues.apache.org/jira/browse/GEODE-6275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16743297#comment-16743297 ] ASF subversion and git services commented on GEODE-6275: Commit 048e4030ae4545e6a029f80691b549770e354f43 in geode-benchmarks's branch refs/heads/develop from Helena Bales [ https://gitbox.apache.org/repos/asf?p=geode-benchmarks.git;h=048e403 ] GEODE-6275: Fail Benchmark job when build fails (#41) Fail the benchmark job when it fails to build or get resources from Maven. Co-authored-by: Jacob Barrett > Benchmarks CI job silently fails > > > Key: GEODE-6275 > URL: https://issues.apache.org/jira/browse/GEODE-6275 > Project: Geode > Issue Type: Bug > Components: benchmarks >Reporter: Helena Bales >Assignee: Helena Bales >Priority: Major > Labels: pull-request-available > Time Spent: 40m > Remaining Estimate: 0h > > The benchmark task in CI silently fails when it fails to build geode or get > resources. The benchmark job should go red when it fails to build geode or > fails to get resources from Maven. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (GEODE-5526) CI Failure: ParallelWANStatsDUnitTest.testParallelPropagationHA fails with AssertionError for Queue Size
[
https://issues.apache.org/jira/browse/GEODE-5526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McMahon reopened GEODE-5526:
-
Failed in run:
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/293
> CI Failure: ParallelWANStatsDUnitTest.testParallelPropagationHA fails with
> AssertionError for Queue Size
>
>
> Key: GEODE-5526
> URL: https://issues.apache.org/jira/browse/GEODE-5526
> Project: Geode
> Issue Type: Bug
>Reporter: Helena Bales
>Assignee: Ryan McMahon
>Priority: Major
> Labels: swat
>
> Failed in Geode DistributedTests on August 3rd, 2018 with:
> {{org.apache.geode.internal.cache.wan.parallel.ParallelWANStatsDUnitTest >
> testParallelPropagationHA FAILED}}
> {{java.lang.AssertionError: expected:<0> but was:<-3>}}
> {{at org.junit.Assert.fail(Assert.java:88)}}
> {{at org.junit.Assert.failNotEquals(Assert.java:834)}}
> {{at org.junit.Assert.assertEquals(Assert.java:645)}}
> {{at org.junit.Assert.assertEquals(Assert.java:631)}}
> {{at
> org.apache.geode.internal.cache.wan.parallel.ParallelWANStatsDUnitTest.testParallelPropagationHA(ParallelWANStatsDUnitTest.java:429)}}
> On the assertion:
> {{assertEquals(0, v5List.get(0) + v6List.get(0) + v7List.get(0)); // queue
> size}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-6277) CI failure: DistributedNoAckRegionDUnitTest.testNBRegionDestructionDuringGetInitialImage
[
https://issues.apache.org/jira/browse/GEODE-6277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McMahon updated GEODE-6277:
Component/s: regions
membership
> CI failure:
> DistributedNoAckRegionDUnitTest.testNBRegionDestructionDuringGetInitialImage
>
>
> Key: GEODE-6277
> URL: https://issues.apache.org/jira/browse/GEODE-6277
> Project: Geode
> Issue Type: Bug
> Components: membership, regions
>Affects Versions: 1.9.0
>Reporter: Ryan McMahon
>Priority: Major
>
>
> {code:java}
> org.apache.geode.cache30.DistributedNoAckRegionDUnitTest >
> testNBRegionDestructionDuringGetInitialImage FAILED
> java.lang.AssertionError: asyncGII failed
> Caused by:
> org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
> {code}
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/288|http://example.com/]
> This appears to be part of a larger flakey failure ticket, but this
> particular failure was not addressed. Original flakey failure ticket:
> [https://issues.apache.org/jira/browse/GEODE-5412?jql=text%20~%20%22testNBRegionDestructionDuringGetInitialImage%22|http://example.com/]
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-6277) CI failure: DistributedNoAckRegionDUnitTest.testNBRegionDestructionDuringGetInitialImage
[
https://issues.apache.org/jira/browse/GEODE-6277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McMahon reassigned GEODE-6277:
---
Assignee: Ryan McMahon
> CI failure:
> DistributedNoAckRegionDUnitTest.testNBRegionDestructionDuringGetInitialImage
>
>
> Key: GEODE-6277
> URL: https://issues.apache.org/jira/browse/GEODE-6277
> Project: Geode
> Issue Type: Bug
> Components: membership, regions
>Affects Versions: 1.9.0
>Reporter: Ryan McMahon
>Assignee: Ryan McMahon
>Priority: Major
>
>
> {code:java}
> org.apache.geode.cache30.DistributedNoAckRegionDUnitTest >
> testNBRegionDestructionDuringGetInitialImage FAILED
> java.lang.AssertionError: asyncGII failed
> Caused by:
> org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
> {code}
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/288|http://example.com/]
> This appears to be part of a larger flakey failure ticket, but this
> particular failure was not addressed. Original flakey failure ticket:
> [https://issues.apache.org/jira/browse/GEODE-5412?jql=text%20~%20%22testNBRegionDestructionDuringGetInitialImage%22|http://example.com/]
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-6277) CI failure: DistributedNoAckRegionDUnitTest.testNBRegionDestructionDuringGetInitialImage
[
https://issues.apache.org/jira/browse/GEODE-6277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McMahon reassigned GEODE-6277:
---
Assignee: xiaojian zhou (was: Ryan McMahon)
> CI failure:
> DistributedNoAckRegionDUnitTest.testNBRegionDestructionDuringGetInitialImage
>
>
> Key: GEODE-6277
> URL: https://issues.apache.org/jira/browse/GEODE-6277
> Project: Geode
> Issue Type: Bug
> Components: membership, regions
>Affects Versions: 1.9.0
>Reporter: Ryan McMahon
>Assignee: xiaojian zhou
>Priority: Major
>
>
> {code:java}
> org.apache.geode.cache30.DistributedNoAckRegionDUnitTest >
> testNBRegionDestructionDuringGetInitialImage FAILED
> java.lang.AssertionError: asyncGII failed
> Caused by:
> org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
> {code}
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/288|http://example.com/]
> This appears to be part of a larger flakey failure ticket, but this
> particular failure was not addressed. Original flakey failure ticket:
> [https://issues.apache.org/jira/browse/GEODE-5412?jql=text%20~%20%22testNBRegionDestructionDuringGetInitialImage%22|http://example.com/]
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-6277) CI failure: DistributedNoAckRegionDUnitTest.testNBRegionDestructionDuringGetInitialImage
[
https://issues.apache.org/jira/browse/GEODE-6277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McMahon updated GEODE-6277:
Affects Version/s: 1.9.0
> CI failure:
> DistributedNoAckRegionDUnitTest.testNBRegionDestructionDuringGetInitialImage
>
>
> Key: GEODE-6277
> URL: https://issues.apache.org/jira/browse/GEODE-6277
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.9.0
>Reporter: Ryan McMahon
>Priority: Major
>
>
> {code:java}
> org.apache.geode.cache30.DistributedNoAckRegionDUnitTest >
> testNBRegionDestructionDuringGetInitialImage FAILED
> java.lang.AssertionError: asyncGII failed
> Caused by:
> org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
> {code}
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/288|http://example.com/]
> This appears to be part of a larger flakey failure ticket, but this
> particular failure was not addressed. Original flakey failure ticket:
> [https://issues.apache.org/jira/browse/GEODE-5412?jql=text%20~%20%22testNBRegionDestructionDuringGetInitialImage%22|http://example.com/]
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-6277) CI failure: DistributedNoAckRegionDUnitTest.testNBRegionDestructionDuringGetInitialImage
Ryan McMahon created GEODE-6277:
---
Summary: CI failure:
DistributedNoAckRegionDUnitTest.testNBRegionDestructionDuringGetInitialImage
Key: GEODE-6277
URL: https://issues.apache.org/jira/browse/GEODE-6277
Project: Geode
Issue Type: Bug
Reporter: Ryan McMahon
{code:java}
org.apache.geode.cache30.DistributedNoAckRegionDUnitTest >
testNBRegionDestructionDuringGetInitialImage FAILED
java.lang.AssertionError: asyncGII failed
Caused by:
org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
{code}
[https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/288|http://example.com/]
This appears to be part of a larger flakey failure ticket, but this particular
failure was not addressed. Original flakey failure ticket:
[https://issues.apache.org/jira/browse/GEODE-5412?jql=text%20~%20%22testNBRegionDestructionDuringGetInitialImage%22|http://example.com/]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-5552) Flaky test ConnectCommandWithSSLTest > connectWithJmxSSL
[
https://issues.apache.org/jira/browse/GEODE-5552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McMahon reassigned GEODE-5552:
---
Assignee: Kenneth Howe
> Flaky test ConnectCommandWithSSLTest > connectWithJmxSSL
>
>
> Key: GEODE-5552
> URL: https://issues.apache.org/jira/browse/GEODE-5552
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.8.0
>Reporter: Jacob S. Barrett
>Assignee: Kenneth Howe
>Priority: Major
> Labels: flaky, swat
>
> {noformat}
> > Task :geode-web:distributedTest
> org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest >
> connectWithJmxSSL FAILED
> java.lang.AssertionError:
> Expecting:
> <"_ __
>/ _/ __/ __/ // /
> / / __/ /___ /_ / _ /
> / /__/ / / _/ / // /
> /__/_/ /__/_//_/1.8.0-SNAPSHOT
>
> Monitor and Manage Apache Geode
> Connecting to Locator at [host=localhost, port=42647] ..
> Connection reset
> ">
> to contain:
> <"trying to connect a non-SSL-enabled client to an SSL-enabled locator">
> at
> org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest.connectWithJmxSSL(ConnectCommandWithSSLTest.java:219)
> {noformat}
> Failing:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/pr-develop/jobs/DistributedTest/builds/521
> Passing:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/pr-develop/jobs/DistributedTest/builds/522
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Reopened] (GEODE-5552) Flaky test ConnectCommandWithSSLTest > connectWithJmxSSL
[
https://issues.apache.org/jira/browse/GEODE-5552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McMahon reopened GEODE-5552:
-
> Flaky test ConnectCommandWithSSLTest > connectWithJmxSSL
>
>
> Key: GEODE-5552
> URL: https://issues.apache.org/jira/browse/GEODE-5552
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.8.0
>Reporter: Jacob S. Barrett
>Assignee: Kenneth Howe
>Priority: Major
> Labels: flaky, swat
>
> {noformat}
> > Task :geode-web:distributedTest
> org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest >
> connectWithJmxSSL FAILED
> java.lang.AssertionError:
> Expecting:
> <"_ __
>/ _/ __/ __/ // /
> / / __/ /___ /_ / _ /
> / /__/ / / _/ / // /
> /__/_/ /__/_//_/1.8.0-SNAPSHOT
>
> Monitor and Manage Apache Geode
> Connecting to Locator at [host=localhost, port=42647] ..
> Connection reset
> ">
> to contain:
> <"trying to connect a non-SSL-enabled client to an SSL-enabled locator">
> at
> org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest.connectWithJmxSSL(ConnectCommandWithSSLTest.java:219)
> {noformat}
> Failing:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/pr-develop/jobs/DistributedTest/builds/521
> Passing:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/pr-develop/jobs/DistributedTest/builds/522
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-6278) CI failure: org.apache.geode.cache.query.dunit.QueryDataInconsistencyDUnitTest. testRangeIndex
Aditya Anchuri created GEODE-6278: - Summary: CI failure: org.apache.geode.cache.query.dunit.QueryDataInconsistencyDUnitTest. testRangeIndex Key: GEODE-6278 URL: https://issues.apache.org/jira/browse/GEODE-6278 Project: Geode Issue Type: Bug Components: querying Reporter: Aditya Anchuri ``` org.apache.geode.cache.query.dunit.QueryDataInconsistencyDUnitTest > testRangeIndex FAILED [ |http://concourse.gemfire.pivotal.io/teams/main/pipelines/gemfire-9.3/jobs/DistributedTest/builds/18#L5c336c39:761] java.lang.AssertionError: Thread did not terminate after 200 ms: Thread[run invoked on an instance of org.apache.geode.cache.query.dunit.QueryDataInconsistencyDUnitTest$6,5,] [ |http://concourse.gemfire.pivotal.io/teams/main/pipelines/gemfire-9.3/jobs/DistributedTest/builds/18#L5c336c39:762] at org.junit.Assert.fail(Assert.java:88) [ |http://concourse.gemfire.pivotal.io/teams/main/pipelines/gemfire-9.3/jobs/DistributedTest/builds/18#L5c336c39:763] at org.apache.geode.test.dunit.ThreadUtils.join(ThreadUtils.java:147) [ |http://concourse.gemfire.pivotal.io/teams/main/pipelines/gemfire-9.3/jobs/DistributedTest/builds/18#L5c336c39:764] at org.apache.geode.test.dunit.ThreadUtils.join(ThreadUtils.java:110) [ |http://concourse.gemfire.pivotal.io/teams/main/pipelines/gemfire-9.3/jobs/DistributedTest/builds/18#L5c336c39:765] at org.apache.geode.cache.query.dunit.QueryDataInconsistencyDUnitTest.testRangeIndex(QueryDataInconsistencyDUnitTest.java:304) ``` Seems like a flakey test. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6278) CI failure: org.apache.geode.cache.query.dunit.QueryDataInconsistencyDUnitTest. testRangeIndex
[
https://issues.apache.org/jira/browse/GEODE-6278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aditya Anchuri updated GEODE-6278:
--
Description:
{code:java}
org.apache.geode.cache.query.dunit.QueryDataInconsistencyDUnitTest >
testRangeIndex FAILED
java.lang.AssertionError: Thread did not terminate after 200 ms: Thread[run
invoked on an instance of
org.apache.geode.cache.query.dunit.QueryDataInconsistencyDUnitTest$6,5,]
at org.junit.Assert.fail(Assert.java:88)
at org.apache.geode.test.dunit.ThreadUtils.join(ThreadUtils.java:147)
at org.apache.geode.test.dunit.ThreadUtils.join(ThreadUtils.java:110)
at
org.apache.geode.cache.query.dunit.QueryDataInconsistencyDUnitTest.testRangeIndex(QueryDataInconsistencyDUnitTest.java:304){code}
Seems like a flakey test.
was:
```
org.apache.geode.cache.query.dunit.QueryDataInconsistencyDUnitTest >
testRangeIndex FAILED
[
|http://concourse.gemfire.pivotal.io/teams/main/pipelines/gemfire-9.3/jobs/DistributedTest/builds/18#L5c336c39:761]
java.lang.AssertionError: Thread did not terminate after 200 ms: Thread[run
invoked on an instance of
org.apache.geode.cache.query.dunit.QueryDataInconsistencyDUnitTest$6,5,]
[
|http://concourse.gemfire.pivotal.io/teams/main/pipelines/gemfire-9.3/jobs/DistributedTest/builds/18#L5c336c39:762]
at org.junit.Assert.fail(Assert.java:88)
[
|http://concourse.gemfire.pivotal.io/teams/main/pipelines/gemfire-9.3/jobs/DistributedTest/builds/18#L5c336c39:763]
at org.apache.geode.test.dunit.ThreadUtils.join(ThreadUtils.java:147)
[
|http://concourse.gemfire.pivotal.io/teams/main/pipelines/gemfire-9.3/jobs/DistributedTest/builds/18#L5c336c39:764]
at org.apache.geode.test.dunit.ThreadUtils.join(ThreadUtils.java:110)
[
|http://concourse.gemfire.pivotal.io/teams/main/pipelines/gemfire-9.3/jobs/DistributedTest/builds/18#L5c336c39:765]
at
org.apache.geode.cache.query.dunit.QueryDataInconsistencyDUnitTest.testRangeIndex(QueryDataInconsistencyDUnitTest.java:304)
```
Seems like a flakey test.
> CI failure:
> org.apache.geode.cache.query.dunit.QueryDataInconsistencyDUnitTest.
> testRangeIndex
> --
>
> Key: GEODE-6278
> URL: https://issues.apache.org/jira/browse/GEODE-6278
> Project: Geode
> Issue Type: Bug
> Components: querying
>Reporter: Aditya Anchuri
>Priority: Major
>
> {code:java}
> org.apache.geode.cache.query.dunit.QueryDataInconsistencyDUnitTest >
> testRangeIndex FAILED
>
> java.lang.AssertionError: Thread did not terminate after 200 ms: Thread[run
> invoked on an instance of
> org.apache.geode.cache.query.dunit.QueryDataInconsistencyDUnitTest$6,5,]
>
> at org.junit.Assert.fail(Assert.java:88)
>
> at org.apache.geode.test.dunit.ThreadUtils.join(ThreadUtils.java:147)
>
> at org.apache.geode.test.dunit.ThreadUtils.join(ThreadUtils.java:110)
>
> at
> org.apache.geode.cache.query.dunit.QueryDataInconsistencyDUnitTest.testRangeIndex(QueryDataInconsistencyDUnitTest.java:304){code}
> Seems like a flakey test.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-6278) CI failure: org.apache.geode.cache.query.dunit.QueryDataInconsistencyDUnitTest. testRangeIndex
[
https://issues.apache.org/jira/browse/GEODE-6278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aditya Anchuri updated GEODE-6278:
--
Description:
{code:java}
org.apache.geode.cache.query.dunit.QueryDataInconsistencyDUnitTest >
testRangeIndex FAILED
java.lang.AssertionError: Thread did not terminate after 200 ms: Thread[run
invoked on an instance of
org.apache.geode.cache.query.dunit.QueryDataInconsistencyDUnitTest$6,5,]
at org.junit.Assert.fail(Assert.java:88)
at org.apache.geode.test.dunit.ThreadUtils.join(ThreadUtils.java:147)
at org.apache.geode.test.dunit.ThreadUtils.join(ThreadUtils.java:110)
at
org.apache.geode.cache.query.dunit.QueryDataInconsistencyDUnitTest.testRangeIndex(QueryDataInconsistencyDUnitTest.java:304){code}
Seems like a flakey test.
http://concourse.gemfire.pivotal.io/teams/main/pipelines/gemfire-9.3/jobs/DistributedTest/builds/18
was:
{code:java}
org.apache.geode.cache.query.dunit.QueryDataInconsistencyDUnitTest >
testRangeIndex FAILED
java.lang.AssertionError: Thread did not terminate after 200 ms: Thread[run
invoked on an instance of
org.apache.geode.cache.query.dunit.QueryDataInconsistencyDUnitTest$6,5,]
at org.junit.Assert.fail(Assert.java:88)
at org.apache.geode.test.dunit.ThreadUtils.join(ThreadUtils.java:147)
at org.apache.geode.test.dunit.ThreadUtils.join(ThreadUtils.java:110)
at
org.apache.geode.cache.query.dunit.QueryDataInconsistencyDUnitTest.testRangeIndex(QueryDataInconsistencyDUnitTest.java:304){code}
Seems like a flakey test.
> CI failure:
> org.apache.geode.cache.query.dunit.QueryDataInconsistencyDUnitTest.
> testRangeIndex
> --
>
> Key: GEODE-6278
> URL: https://issues.apache.org/jira/browse/GEODE-6278
> Project: Geode
> Issue Type: Bug
> Components: querying
>Reporter: Aditya Anchuri
>Priority: Major
>
> {code:java}
> org.apache.geode.cache.query.dunit.QueryDataInconsistencyDUnitTest >
> testRangeIndex FAILED
>
> java.lang.AssertionError: Thread did not terminate after 200 ms: Thread[run
> invoked on an instance of
> org.apache.geode.cache.query.dunit.QueryDataInconsistencyDUnitTest$6,5,]
>
> at org.junit.Assert.fail(Assert.java:88)
>
> at org.apache.geode.test.dunit.ThreadUtils.join(ThreadUtils.java:147)
>
> at org.apache.geode.test.dunit.ThreadUtils.join(ThreadUtils.java:110)
>
> at
> org.apache.geode.cache.query.dunit.QueryDataInconsistencyDUnitTest.testRangeIndex(QueryDataInconsistencyDUnitTest.java:304){code}
> Seems like a flakey test.
> http://concourse.gemfire.pivotal.io/teams/main/pipelines/gemfire-9.3/jobs/DistributedTest/builds/18
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5552) Flaky test ConnectCommandWithSSLTest > connectWithJmxSSL
[
https://issues.apache.org/jira/browse/GEODE-5552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16743340#comment-16743340
]
Ryan McMahon commented on GEODE-5552:
-
Failed in:
http://concourse.gemfire.pivotal.io/teams/main/pipelines/gemfire-9.6/jobs/DistributedTest/builds/40
> Flaky test ConnectCommandWithSSLTest > connectWithJmxSSL
>
>
> Key: GEODE-5552
> URL: https://issues.apache.org/jira/browse/GEODE-5552
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.8.0
>Reporter: Jacob S. Barrett
>Assignee: Kenneth Howe
>Priority: Major
> Labels: flaky, swat
>
> {noformat}
> > Task :geode-web:distributedTest
> org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest >
> connectWithJmxSSL FAILED
> java.lang.AssertionError:
> Expecting:
> <"_ __
>/ _/ __/ __/ // /
> / / __/ /___ /_ / _ /
> / /__/ / / _/ / // /
> /__/_/ /__/_//_/1.8.0-SNAPSHOT
>
> Monitor and Manage Apache Geode
> Connecting to Locator at [host=localhost, port=42647] ..
> Connection reset
> ">
> to contain:
> <"trying to connect a non-SSL-enabled client to an SSL-enabled locator">
> at
> org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest.connectWithJmxSSL(ConnectCommandWithSSLTest.java:219)
> {noformat}
> Failing:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/pr-develop/jobs/DistributedTest/builds/521
> Passing:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/pr-develop/jobs/DistributedTest/builds/522
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-6267) Subjects are not logged out when a client departs causing a memory leak
[
https://issues.apache.org/jira/browse/GEODE-6267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16743377#comment-16743377
]
Barry Oglesby commented on GEODE-6267:
--
Here are some histograms.
Startup:
{noformat}
num #instances #bytes class name
--
1: 66767 8069280 [C
2: 4565 5288072 [B
3: 36908 2952640 java.util.zip.ZipEntry
4: 66702 1600848 java.lang.String
5: 7002 789552 java.lang.Class
6: 5084 567984 [Ljava.lang.Object;
7: 5153 453464 java.lang.reflect.Method
8: 656 388464 [J
9: 11897 380704 java.util.concurrent.ConcurrentHashMap$Node
10: 3954 336880 [Ljava.util.HashMap$Node;
11: 8124 324960 java.util.LinkedHashMap$Entry
12: 10121 323872 java.util.HashMap$Node
13: 4751 198016 [I
14: 10665 170640 java.lang.Object
15: 2131 170480 java.lang.reflect.Constructor
16: 2749 153944 java.util.LinkedHashMap
17: 1619 116568 java.lang.reflect.Field
18: 5503 115384 [Ljava.lang.Class;
19: 2202 105696 java.util.HashMap
20: 118 94864 [Ljava.util.concurrent.ConcurrentHashMap$Node;
21: 2096 80416 [Ljava.lang.String;
22: 1871 74840 java.lang.ref.Finalizer
23: 1175 65800 java.lang.Class$ReflectionData
24: 1409 56360 java.lang.ref.SoftReference
25: 607 53160 [Ljava.lang.reflect.Method;
Total 186115 9987688
{noformat}
After connecting and disconnecting a client 1 times:
{noformat}
num #instances #bytes class name
--
1: 229739 15010256 [C
2: 92139 7398488 [Ljava.util.HashMap$Node;
3: 229634 5511216 java.lang.String
4: 61726 3456656 java.util.LinkedHashMap
5: 97956 3134592 java.util.HashMap$Node
6: 64120 2564800 java.util.LinkedHashMap$Entry
7: 35955 2125344 [Ljava.lang.Object;
8: 61804 1977728 java.util.concurrent.ConcurrentHashMap$Node
9: 30485 1954128 [Ljava.util.Hashtable$Entry;
10: 60493 1935776 java.util.Hashtable$Entry
11: 11601 1597640 [B
12: 31760 1524480 java.util.HashMap
13: 30072 1443456 java.util.Properties
14: 3 144 org.apache.shiro.session.mgt.SimpleSession
15: 7477 841096 java.lang.Class
16: 30464 731136 java.util.ArrayList
17: 30009 720216 java.util.Date
18: 10003 720216 org.apache.geode.distributed.internal.membership.gms.GMSMember
19: 3 72 TestPrincipal
20: 3 72 org.apache.shiro.subject.SimplePrincipalCollection
21: 122 485904 [Ljava.util.concurrent.ConcurrentHashMap$Node;
22: 10003 480144
org.apache.geode.distributed.internal.membership.InternalDistributedMember
23: 30007 480112 java.util.LinkedHashSet
24: 732 405536 [J
25: 20815 333040 java.lang.Object
Total 1403107 61797808
{noformat}
After connecting and disconnecting a client enough times to create ~182k
SimpleSessions:
{noformat}
num #instances #bytes class name
--
1: 1252634 78052152 [C
2: 552473 44224760 [Ljava.util.HashMap$Node;
3: 1252511 30060264 java.lang.String
4: 368616 20642496 java.util.LinkedHashMap
5: 558197 17862304 java.util.HashMap$Node
6: 371010 14840400 java.util.LinkedHashMap$Entry
7: 183930 11774608 [Ljava.util.Hashtable$Entry;
8: 367383 11756256 java.util.Hashtable$Entry
9: 189397 10719072 [Ljava.lang.Object;
10: 317462 10158784 java.util.concurrent.ConcurrentHashMap$Node
11: 185203 8889744 java.util.HashMap
12: 183517 8808816 java.util.Properties
13: 183445 8805360 org.apache.shiro.session.mgt.SimpleSession
14: 62707 7321352 [B
15: 183909 4413816 java.util.ArrayList
16: 183454 4402896 java.util.Date
17: 183445 4402680 TestPrincipal
18: 183445 4402680 org.apache.shiro.subject.SimplePrincipalCollection
19: 61108 4399776
org.apache.geode.distributed.internal.membership.gms.GMSMember
20: 183452 2935232 java.util.LinkedHashSet
Total 7692368 330322672
{noformat}
> Subjects are not logged out when a client departs causing a memory leak
> ---
>
> Key: GEODE-6267
> URL: https://issues.apache.org/jira/browse/GEODE-6267
> Project: Geode
> Issue Type: Bug
> Components: security
>Reporter: Barry Oglesby
>Assignee: Barry Oglesby
>Priority: Major
>
> When a client with security enabled connects to a server, the
> IntegratedSecurityService logs in a Subject. This causes a SimpleSession to
> be created.
> The Subject is stored in ClientUserAuths.uniqueIdVsSubject.
> Here is a stack showing the SimpleSession creation:
> {noformat}
> [warning 2019/01/08 18:02:42.993 PST server1 Thread 0> tid=0x4e] SimpleSession. invoked:
> java.lang.Exception
> at org.apache.shiro.session.mgt.SimpleSession.(SimpleSession.java:99)
> at
> org.apache.shiro.session.mgt.SimpleSessionFactory.createSession(SimpleSessionFactory.java:44)
> at
> org.apache.shiro.session.mgt.DefaultSessionManager.newSessionInstance(DefaultSessionManager.java:163)
> at
> org.apache.shiro.session.mgt.Def
[jira] [Commented] (GEODE-6267) Subjects are not logged out when a client departs causing a memory leak
[
https://issues.apache.org/jira/browse/GEODE-6267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16743380#comment-16743380
]
Barry Oglesby commented on GEODE-6267:
--
After adding code to logout the Subjects in ClientUserAuths and
CacheClientProxy:
{noformat}
num #instances #bytes class name
--
1: 79717 7093992 [C
2: 79610 1910640 java.lang.String
3: 11596 1599472 [B
4: 31794 1017408 java.util.concurrent.ConcurrentHashMap$Node
5: 7477 841096 java.lang.Class
6: 9998 719856 org.apache.geode.distributed.internal.membership.gms.GMSMember
7: 9998 479904
org.apache.geode.distributed.internal.membership.InternalDistributedMember
8: 5956 445384 [Ljava.lang.Object;
9: 753 408176 [J
10: 20810 332960 java.lang.Object
11: 10022 320704 java.net.InetAddress$InetAddressHolder
12: 9989 319648 org.apache.geode.distributed.DurableClientAttributes
13: 9988 319616
org.apache.geode.internal.cache.tier.sockets.ClientProxyMembershipID
14: 2980 262240 java.lang.reflect.Method
15: 7956 254592 java.util.HashMap$Node
16: 10221 245304 java.lang.Long
17: 10017 240408 java.net.Inet4Address
18: 122 223824 [Ljava.util.concurrent.ConcurrentHashMap$Node;
19: 4881 208488 [I
20: 11264 202016 [Ljava.lang.String;
21: 2139 198488 [Ljava.util.HashMap$Node;
22: 2119 169520 java.lang.reflect.Constructor
23: 4120 164800 java.util.LinkedHashMap$Entry
24: 1726 96656 java.util.LinkedHashMap
25: 1760 84480 java.util.HashMap
Total 391292 19641912
{noformat}
There is still a leak here in I think ClientProxyMembershipIDs. I'll take a
look at that.
> Subjects are not logged out when a client departs causing a memory leak
> ---
>
> Key: GEODE-6267
> URL: https://issues.apache.org/jira/browse/GEODE-6267
> Project: Geode
> Issue Type: Bug
> Components: security
>Reporter: Barry Oglesby
>Assignee: Barry Oglesby
>Priority: Major
>
> When a client with security enabled connects to a server, the
> IntegratedSecurityService logs in a Subject. This causes a SimpleSession to
> be created.
> The Subject is stored in ClientUserAuths.uniqueIdVsSubject.
> Here is a stack showing the SimpleSession creation:
> {noformat}
> [warning 2019/01/08 18:02:42.993 PST server1 Thread 0> tid=0x4e] SimpleSession. invoked:
> java.lang.Exception
> at org.apache.shiro.session.mgt.SimpleSession.(SimpleSession.java:99)
> at
> org.apache.shiro.session.mgt.SimpleSessionFactory.createSession(SimpleSessionFactory.java:44)
> at
> org.apache.shiro.session.mgt.DefaultSessionManager.newSessionInstance(DefaultSessionManager.java:163)
> at
> org.apache.shiro.session.mgt.DefaultSessionManager.doCreateSession(DefaultSessionManager.java:154)
> at
> org.apache.shiro.session.mgt.AbstractValidatingSessionManager.createSession(AbstractValidatingSessionManager.java:136)
> at
> org.apache.shiro.session.mgt.AbstractNativeSessionManager.start(AbstractNativeSessionManager.java:99)
> at
> org.apache.shiro.mgt.SessionsSecurityManager.start(SessionsSecurityManager.java:152)
> at
> org.apache.shiro.subject.support.DelegatingSubject.getSession(DelegatingSubject.java:336)
> at
> org.apache.shiro.subject.support.DelegatingSubject.getSession(DelegatingSubject.java:312)
> at
> org.apache.shiro.mgt.DefaultSubjectDAO.mergePrincipals(DefaultSubjectDAO.java:204)
> at
> org.apache.shiro.mgt.DefaultSubjectDAO.saveToSession(DefaultSubjectDAO.java:166)
> at org.apache.shiro.mgt.DefaultSubjectDAO.save(DefaultSubjectDAO.java:147)
> at
> org.apache.shiro.mgt.DefaultSecurityManager.save(DefaultSecurityManager.java:383)
> at
> org.apache.shiro.mgt.DefaultSecurityManager.createSubject(DefaultSecurityManager.java:350)
> at
> org.apache.shiro.mgt.DefaultSecurityManager.createSubject(DefaultSecurityManager.java:183)
> at
> org.apache.shiro.mgt.DefaultSecurityManager.login(DefaultSecurityManager.java:283)
> at
> org.apache.shiro.subject.support.DelegatingSubject.login(DelegatingSubject.java:256)
> at
> org.apache.geode.internal.security.IntegratedSecurityService.login(IntegratedSecurityService.java:139)
> at
> org.apache.geode.internal.cache.tier.sockets.HandShake.verifyCredentials(HandShake.java:1688)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.setCredentials(ServerConnection.java:1044)
> at
> org.apache.geode.internal.cache.tier.sockets.command.PutUserCredentials.cmdExecute(PutUserCredentials.java:52)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:163)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMsg(ServerConnection.java:797)
> at
> org.apache.geode.internal.cache.tier.sockets.LegacyServerConnection.doOneMessage(LegacyServerConnection.java:85)
> at
> org.apache.ge
[jira] [Comment Edited] (GEODE-6267) Subjects are not logged out when a client departs causing a memory leak
[
https://issues.apache.org/jira/browse/GEODE-6267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16743383#comment-16743383
]
Barry Oglesby edited comment on GEODE-6267 at 1/15/19 8:41 PM:
---
Here is a concise list of instances and memory used:
Startup:
Total 186115 9987688
After 1 clients:
Total 1403107 61797808
After subject logout:
Total 391292 19641912
was (Author: barry.oglesby):
Here is a concise list of instances:
Startup:
Total 186115 9987688
After 1 clients:
Total 1403107 61797808
After subject logout:
Total 391292 19641912
> Subjects are not logged out when a client departs causing a memory leak
> ---
>
> Key: GEODE-6267
> URL: https://issues.apache.org/jira/browse/GEODE-6267
> Project: Geode
> Issue Type: Bug
> Components: security
>Reporter: Barry Oglesby
>Assignee: Barry Oglesby
>Priority: Major
>
> When a client with security enabled connects to a server, the
> IntegratedSecurityService logs in a Subject. This causes a SimpleSession to
> be created.
> The Subject is stored in ClientUserAuths.uniqueIdVsSubject.
> Here is a stack showing the SimpleSession creation:
> {noformat}
> [warning 2019/01/08 18:02:42.993 PST server1 Thread 0> tid=0x4e] SimpleSession. invoked:
> java.lang.Exception
> at org.apache.shiro.session.mgt.SimpleSession.(SimpleSession.java:99)
> at
> org.apache.shiro.session.mgt.SimpleSessionFactory.createSession(SimpleSessionFactory.java:44)
> at
> org.apache.shiro.session.mgt.DefaultSessionManager.newSessionInstance(DefaultSessionManager.java:163)
> at
> org.apache.shiro.session.mgt.DefaultSessionManager.doCreateSession(DefaultSessionManager.java:154)
> at
> org.apache.shiro.session.mgt.AbstractValidatingSessionManager.createSession(AbstractValidatingSessionManager.java:136)
> at
> org.apache.shiro.session.mgt.AbstractNativeSessionManager.start(AbstractNativeSessionManager.java:99)
> at
> org.apache.shiro.mgt.SessionsSecurityManager.start(SessionsSecurityManager.java:152)
> at
> org.apache.shiro.subject.support.DelegatingSubject.getSession(DelegatingSubject.java:336)
> at
> org.apache.shiro.subject.support.DelegatingSubject.getSession(DelegatingSubject.java:312)
> at
> org.apache.shiro.mgt.DefaultSubjectDAO.mergePrincipals(DefaultSubjectDAO.java:204)
> at
> org.apache.shiro.mgt.DefaultSubjectDAO.saveToSession(DefaultSubjectDAO.java:166)
> at org.apache.shiro.mgt.DefaultSubjectDAO.save(DefaultSubjectDAO.java:147)
> at
> org.apache.shiro.mgt.DefaultSecurityManager.save(DefaultSecurityManager.java:383)
> at
> org.apache.shiro.mgt.DefaultSecurityManager.createSubject(DefaultSecurityManager.java:350)
> at
> org.apache.shiro.mgt.DefaultSecurityManager.createSubject(DefaultSecurityManager.java:183)
> at
> org.apache.shiro.mgt.DefaultSecurityManager.login(DefaultSecurityManager.java:283)
> at
> org.apache.shiro.subject.support.DelegatingSubject.login(DelegatingSubject.java:256)
> at
> org.apache.geode.internal.security.IntegratedSecurityService.login(IntegratedSecurityService.java:139)
> at
> org.apache.geode.internal.cache.tier.sockets.HandShake.verifyCredentials(HandShake.java:1688)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.setCredentials(ServerConnection.java:1044)
> at
> org.apache.geode.internal.cache.tier.sockets.command.PutUserCredentials.cmdExecute(PutUserCredentials.java:52)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:163)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMsg(ServerConnection.java:797)
> at
> org.apache.geode.internal.cache.tier.sockets.LegacyServerConnection.doOneMessage(LegacyServerConnection.java:85)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1179)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl$4$1.run(AcceptorImpl.java:641)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> When the client disconnects, the ClientUserAuths is cleaned up (in cleanup),
> but the Subjects are not logged out.
> With subscription-enabled=true, an additional Subject is created and stored
> in the CacheClientProxy subject. This Subject is not logged out either.
> Here is a stack showing the SimpleSession creation:
> {noformat}
> [warning 2019/01/08 18:02:43.023 PST server1 Thread 0> tid=0x52] SimpleSession. invoked:
> java.lang.Exception
> at org.apache.shiro.session.mgt.SimpleSession.(SimpleSession.java:99)
> at
> org.apache.shiro.session.mgt.SimpleSessionFactory.createSession(Sim
[jira] [Commented] (GEODE-6267) Subjects are not logged out when a client departs causing a memory leak
[
https://issues.apache.org/jira/browse/GEODE-6267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16743383#comment-16743383
]
Barry Oglesby commented on GEODE-6267:
--
Here is a concise list of instances:
Startup:
Total 186115 9987688
After 1 clients:
Total 1403107 61797808
After subject logout:
Total 391292 19641912
> Subjects are not logged out when a client departs causing a memory leak
> ---
>
> Key: GEODE-6267
> URL: https://issues.apache.org/jira/browse/GEODE-6267
> Project: Geode
> Issue Type: Bug
> Components: security
>Reporter: Barry Oglesby
>Assignee: Barry Oglesby
>Priority: Major
>
> When a client with security enabled connects to a server, the
> IntegratedSecurityService logs in a Subject. This causes a SimpleSession to
> be created.
> The Subject is stored in ClientUserAuths.uniqueIdVsSubject.
> Here is a stack showing the SimpleSession creation:
> {noformat}
> [warning 2019/01/08 18:02:42.993 PST server1 Thread 0> tid=0x4e] SimpleSession. invoked:
> java.lang.Exception
> at org.apache.shiro.session.mgt.SimpleSession.(SimpleSession.java:99)
> at
> org.apache.shiro.session.mgt.SimpleSessionFactory.createSession(SimpleSessionFactory.java:44)
> at
> org.apache.shiro.session.mgt.DefaultSessionManager.newSessionInstance(DefaultSessionManager.java:163)
> at
> org.apache.shiro.session.mgt.DefaultSessionManager.doCreateSession(DefaultSessionManager.java:154)
> at
> org.apache.shiro.session.mgt.AbstractValidatingSessionManager.createSession(AbstractValidatingSessionManager.java:136)
> at
> org.apache.shiro.session.mgt.AbstractNativeSessionManager.start(AbstractNativeSessionManager.java:99)
> at
> org.apache.shiro.mgt.SessionsSecurityManager.start(SessionsSecurityManager.java:152)
> at
> org.apache.shiro.subject.support.DelegatingSubject.getSession(DelegatingSubject.java:336)
> at
> org.apache.shiro.subject.support.DelegatingSubject.getSession(DelegatingSubject.java:312)
> at
> org.apache.shiro.mgt.DefaultSubjectDAO.mergePrincipals(DefaultSubjectDAO.java:204)
> at
> org.apache.shiro.mgt.DefaultSubjectDAO.saveToSession(DefaultSubjectDAO.java:166)
> at org.apache.shiro.mgt.DefaultSubjectDAO.save(DefaultSubjectDAO.java:147)
> at
> org.apache.shiro.mgt.DefaultSecurityManager.save(DefaultSecurityManager.java:383)
> at
> org.apache.shiro.mgt.DefaultSecurityManager.createSubject(DefaultSecurityManager.java:350)
> at
> org.apache.shiro.mgt.DefaultSecurityManager.createSubject(DefaultSecurityManager.java:183)
> at
> org.apache.shiro.mgt.DefaultSecurityManager.login(DefaultSecurityManager.java:283)
> at
> org.apache.shiro.subject.support.DelegatingSubject.login(DelegatingSubject.java:256)
> at
> org.apache.geode.internal.security.IntegratedSecurityService.login(IntegratedSecurityService.java:139)
> at
> org.apache.geode.internal.cache.tier.sockets.HandShake.verifyCredentials(HandShake.java:1688)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.setCredentials(ServerConnection.java:1044)
> at
> org.apache.geode.internal.cache.tier.sockets.command.PutUserCredentials.cmdExecute(PutUserCredentials.java:52)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:163)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMsg(ServerConnection.java:797)
> at
> org.apache.geode.internal.cache.tier.sockets.LegacyServerConnection.doOneMessage(LegacyServerConnection.java:85)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1179)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl$4$1.run(AcceptorImpl.java:641)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> When the client disconnects, the ClientUserAuths is cleaned up (in cleanup),
> but the Subjects are not logged out.
> With subscription-enabled=true, an additional Subject is created and stored
> in the CacheClientProxy subject. This Subject is not logged out either.
> Here is a stack showing the SimpleSession creation:
> {noformat}
> [warning 2019/01/08 18:02:43.023 PST server1 Thread 0> tid=0x52] SimpleSession. invoked:
> java.lang.Exception
> at org.apache.shiro.session.mgt.SimpleSession.(SimpleSession.java:99)
> at
> org.apache.shiro.session.mgt.SimpleSessionFactory.createSession(SimpleSessionFactory.java:44)
> at
> org.apache.shiro.session.mgt.DefaultSessionManager.newSessionInstance(DefaultSessionManager.java:163)
> at
> org.apache.shiro.session.mgt.DefaultSessionManager.doCreateSession(DefaultSessionManager.java:154)
> at
> or
[jira] [Commented] (GEODE-6267) Subjects are not logged out when a client departs causing a memory leak
[
https://issues.apache.org/jira/browse/GEODE-6267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16743391#comment-16743391
]
Barry Oglesby commented on GEODE-6267:
--
I found something else while debugging this leak.
If the ClentHealthMonitor unregisters the CacheClientProxy, most of
closeTransientFields is short-circuited. This is the normal code path.
In this code path, terminateDispatching calls closeSocket before calling
closeTransientFields. In the finally block, closeTransientFields is called.
{noformat}
java.lang.Exception: Stack trace
at java.lang.Thread.dumpStack(Thread.java:1333)
at
org.apache.geode.internal.cache.tier.sockets.CacheClientProxy.closeTransientFields(CacheClientProxy.java:965)
at
org.apache.geode.internal.cache.tier.sockets.CacheClientProxy.terminateDispatching(CacheClientProxy.java:945)
at
org.apache.geode.internal.cache.tier.sockets.CacheClientProxy.close(CacheClientProxy.java:794)
at
org.apache.geode.internal.cache.tier.sockets.CacheClientNotifier.closeDeadProxies(CacheClientNotifier.java:1712)
at
org.apache.geode.internal.cache.tier.sockets.CacheClientNotifier.unregisterClient(CacheClientNotifier.java:724)
at
org.apache.geode.internal.cache.tier.sockets.ClientHealthMonitor.unregisterClient(ClientHealthMonitor.java:270)
at
org.apache.geode.internal.cache.tier.sockets.ServerConnection.handleTermination(ServerConnection.java:958)
at
org.apache.geode.internal.cache.tier.sockets.ServerConnection.handleTermination(ServerConnection.java:878)
at
org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1229)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at
org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:613)
at
org.apache.geode.internal.logging.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:121)
{noformat}
Since closeSocket has already been called interminateDispatching,
closeTransientFields short-circuits the rest of the method:
{noformat}
if (!closeSocket()) {
// The thread who closed the socket will be responsible to
// releaseResourcesForAddress and clearClientInterestList
return;
}
{noformat}
This means that these methods aren't called:
{noformat}
releaseCommBuffer
releaseResourcesForAddress
{noformat}
I addressed this issue in my changes as well.
> Subjects are not logged out when a client departs causing a memory leak
> ---
>
> Key: GEODE-6267
> URL: https://issues.apache.org/jira/browse/GEODE-6267
> Project: Geode
> Issue Type: Bug
> Components: security
>Reporter: Barry Oglesby
>Assignee: Barry Oglesby
>Priority: Major
>
> When a client with security enabled connects to a server, the
> IntegratedSecurityService logs in a Subject. This causes a SimpleSession to
> be created.
> The Subject is stored in ClientUserAuths.uniqueIdVsSubject.
> Here is a stack showing the SimpleSession creation:
> {noformat}
> [warning 2019/01/08 18:02:42.993 PST server1 Thread 0> tid=0x4e] SimpleSession. invoked:
> java.lang.Exception
> at org.apache.shiro.session.mgt.SimpleSession.(SimpleSession.java:99)
> at
> org.apache.shiro.session.mgt.SimpleSessionFactory.createSession(SimpleSessionFactory.java:44)
> at
> org.apache.shiro.session.mgt.DefaultSessionManager.newSessionInstance(DefaultSessionManager.java:163)
> at
> org.apache.shiro.session.mgt.DefaultSessionManager.doCreateSession(DefaultSessionManager.java:154)
> at
> org.apache.shiro.session.mgt.AbstractValidatingSessionManager.createSession(AbstractValidatingSessionManager.java:136)
> at
> org.apache.shiro.session.mgt.AbstractNativeSessionManager.start(AbstractNativeSessionManager.java:99)
> at
> org.apache.shiro.mgt.SessionsSecurityManager.start(SessionsSecurityManager.java:152)
> at
> org.apache.shiro.subject.support.DelegatingSubject.getSession(DelegatingSubject.java:336)
> at
> org.apache.shiro.subject.support.DelegatingSubject.getSession(DelegatingSubject.java:312)
> at
> org.apache.shiro.mgt.DefaultSubjectDAO.mergePrincipals(DefaultSubjectDAO.java:204)
> at
> org.apache.shiro.mgt.DefaultSubjectDAO.saveToSession(DefaultSubjectDAO.java:166)
> at org.apache.shiro.mgt.DefaultSubjectDAO.save(DefaultSubjectDAO.java:147)
> at
> org.apache.shiro.mgt.DefaultSecurityManager.save(DefaultSecurityManager.java:383)
> at
> org.apache.shiro.mgt.DefaultSecurityManager.createSubject(DefaultSecurityManager.java:350)
> at
> org.apache.shiro.mgt.DefaultSecurityManager.createSubject(DefaultSecurityManager.java:183)
> at
> org.apache.shiro.mgt.DefaultSecurityManager.login(DefaultSecurityManager.java:283)
>
[jira] [Assigned] (GEODE-6279) CI: PR Test results URI is valid but unintentionally mangled. Many scripts reproduce effort.
[
https://issues.apache.org/jira/browse/GEODE-6279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg reassigned GEODE-6279:
---
Assignee: Patrick Rhomberg
> CI: PR Test results URI is valid but unintentionally mangled. Many scripts
> reproduce effort.
> -
>
> Key: GEODE-6279
> URL: https://issues.apache.org/jira/browse/GEODE-6279
> Project: Geode
> Issue Type: Improvement
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
>
> For instance, the test run
> [here|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-pr/jobs/UpgradeTestOpenJDK8/builds/704]
> contains the following output in the {{archive_results}} step:
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-{"pr":"3032","commit":"a9a03f033e90b39aceab07b56919e6a4fef1e43d","committed":"2019-01-10T20:13:25Z"}/test-results/upgradeTest/1547153318/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> {noformat}
> This is a consequence of the diff-set for GEODE-6259 using the concourse
> version as the (Concourse) source of truth for versioning and expecting the
> version file to only contain the version string.
> Another underlying issue is that many of these scripts are (a) used in both
> the main pipeline as well as the PR pipeline and (b) nearly-but-imperfectly
> duplicate a great deal fo work between each script. These common tasks
> should be unified to a shared utilities that can be accessed by any of our
> scripts so that these pitfalls do not snare future developers.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-6279) CI: PR Test results URI is valid but unintentionally mangled. Many scripts reproduce effort.
Patrick Rhomberg created GEODE-6279:
---
Summary: CI: PR Test results URI is valid but unintentionally
mangled. Many scripts reproduce effort.
Key: GEODE-6279
URL: https://issues.apache.org/jira/browse/GEODE-6279
Project: Geode
Issue Type: Improvement
Reporter: Patrick Rhomberg
For instance, the test run
[here|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-pr/jobs/UpgradeTestOpenJDK8/builds/704]
contains the following output in the {{archive_results}} step:
{noformat}
=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-{"pr":"3032","commit":"a9a03f033e90b39aceab07b56919e6a4fef1e43d","committed":"2019-01-10T20:13:25Z"}/test-results/upgradeTest/1547153318/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
{noformat}
This is a consequence of the diff-set for GEODE-6259 using the concourse
version as the (Concourse) source of truth for versioning and expecting the
version file to only contain the version string.
Another underlying issue is that many of these scripts are (a) used in both the
main pipeline as well as the PR pipeline and (b) nearly-but-imperfectly
duplicate a great deal fo work between each script. These common tasks should
be unified to a shared utilities that can be accessed by any of our scripts so
that these pitfalls do not snare future developers.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-6280) Create new public module for the Management API
Jens Deppe created GEODE-6280: - Summary: Create new public module for the Management API Key: GEODE-6280 URL: https://issues.apache.org/jira/browse/GEODE-6280 Project: Geode Issue Type: New Feature Components: configuration Reporter: Jens Deppe We will need a new public module for the Management API. This separate module, once compiled, will produce a jar that developers can download (via Maven or otherwise) to access the Management API. Thus it is required that any dependencies we have that are currently "internal" need to be moved into this public module. h3. Acceptance Criteria *Given* I am a java developer *and* configured my `build.gradle` to pull down the Geode Management API module *When* I do a gradlew build *Then* I can write a java application that uses components inside this module *and* the module is self contained and does not have other geode dependencies. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6268) initializeUniquePortRange_willReturnUniquePortsForUniqueRanges seems flaky on Windows
[ https://issues.apache.org/jira/browse/GEODE-6268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16743451#comment-16743451 ] Ryan McMahon commented on GEODE-6268: - Failed in: https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsIntegrationTestOpenJDK8/builds/221 > initializeUniquePortRange_willReturnUniquePortsForUniqueRanges seems flaky on > Windows > - > > Key: GEODE-6268 > URL: https://issues.apache.org/jira/browse/GEODE-6268 > Project: Geode > Issue Type: Bug > Components: ci >Reporter: Sean Goller >Assignee: Kenneth Howe >Priority: Major > > org.apache.geode.internal.AvailablePortHelperIntegrationTest.initializeUniquePortRange_willReturnUniquePortsForUniqueRanges > periodically fails on windows. It seems like there's some flakiness being > introduced that may be platform specfic. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-6281) RegionHelper.generateCacheXml should not include entry values in the generated xml
[ https://issues.apache.org/jira/browse/GEODE-6281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao reassigned GEODE-6281: -- Assignee: Jinmei Liao > RegionHelper.generateCacheXml should not include entry values in the > generated xml > -- > > Key: GEODE-6281 > URL: https://issues.apache.org/jira/browse/GEODE-6281 > Project: Geode > Issue Type: Bug > Components: configuration >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > > If the cache holds lots of data, this would leads to OOME. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6281) RegionHelper.generateCacheXml should not include entry values in the generated xml
Jinmei Liao created GEODE-6281: -- Summary: RegionHelper.generateCacheXml should not include entry values in the generated xml Key: GEODE-6281 URL: https://issues.apache.org/jira/browse/GEODE-6281 Project: Geode Issue Type: Bug Components: configuration Reporter: Jinmei Liao If the cache holds lots of data, this would leads to OOME. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-6278) CI failure: org.apache.geode.cache.query.dunit.QueryDataInconsistencyDUnitTest. testRangeIndex
[
https://issues.apache.org/jira/browse/GEODE-6278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McMahon reassigned GEODE-6278:
---
Assignee: Jason Huynh
> CI failure:
> org.apache.geode.cache.query.dunit.QueryDataInconsistencyDUnitTest.
> testRangeIndex
> --
>
> Key: GEODE-6278
> URL: https://issues.apache.org/jira/browse/GEODE-6278
> Project: Geode
> Issue Type: Bug
> Components: querying
>Reporter: Aditya Anchuri
>Assignee: Jason Huynh
>Priority: Major
>
> {code:java}
> org.apache.geode.cache.query.dunit.QueryDataInconsistencyDUnitTest >
> testRangeIndex FAILED
>
> java.lang.AssertionError: Thread did not terminate after 200 ms: Thread[run
> invoked on an instance of
> org.apache.geode.cache.query.dunit.QueryDataInconsistencyDUnitTest$6,5,]
>
> at org.junit.Assert.fail(Assert.java:88)
>
> at org.apache.geode.test.dunit.ThreadUtils.join(ThreadUtils.java:147)
>
> at org.apache.geode.test.dunit.ThreadUtils.join(ThreadUtils.java:110)
>
> at
> org.apache.geode.cache.query.dunit.QueryDataInconsistencyDUnitTest.testRangeIndex(QueryDataInconsistencyDUnitTest.java:304){code}
> Seems like a flakey test.
> http://concourse.gemfire.pivotal.io/teams/main/pipelines/gemfire-9.3/jobs/DistributedTest/builds/18
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-6281) RegionHelper.generateCacheXml should not include entry values in the generated xml
[ https://issues.apache.org/jira/browse/GEODE-6281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-6281: -- Labels: pull-request-available (was: ) > RegionHelper.generateCacheXml should not include entry values in the > generated xml > -- > > Key: GEODE-6281 > URL: https://issues.apache.org/jira/browse/GEODE-6281 > Project: Geode > Issue Type: Bug > Components: configuration >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: pull-request-available > > If the cache holds lots of data, this would leads to OOME. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (GEODE-5370) DistributedTest task on CI occasionally exceeds timeout
[ https://issues.apache.org/jira/browse/GEODE-5370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon reopened GEODE-5370: - This appears to still be happening. See the below runs: https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/282 https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/297 > DistributedTest task on CI occasionally exceeds timeout > --- > > Key: GEODE-5370 > URL: https://issues.apache.org/jira/browse/GEODE-5370 > Project: Geode > Issue Type: Bug >Reporter: Alexander Murmann >Assignee: Jinmei Liao >Priority: Major > Labels: ci, concourse, flaky, swat > > Occasionally the CI job fails because it exceeds the 8 hour timeout. The job > usually takes ~3 hours, so this is definitely outside the expected variation. > See the following runs: > [https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/88] > [https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/79] > [https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/77] > [https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/71] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6282) CI Failure: WindowsGfshDistributedTestOpenJDK11.connectWithSSL
Ryan McMahon created GEODE-6282:
---
Summary: CI Failure:
WindowsGfshDistributedTestOpenJDK11.connectWithSSL
Key: GEODE-6282
URL: https://issues.apache.org/jira/browse/GEODE-6282
Project: Geode
Issue Type: Bug
Reporter: Ryan McMahon
{code:java}
org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest >
connectWithSSL 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 1233
[error 2019/01/15 20:17:38.966 GMT tid=63]
Jmx manager could not be started because HTTP service failed to start
org.apache.geode.management.ManagementException: HTTP service failed to start
at
org.apache.geode.management.internal.ManagementAgent.startHttpService(ManagementAgent.java:349)
at
org.apache.geode.management.internal.ManagementAgent.startAgent(ManagementAgent.java:159)
at
org.apache.geode.management.internal.SystemManagementService.startManager(SystemManagementService.java:432)
at
org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheCreation(ManagementAdapter.java:173)
at
org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:115)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2234)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:606)
at
org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1214)
at
org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:799)
at
org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:785)
at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:176)
at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:223)
at
org.apache.geode.distributed.internal.InternalLocator.startCache(InternalLocator.java:657)
at
org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:644)
at
org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:330)
at org.apache.geode.distributed.Locator.startLocator(Locator.java:252)
at org.apache.geode.distributed.Locator.startLocatorAndDS(Locator.java:139)
at
org.apache.geode.test.junit.rules.LocatorStarterRule.startLocator(LocatorStarterRule.java:85)
at
org.apache.geode.test.junit.rules.LocatorStarterRule.before(LocatorStarterRule.java:66)
at
org.apache.geode.test.dunit.rules.ClusterStartupRule.lambda$startLocatorVM$22d9b8a8$1(ClusterStartupRule.java:208)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
org.apache.geode.test.dunit.internal.MethodInvoker.executeObject(MethodInvoker.java:123)
at
org.apache.geode.test.dunit.internal.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:69)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at java.rmi/sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:359)
at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:200)
at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:197)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.rmi/sun.rmi.transport.Transport.serviceCall(Transport.java:196)
at
java.rmi/sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:562)
at
java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:796)
at
java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:677)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at
java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:676)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: java.net.BindException: Address already in use: bind
at java.base/sun.nio.ch.Net.bind0(Native Method)
at java.ba
[jira] [Comment Edited] (GEODE-5370) DistributedTest task on CI occasionally exceeds timeout
[ https://issues.apache.org/jira/browse/GEODE-5370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16743467#comment-16743467 ] Ryan McMahon edited comment on GEODE-5370 at 1/15/19 11:21 PM: --- This appears to still be happening. See the below run: [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/297] was (Author: rmcmahon): This appears to still be happening. See the below runs: https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/282 https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/297 > DistributedTest task on CI occasionally exceeds timeout > --- > > Key: GEODE-5370 > URL: https://issues.apache.org/jira/browse/GEODE-5370 > Project: Geode > Issue Type: Bug >Reporter: Alexander Murmann >Assignee: Jinmei Liao >Priority: Major > Labels: ci, concourse, flaky, swat > > Occasionally the CI job fails because it exceeds the 8 hour timeout. The job > usually takes ~3 hours, so this is definitely outside the expected variation. > See the following runs: > [https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/88] > [https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/79] > [https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/77] > [https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/71] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
