[jira] [Created] (GEODE-6926) BOMs constrain all our dependencies, including test-only dependencies
Patrick Rhomberg created GEODE-6926:
---
Summary: BOMs constrain all our dependencies, including test-only
dependencies
Key: GEODE-6926
URL: https://issues.apache.org/jira/browse/GEODE-6926
Project: Geode
Issue Type: Improvement
Reporter: Patrick Rhomberg
Because we include every version for every dependency we consume in one place
(i.e. {{buildSrc/.../DependencyConstraints}}), and because we build our
{{geode-all-bom}} from this single versions store, we are publishing a BOM that
constrains more than it should.
For instance, a consumer of the {{geode-all-bom}} will have JUnit constrained
to version 4.12, which as a geode _product_ consumer is both unnecessary and
potentially breaking.
We need to audit our dependencies and identify those dependencies which do not
reach a consumer.
This ticket may be partially coupled with GEODE-6532, which audits product
dependencies to distinguish _our_ compile/runtime dependencies from a
_consumer's_ transitive compile and runtime dependencies.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-6814) Concourse: I cannot test Geode locally due to GCP rsync patterns.
[
https://issues.apache.org/jira/browse/GEODE-6814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg updated GEODE-6814:
Summary: Concourse: I cannot test Geode locally due to GCP rsync patterns.
(was: I cannot test Geode locally due to GCP rsync patterns.)
> Concourse: I cannot test Geode locally due to GCP rsync patterns.
> -
>
> Key: GEODE-6814
> URL: https://issues.apache.org/jira/browse/GEODE-6814
> Project: Geode
> Issue Type: Improvement
>Reporter: Patrick Rhomberg
>Priority: Major
>
> Our testing framework follows the pattern that Concourse creates test
> instances in GCP and handles artifact migration between the Concourse worker
> and the GCP VMs.
> As a developer, particularly one interested in our testing framework, I may
> wish to locally test a checkout of Geode, and in particular test changes made
> to our pipeline. This is currently blocked by (a) the {{deploy_pipeline.sh}}
> script only being viable when run within the {{meta-*}} pipeline within
> concourse, and (b) scripts presume this GCP test VM pattern.
> The {{deploy_pipeline.sh}} script should be able to be configured easily to
> target, for instance, a {{localhost}} target, so that I may do local
> iteration on the Geode pipeline.
> As future work belonging to another ticket, this pipeline should be able to
> run locally without spinning up GCP instances.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-6814) I cannot test Geode locally due to GCP rsync patterns.
Patrick Rhomberg created GEODE-6814:
---
Summary: I cannot test Geode locally due to GCP rsync patterns.
Key: GEODE-6814
URL: https://issues.apache.org/jira/browse/GEODE-6814
Project: Geode
Issue Type: Improvement
Reporter: Patrick Rhomberg
Our testing framework follows the pattern that Concourse creates test instances
in GCP and handles artifact migration between the Concourse worker and the GCP
VMs.
As a developer, particularly one interested in our testing framework, I may
wish to locally test a checkout of Geode, and in particular test changes made
to our pipeline. This is currently blocked by (a) the {{deploy_pipeline.sh}}
script only being viable when run within the {{meta-*}} pipeline within
concourse, and (b) scripts presume this GCP test VM pattern.
The {{deploy_pipeline.sh}} script should be able to be configured easily to
target, for instance, a {{localhost}} target, so that I may do local iteration
on the Geode pipeline.
As future work belonging to another ticket, this pipeline should be able to run
locally without spinning up GCP instances.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-6813) Concourse: Jinja templating surrounding publication is inconsistent
Patrick Rhomberg created GEODE-6813:
---
Summary: Concourse: Jinja templating surrounding publication is
inconsistent
Key: GEODE-6813
URL: https://issues.apache.org/jira/browse/GEODE-6813
Project: Geode
Issue Type: Improvement
Reporter: Patrick Rhomberg
There is an inconsistency when deciding whether or not to include publication
jobs in a fork-facing Concourse deployment. Currently, some tasks require
{{fork == apache and branch == develop}}, where some require {{fork == apache
or branch == develop}}.
For consistency, these should all be {{or}} checks.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-6813) Concourse: Jinja templating surrounding publication is inconsistent
[
https://issues.apache.org/jira/browse/GEODE-6813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg reassigned GEODE-6813:
---
Assignee: Robert Houghton
> Concourse: Jinja templating surrounding publication is inconsistent
> ---
>
> Key: GEODE-6813
> URL: https://issues.apache.org/jira/browse/GEODE-6813
> Project: Geode
> Issue Type: Improvement
>Reporter: Patrick Rhomberg
>Assignee: Robert Houghton
>Priority: Major
>
> There is an inconsistency when deciding whether or not to include publication
> jobs in a fork-facing Concourse deployment. Currently, some tasks require
> {{fork == apache and branch == develop}}, where some require {{fork == apache
> or branch == develop}}.
> For consistency, these should all be {{or}} checks.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-6752) CI: A passing build ID, in addition to PassingRef, would be useful
[ https://issues.apache.org/jira/browse/GEODE-6752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg resolved GEODE-6752. - Resolution: Fixed > CI: A passing build ID, in addition to PassingRef, would be useful > -- > > Key: GEODE-6752 > URL: https://issues.apache.org/jira/browse/GEODE-6752 > Project: Geode > Issue Type: Improvement >Reporter: Patrick Rhomberg >Assignee: Patrick Rhomberg >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > During development, it is useful to have the build ID rather than just the > SHA of a passing build, for investigating differences between the CI passing > build's artifacts against a local build at the same SHA. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-6752) CI: A passing build ID, in addition to PassingRef, would be useful
[ https://issues.apache.org/jira/browse/GEODE-6752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg reassigned GEODE-6752: --- Assignee: Patrick Rhomberg > CI: A passing build ID, in addition to PassingRef, would be useful > -- > > Key: GEODE-6752 > URL: https://issues.apache.org/jira/browse/GEODE-6752 > Project: Geode > Issue Type: Improvement >Reporter: Patrick Rhomberg >Assignee: Patrick Rhomberg >Priority: Major > > During development, it is useful to have the build ID rather than just the > SHA of a passing build, for investigating differences between the CI passing > build's artifacts against a local build at the same SHA. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6752) CI: A passing build ID, in addition to PassingRef, would be useful
Patrick Rhomberg created GEODE-6752: --- Summary: CI: A passing build ID, in addition to PassingRef, would be useful Key: GEODE-6752 URL: https://issues.apache.org/jira/browse/GEODE-6752 Project: Geode Issue Type: Improvement Reporter: Patrick Rhomberg During development, it is useful to have the build ID rather than just the SHA of a passing build, for investigating differences between the CI passing build's artifacts against a local build at the same SHA. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6383) Build scripting should not violate modularity.
[
https://issues.apache.org/jira/browse/GEODE-6383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg resolved GEODE-6383.
-
Resolution: Fixed
> Build scripting should not violate modularity.
> --
>
> Key: GEODE-6383
> URL: https://issues.apache.org/jira/browse/GEODE-6383
> Project: Geode
> Issue Type: Improvement
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> In many portions of our build scripting, we use the invasive,
> modularity-breaking pattern of
> {noformat}
> subprojects {
> configureSomething
> }
> {noformat}
> This is particularly problematic when certain plugins or built-ins do not
> integrate well with each other, e.g, Gradle 5.2's {{java-platform}} needing
> to be applied before the {{java}} plugin.
> As a result, within a single subproject, it is very difficult to know
> (without prior experience) how the subproject is configured.
> This ticket is intended to be a "parent" ticket for jobs that fall into the
> following categories:
> * Converting a plugin-script in {{gradle/}} to a class extending
> {{Plugin}}.
> * Moving a plugin to belong to {{buildSrc}}
> * Converting invasive {{subproject [configuration]}} calls to be "opt-in" by
> the subprojects that require the configuration, such as the work done in
> GEODE-6237.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-6611) Subprojects should be audited with respect to which plugins ought be applied
[
https://issues.apache.org/jira/browse/GEODE-6611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg updated GEODE-6611:
Summary: Subprojects should be audited with respect to which plugins ought
be applied (was: Subprojects should be audited with respect to which plugins
aught be applied)
> Subprojects should be audited with respect to which plugins ought be applied
>
>
> Key: GEODE-6611
> URL: https://issues.apache.org/jira/browse/GEODE-6611
> Project: Geode
> Issue Type: Improvement
>Reporter: Patrick Rhomberg
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Previously, every Gradle subproject was aggressively configured via blocks
> like
> {noformat}
> subprojets {
> apply plugin: 'java'
> ...
> }
> {noformat}
> As the code base expanded, we have introduced many subprojects who do not
> warrant a "standard" configuration as a Java project. For instance, in
> GEODE-6569, a subproject responsible for producing Geode's BOM was also
> producing a trivial jar. This is the direct result of a configuration like
> the above.
> Modularity was restored by GEODE-6383 and such invasive configuration no
> longer exists. We will soon be positioned to remove from such subprojects
> those plugins that do not belong.
> Each subproject should be audited and only pull in the plugins necessary.
> This may resolve many tangental issues, particularly with publication, e.g.,
> the war subproject publishing jars not fit for (direct) consumption.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Reopened] (GEODE-6383) Build scripting should not violate modularity.
[
https://issues.apache.org/jira/browse/GEODE-6383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg reopened GEODE-6383:
-
Some minor missed issues. PR will be forthcoming immediately.
> Build scripting should not violate modularity.
> --
>
> Key: GEODE-6383
> URL: https://issues.apache.org/jira/browse/GEODE-6383
> Project: Geode
> Issue Type: Improvement
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In many portions of our build scripting, we use the invasive,
> modularity-breaking pattern of
> {noformat}
> subprojects {
> configureSomething
> }
> {noformat}
> This is particularly problematic when certain plugins or built-ins do not
> integrate well with each other, e.g, Gradle 5.2's {{java-platform}} needing
> to be applied before the {{java}} plugin.
> As a result, within a single subproject, it is very difficult to know
> (without prior experience) how the subproject is configured.
> This ticket is intended to be a "parent" ticket for jobs that fall into the
> following categories:
> * Converting a plugin-script in {{gradle/}} to a class extending
> {{Plugin}}.
> * Moving a plugin to belong to {{buildSrc}}
> * Converting invasive {{subproject [configuration]}} calls to be "opt-in" by
> the subprojects that require the configuration, such as the work done in
> GEODE-6237.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-6512) Remove test-by-category.gradle
[
https://issues.apache.org/jira/browse/GEODE-6512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg resolved GEODE-6512.
-
Resolution: Fixed
> Remove test-by-category.gradle
> --
>
> Key: GEODE-6512
> URL: https://issues.apache.org/jira/browse/GEODE-6512
> Project: Geode
> Issue Type: Improvement
>Reporter: Patrick Rhomberg
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> This configuration macro is at best a violation of clean design and at worst
> an attractive pitfall for developers.
> * The way configuration is injected into all subprojects violates each
> subproject's modularity.
> * A known issue with JUnit4's category filtering means that every test is
> instantiated, regardless of category, and those not matching the given
> category is run as a no-op. As a result, testing via category is very time
> intensive, even when running a trivial category with no tests in it. This is
> what drove the redesign of tests to use Nebula {{facets}} and separate source
> sets, rather than our previous categories of {{UnitTest}},
> {{IntegrationTest}}, et al.
> * Because each target extends the Test task type, it only scans the {{test}}
> source set. Developers may be mislead into thinking that all tests of the
> given category should be run under the given task.
> * Also because each task is of the Test task type, it inherits only the
> {{UnitTest}} default configuration. Even if the previous point were not
> true, we would expect many tests to fail due to invalid DUnit configuration.
> * In fact, each type only inherits the default configuration, and not our
> correct JUnit configuration. Tested locally with {{./gradlew securityTest}},
> I see several initialization failures that result from improper configuration.
> These categories are still useful to the developer for gathering tests within
> a given scope, e.g. {{SecurityTest}}, across our multiple testing facets, but
> as gradle targets, these are cruft that needs to be removed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-6383) Build scripting should not violate modularity.
[
https://issues.apache.org/jira/browse/GEODE-6383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg resolved GEODE-6383.
-
Resolution: Fixed
> Build scripting should not violate modularity.
> --
>
> Key: GEODE-6383
> URL: https://issues.apache.org/jira/browse/GEODE-6383
> Project: Geode
> Issue Type: Improvement
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In many portions of our build scripting, we use the invasive,
> modularity-breaking pattern of
> {noformat}
> subprojects {
> configureSomething
> }
> {noformat}
> This is particularly problematic when certain plugins or built-ins do not
> integrate well with each other, e.g, Gradle 5.2's {{java-platform}} needing
> to be applied before the {{java}} plugin.
> As a result, within a single subproject, it is very difficult to know
> (without prior experience) how the subproject is configured.
> This ticket is intended to be a "parent" ticket for jobs that fall into the
> following categories:
> * Converting a plugin-script in {{gradle/}} to a class extending
> {{Plugin}}.
> * Moving a plugin to belong to {{buildSrc}}
> * Converting invasive {{subproject [configuration]}} calls to be "opt-in" by
> the subprojects that require the configuration, such as the work done in
> GEODE-6237.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-6611) Subprojects should be audited with respect to which plugins aught be applied
Patrick Rhomberg created GEODE-6611:
---
Summary: Subprojects should be audited with respect to which
plugins aught be applied
Key: GEODE-6611
URL: https://issues.apache.org/jira/browse/GEODE-6611
Project: Geode
Issue Type: Improvement
Reporter: Patrick Rhomberg
Previously, every Gradle subproject was aggressively configured via blocks like
{noformat}
subprojets {
apply plugin: 'java'
...
}
{noformat}
As the code base expanded, we have introduced many subprojects who do not
warrant a "standard" configuration as a Java project. For instance, in
GEODE-6569, a subproject responsible for producing Geode's BOM was also
producing a trivial jar. This is the direct result of a configuration like the
above.
Modularity was restored by GEODE-6383 and such invasive configuration no longer
exists. We will soon be positioned to remove from such subprojects those
plugins that do not belong.
Each subproject should be audited and only pull in the plugins necessary. This
may resolve many tangental issues, particularly with publication, e.g., the war
subproject publishing jars not fit for (direct) consumption.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-6599) Subprojects should opt into our /gradle/*.gradle macros, not have it injected by root
[ https://issues.apache.org/jira/browse/GEODE-6599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg resolved GEODE-6599. - Resolution: Duplicate As pointed out in PR 3403, the provided PR really satisfies GEODE-6383 in its entire declared scope. I should not have opened this sub-task, as no additional subtasks to 6383 will be necessary. The referenced PR will be updated to refer to GEODE-6383. > Subprojects should opt into our /gradle/*.gradle macros, not have it > injected by root > --- > > Key: GEODE-6599 > URL: https://issues.apache.org/jira/browse/GEODE-6599 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Rhomberg >Assignee: Patrick Rhomberg >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > This ticket does not attempt to make any sense of whether or not these macros > should or should not be applied to any particular subproject, with such > evaluation being left to future work. > The scope of this ticket is only to have each subproject opt into its > configuration rather than have that configuration injected from outside the > project, and additionally resolve any issues with configuration and > evaluation order that were important but not explicitly declared by a given > subproject's configuration. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-6599) Subprojects should opt into our /gradle/*.gradle macros, not have it injected by root
[ https://issues.apache.org/jira/browse/GEODE-6599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg reassigned GEODE-6599: --- Assignee: Patrick Rhomberg > Subprojects should opt into our /gradle/*.gradle macros, not have it > injected by root > --- > > Key: GEODE-6599 > URL: https://issues.apache.org/jira/browse/GEODE-6599 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Rhomberg >Assignee: Patrick Rhomberg >Priority: Major > > This ticket does not attempt to make any sense of whether or not these macros > should or should not be applied to any particular subproject, with such > evaluation being left to future work. > The scope of this ticket is only to have each subproject opt into its > configuration rather than have that configuration injected from outside the > project, and additionally resolve any issues with configuration and > evaluation order that were important but not explicitly declared by a given > subproject's configuration. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6599) Subprojects should opt into our /gradle/*.gradle macros, not have it injected by root
Patrick Rhomberg created GEODE-6599: --- Summary: Subprojects should opt into our /gradle/*.gradle macros, not have it injected by root Key: GEODE-6599 URL: https://issues.apache.org/jira/browse/GEODE-6599 Project: Geode Issue Type: Sub-task Reporter: Patrick Rhomberg This ticket does not attempt to make any sense of whether or not these macros should or should not be applied to any particular subproject, with such evaluation being left to future work. The scope of this ticket is only to have each subproject opt into its configuration rather than have that configuration injected from outside the project, and additionally resolve any issues with configuration and evaluation order that were important but not explicitly declared by a given subproject's configuration. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-6383) Build scripting should not violate modularity.
[
https://issues.apache.org/jira/browse/GEODE-6383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg reassigned GEODE-6383:
---
Assignee: Patrick Rhomberg
> Build scripting should not violate modularity.
> --
>
> Key: GEODE-6383
> URL: https://issues.apache.org/jira/browse/GEODE-6383
> Project: Geode
> Issue Type: Improvement
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
>
> In many portions of our build scripting, we use the invasive,
> modularity-breaking pattern of
> {noformat}
> subprojects {
> configureSomething
> }
> {noformat}
> This is particularly problematic when certain plugins or built-ins do not
> integrate well with each other, e.g, Gradle 5.2's {{java-platform}} needing
> to be applied before the {{java}} plugin.
> As a result, within a single subproject, it is very difficult to know
> (without prior experience) how the subproject is configured.
> This ticket is intended to be a "parent" ticket for jobs that fall into the
> following categories:
> * Converting a plugin-script in {{gradle/}} to a class extending
> {{Plugin}}.
> * Moving a plugin to belong to {{buildSrc}}
> * Converting invasive {{subproject [configuration]}} calls to be "opt-in" by
> the subprojects that require the configuration, such as the work done in
> GEODE-6237.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-6323) Configuration in doFirst and doLast blocks are not valid for task configuration.
[
https://issues.apache.org/jira/browse/GEODE-6323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg resolved GEODE-6323.
-
Resolution: Fixed
> Configuration in doFirst and doLast blocks are not valid for task
> configuration.
>
>
> Key: GEODE-6323
> URL: https://issues.apache.org/jira/browse/GEODE-6323
> Project: Geode
> Issue Type: Bug
> Components: ci
>Reporter: Patrick Rhomberg
>Assignee: Robert Houghton
>Priority: Major
> Labels: pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> See
> https://guides.gradle.org/using-build-cache/#suggestions_for_authoring_your_build
> {{doFirst}} and {{doLast}} occur at execution, but the up-to-date state of
> the task is required at configuration-time. More importantly, these task
> actions are cacheable and can be returned incorrectly if the declared inputs
> to the task are unchanged. Notably for {{gfshDepsJar}} and {{depsJar}}, if
> the {{cp()}} changes, these changes will not be detected and a cached version
> of the manifest can be used rather than the new intended classpath.
> This is not an issue in the Concourse pipeline, since no cache exists, but it
> can be troublesome for a developer.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-6382) Remove dead code from build -- sanitizedName is now irrelevant
[ https://issues.apache.org/jira/browse/GEODE-6382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg resolved GEODE-6382. - Resolution: Fixed > Remove dead code from build -- sanitizedName is now irrelevant > --- > > Key: GEODE-6382 > URL: https://issues.apache.org/jira/browse/GEODE-6382 > Project: Geode > Issue Type: Improvement >Reporter: Patrick Rhomberg >Assignee: Patrick Rhomberg >Priority: Major > Labels: pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > > By Gradle5 compliance, project names must not contain a forward-slash. This > utility is now an unnecessarily-complicated fetch of the project name. It > should be removed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6395) Safeguard spotless custom rule bump
[
https://issues.apache.org/jira/browse/GEODE-6395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg resolved GEODE-6395.
-
Resolution: Fixed
> Safeguard spotless custom rule bump
> ---
>
> Key: GEODE-6395
> URL: https://issues.apache.org/jira/browse/GEODE-6395
> Project: Geode
> Issue Type: Improvement
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The Spotless method {{bumpThisNumberIfACustomStepChanges}} should have its
> input changed whenever a custom rule is changed or added. Failure to do so
> can cause spotless to not execute, or to throw an NPE in rare instances.
> Developers can easily overlook this however. As an alternative, we could
> pass the sha of the spotless file itself to this method, ensuring that any
> change to spotless will cause the spotless cache to invalidate itself.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-6400) Expose artifacts that are suitable for composite consumption.
[
https://issues.apache.org/jira/browse/GEODE-6400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg resolved GEODE-6400.
-
Resolution: Fixed
> Expose artifacts that are suitable for composite consumption.
> -
>
> Key: GEODE-6400
> URL: https://issues.apache.org/jira/browse/GEODE-6400
> Project: Geode
> Issue Type: Sub-task
>Reporter: Patrick Rhomberg
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Artifacts exposed to composite builds are defined in the legacy
> {{archives.artifacts}} publication style. However, this should / will / must
> not change what our actual publication artifacts (with respect to the
> {{maven-publish}} plugin).
> This is also an opportunity to streamline some of our more gnarly code in
> both {{geode-assembly}} and {{publish.gradle}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-6532) Convert compile dependencies to implementation/api dependencies
[
https://issues.apache.org/jira/browse/GEODE-6532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg reassigned GEODE-6532:
---
Assignee: Dan Smith
> Convert compile dependencies to implementation/api dependencies
> ---
>
> Key: GEODE-6532
> URL: https://issues.apache.org/jira/browse/GEODE-6532
> Project: Geode
> Issue Type: Improvement
> Components: build, docs
>Reporter: Patrick Rhomberg
>Assignee: Dan Smith
>Priority: Major
>
> The {{compile}} configuration has been deprecated for some time. {{api}}
> will behave similarly, whereas {{implementation}} will appear to be a
> {{runtime}} dependency to consumers.
> This will require examining our public API so that we may correctly declare
> which dependencies are {{api}}. When a PR is made, an email should be sent
> to the dev@ and/or user@ lists warning that those consuming internal APIs
> (against best practice) may experience breakages if their own dependencies
> are not properly declared. Similarly, a release note on this topic could be
> helpful to those upgrading.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-6532) Convert compile dependencies to implementation/api dependencies
Patrick Rhomberg created GEODE-6532:
---
Summary: Convert compile dependencies to implementation/api
dependencies
Key: GEODE-6532
URL: https://issues.apache.org/jira/browse/GEODE-6532
Project: Geode
Issue Type: Improvement
Components: build, docs
Reporter: Patrick Rhomberg
The {{compile}} configuration has been deprecated for some time. {{api}} will
behave similarly, whereas {{implementation}} will appear to be a {{runtime}}
dependency to consumers.
This will require examining our public API so that we may correctly declare
which dependencies are {{api}}. When a PR is made, an email should be sent to
the dev@ and/or user@ lists warning that those consuming internal APIs (against
best practice) may experience breakages if their own dependencies are not
properly declared. Similarly, a release note on this topic could be helpful to
those upgrading.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-6439) Bump jackson scala dependency version
[ https://issues.apache.org/jira/browse/GEODE-6439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg resolved GEODE-6439. - Resolution: Fixed > Bump jackson scala dependency version > - > > Key: GEODE-6439 > URL: https://issues.apache.org/jira/browse/GEODE-6439 > Project: Geode > Issue Type: Improvement >Reporter: Patrick Rhomberg >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-5604) Make Geode build Gradle-5.0 ready
[ https://issues.apache.org/jira/browse/GEODE-5604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg resolved GEODE-5604. - Resolution: Fixed > Make Geode build Gradle-5.0 ready > - > > Key: GEODE-5604 > URL: https://issues.apache.org/jira/browse/GEODE-5604 > Project: Geode > Issue Type: Improvement > Components: build >Reporter: Robert Houghton >Priority: Major > Labels: pull-request-available > Time Spent: 2h 20m > Remaining Estimate: 0h > > Gradle is giving warnings about unsupported or deprecated features from our > 3.xx days. Clean them up. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4267) PersistentRecoveryOrderOldConfigDUnitTest.testCrashDuringPreparePersistentId fails intermittently due to DistributedSystemDisconnectedException suspect string
[
https://issues.apache.org/jira/browse/GEODE-4267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16790795#comment-16790795
]
Patrick Rhomberg commented on GEODE-4267:
-
Failed again in a recent PR.
Run: https://concourse.apachegeode-ci.info/builds/45455
Results
:http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-3290/test-results/distributedTest/1552354297/
Artifacts:
http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-3290/test-artifacts/1552354297/distributedtestfiles-geode-pr-3290.tgz
> PersistentRecoveryOrderOldConfigDUnitTest.testCrashDuringPreparePersistentId
> fails intermittently due to DistributedSystemDisconnectedException suspect
> string
> --
>
> Key: GEODE-4267
> URL: https://issues.apache.org/jira/browse/GEODE-4267
> Project: Geode
> Issue Type: Bug
> Components: persistence, tests
>Reporter: Kirk Lund
>Assignee: Mark Hanson
>Priority: Minor
> Labels: Flaky
> Attachments: GEODE-4267-standard-output.txt,
> lynn-findfailures-11-26-2018-15-25-48-logs.tgz
>
>
> {noformat}
> org.apache.geode.internal.cache.persistence.PersistentRecoveryOrderOldConfigDUnitTest
> > testCrashDuringPreparePersistentId FAILED
> java.lang.RuntimeException:
> org.apache.geode.distributed.DistributedSystemDisconnectedException: This
> connection to a distributed system has been disconnected.
> Caused by:
> org.apache.geode.distributed.DistributedSystemDisconnectedException:
> This connection to a distributed system has been disconnected.
> 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 1443
> [error 2017/12/16 00:50:26.778 UTC
> tid=0x1b]
> org.apache.geode.distributed.DistributedSystemDisconnectedException: This
> connection to a distributed system has been disconnected.
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-6512) Remove test-by-category.gradle
[
https://issues.apache.org/jira/browse/GEODE-6512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg updated GEODE-6512:
Description:
This configuration macro is at best a violation of clean design and at worst an
attractive pitfall for developers.
* The way configuration is injected into all subprojects violates each
subproject's modularity.
* A known issue with JUnit4's category filtering means that every test is
instantiated, regardless of category, and those not matching the given category
is run as a no-op. As a result, testing via category is very time intensive,
even when running a trivial category with no tests in it. This is what drove
the redesign of tests to use Nebula {{facets}} and separate source sets, rather
than our previous categories of {{UnitTest}}, {{IntegrationTest}}, et al.
* Because each target extends the Test task type, it only scans the {{test}}
source set. Developers may be mislead into thinking that all tests of the
given category should be run under the given task.
* Also because each task is of the Test task type, it inherits only the
{{UnitTest}} default configuration. Even if the previous point were not true,
we would expect many tests to fail due to invalid DUnit configuration.
* In fact, each type only inherits the default configuration, and not our
correct JUnit configuration. Tested locally with {{./gradlew securityTest}}, I
see several initialization failures that result from improper configuration.
These categories are still useful to the developer for gathering tests within a
given scope, e.g. {{SecurityTest}}, across our multiple testing facets, but as
gradle targets, these are cruft that needs to be removed.
was:
This configuration macro is at best a violation clean design and at worst an
attractive pitfall for developers.
* The way configuration is injected into all subprojects violates each
subproject's modularity.
* A known issue with JUnit4's category filtering means that every test is
instantiated, regardless of category, and those not matching the given category
is run as a no-op. As a result, testing via category is very time intensive,
even when running a trivial category with no tests in it. This is what drove
the redesign of tests to use Nebula {{facets}} and separate source sets, rather
than our previous categories of {{UnitTest}}, {{IntegrationTest}}, et al.
* Because each target extends the Test task type, it only scans the {{test}}
source set. Developers may be mislead into thinking that all tests of the
given category should be run under the given task.
* Also because each task is of the Test task type, it inherits only the
{{UnitTest}} default configuration. Even if the previous point were not true,
we would expect many tests to fail due to invalid DUnit configuration.
* In fact, each type only inherits the default configuration, and not our
correct JUnit configuration. Tested locally with {{./gradlew securityTest}}, I
see several initialization failures that result from improper configuration.
These categories are still useful to the developer for gathering tests within a
given scope, e.g. {{SecurityTest}}, across our multiple testing facets, but as
gradle targets, these are cruft that needs to be removed.
> Remove test-by-category.gradle
> --
>
> Key: GEODE-6512
> URL: https://issues.apache.org/jira/browse/GEODE-6512
> Project: Geode
> Issue Type: Improvement
>Reporter: Patrick Rhomberg
>Priority: Major
>
> This configuration macro is at best a violation of clean design and at worst
> an attractive pitfall for developers.
> * The way configuration is injected into all subprojects violates each
> subproject's modularity.
> * A known issue with JUnit4's category filtering means that every test is
> instantiated, regardless of category, and those not matching the given
> category is run as a no-op. As a result, testing via category is very time
> intensive, even when running a trivial category with no tests in it. This is
> what drove the redesign of tests to use Nebula {{facets}} and separate source
> sets, rather than our previous categories of {{UnitTest}},
> {{IntegrationTest}}, et al.
> * Because each target extends the Test task type, it only scans the {{test}}
> source set. Developers may be mislead into thinking that all tests of the
> given category should be run under the given task.
> * Also because each task is of the Test task type, it inherits only the
> {{UnitTest}} default configuration. Even if the previous point were not
> true, we would expect many tests to fail due to invalid DUnit configuration.
> * In fact, each type only inherits the default configuration, and not our
> correct JUnit configuration. Tested locally with {{./gradlew securityTest}},
> I see several initializati
[jira] [Created] (GEODE-6512) Remove test-by-category.gradle
Patrick Rhomberg created GEODE-6512:
---
Summary: Remove test-by-category.gradle
Key: GEODE-6512
URL: https://issues.apache.org/jira/browse/GEODE-6512
Project: Geode
Issue Type: Improvement
Reporter: Patrick Rhomberg
This configuration macro is at best a violation clean design and at worst an
attractive pitfall for developers.
* The way configuration is injected into all subprojects violates each
subproject's modularity.
* A known issue with JUnit4's category filtering means that every test is
instantiated, regardless of category, and those not matching the given category
is run as a no-op. As a result, testing via category is very time intensive,
even when running a trivial category with no tests in it. This is what drove
the redesign of tests to use Nebula {{facets}} and separate source sets, rather
than our previous categories of {{UnitTest}}, {{IntegrationTest}}, et al.
* Because each target extends the Test task type, it only scans the {{test}}
source set. Developers may be mislead into thinking that all tests of the
given category should be run under the given task.
* Also because each task is of the Test task type, it inherits only the
{{UnitTest}} default configuration. Even if the previous point were not true,
we would expect many tests to fail due to invalid DUnit configuration.
* In fact, each type only inherits the default configuration, and not our
correct JUnit configuration. Tested locally with {{./gradlew securityTest}}, I
see several initialization failures that result from improper configuration.
These categories are still useful to the developer for gathering tests within a
given scope, e.g. {{SecurityTest}}, across our multiple testing facets, but as
gradle targets, these are cruft that needs to be removed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-6449) Build and BuildSrc should not rely S3 to resolve dependencies
[ https://issues.apache.org/jira/browse/GEODE-6449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg resolved GEODE-6449. - Resolution: Fixed > Build and BuildSrc should not rely S3 to resolve dependencies > - > > Key: GEODE-6449 > URL: https://issues.apache.org/jira/browse/GEODE-6449 > Project: Geode > Issue Type: Improvement >Reporter: Patrick Rhomberg >Priority: Major > Time Spent: 2h > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6483) Separate concerns of render.py
[
https://issues.apache.org/jira/browse/GEODE-6483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg resolved GEODE-6483.
-
Resolution: Fixed
> Separate concerns of render.py
> --
>
> Key: GEODE-6483
> URL: https://issues.apache.org/jira/browse/GEODE-6483
> Project: Geode
> Issue Type: Improvement
>Reporter: Patrick Rhomberg
>Priority: Major
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> Currently, the {{render.py}} script that handles interpolation of Jinja
> variables in our various pipelines has the additional concern of settings
> multiple pipeline variables hardcoded in the {{render.py}} script. Variables
> of this script should be contained only in referenced variable files, e.g.
> {{shared/jinja.variables.yml}}, and not hard-coded.
> Removing this hard-coded behavior will make the script more flexible in its
> use as a Jinja renderer as a whole, and make its behavior in the meta
> pipeline more obvious to a developer-reader.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-6493) Gradle: Do not configure tasks outside the configuration phase
Patrick Rhomberg created GEODE-6493:
---
Summary: Gradle: Do not configure tasks outside the configuration
phase
Key: GEODE-6493
URL: https://issues.apache.org/jira/browse/GEODE-6493
Project: Geode
Issue Type: Improvement
Reporter: Patrick Rhomberg
In multiple places, we configure tasks only when the task graph is ready, e.g.
viaÂ
{noformat}
gradle.taskGraph.whenReady( { graph ->
tasks.withType(Tar).each { tar ->
tar.compression = Compression.GZIP
tar.extension = 'tgz'
}
// ...
}
{noformat}
However, this presents the possibility that tasks configured as dependencies of
tasks configured this way will have inaccurate configuration themselves, as
they might consume artifacts whose configurations shift after the fact, e.g., a
Tar task configured above will report an extension {{.tar}} during
configuration as its task outputs, causing downstream tasks to fail at
execution time when that file does not exist.
In most cases, {{whenReady}} blocks should be changed to be validation checks
rather than actual configuration, raising an error when a particular task is
not configured as required.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-6399) Use java-platform to unify dependencyManagement in published artifacts
[
https://issues.apache.org/jira/browse/GEODE-6399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg resolved GEODE-6399.
-
Resolution: Fixed
> Use java-platform to unify dependencyManagement in published artifacts
> --
>
> Key: GEODE-6399
> URL: https://issues.apache.org/jira/browse/GEODE-6399
> Project: Geode
> Issue Type: Sub-task
>Reporter: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Requires GEODE-6398.
> Via {{java-platform}}, we can declare inter-subproject BOM dependencies that
> resolve at configuration time, allowing us to bump dependency versions
> without updating each of our ~30 {{expected-pom.xml}} files.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-6398) Upgrade Gradle to 5.2+
[
https://issues.apache.org/jira/browse/GEODE-6398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg resolved GEODE-6398.
-
Resolution: Fixed
> Upgrade Gradle to 5.2+
> --
>
> Key: GEODE-6398
> URL: https://issues.apache.org/jira/browse/GEODE-6398
> Project: Geode
> Issue Type: Sub-task
>Reporter: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> In Gradle 5.2, the {{java-platform}} plugin allows for a simple,
> gradle-native way to declare dependency constraints. Most importantly, this
> occurs at configuration time, alleviating issues surrounding our previous
> attempt to consume a single Geode BOM.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-6484) Cleanup Jinja YML variables
Patrick Rhomberg created GEODE-6484: --- Summary: Cleanup Jinja YML variables Key: GEODE-6484 URL: https://issues.apache.org/jira/browse/GEODE-6484 Project: Geode Issue Type: Improvement Reporter: Patrick Rhomberg We have a great deal of copy-paste in our Jinja YML variables. Most could be cleaned up via YML element merging, specifying a default and letting individual tests override the relevant fields, e.g., test name. See [YAML documentation|https://yaml.org/type/merge.html] for details on YAML merging. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6483) Separate concerns of render.py
Patrick Rhomberg created GEODE-6483:
---
Summary: Separate concerns of render.py
Key: GEODE-6483
URL: https://issues.apache.org/jira/browse/GEODE-6483
Project: Geode
Issue Type: Improvement
Reporter: Patrick Rhomberg
Currently, the {{render.py}} script that handles interpolation of Jinja
variables in our various pipelines has the additional concern of settings
multiple pipeline variables hardcoded in the {{render.py}} script. Variables
of this script should be contained only in referenced variable files, e.g.
{{shared/jinja.variables.yml}}, and not hard-coded.
Removing this hard-coded behavior will make the script more flexible in its use
as a Jinja renderer as a whole, and make its behavior in the meta pipeline more
obvious to a developer-reader.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-6302) checkPom only checks dependencies, but not other Pom sections
[
https://issues.apache.org/jira/browse/GEODE-6302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg resolved GEODE-6302.
-
Resolution: Fixed
> checkPom only checks dependencies, but not other Pom sections
> -
>
> Key: GEODE-6302
> URL: https://issues.apache.org/jira/browse/GEODE-6302
> Project: Geode
> Issue Type: Improvement
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Most notable, the {{dependencyManagement}} section can now change without the
> {{checkPom}} task failing.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-6314) CI: Build version should only be rolled, and should always be rolled, at the Build step
[ https://issues.apache.org/jira/browse/GEODE-6314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg resolved GEODE-6314. - Resolution: Fixed > CI: Build version should only be rolled, and should always be rolled, at the > Build step > --- > > Key: GEODE-6314 > URL: https://issues.apache.org/jira/browse/GEODE-6314 > Project: Geode > Issue Type: Bug > Components: ci >Reporter: Patrick Rhomberg >Assignee: Patrick Rhomberg >Priority: Major > Labels: pull-request-available > Time Spent: 40m > Remaining Estimate: 0h > > Currently, the build ID is bumped also at publish as well as Build, and Build > only bumps when it is successful. In its role as a single, meaningful > identifier, it should always be rolled at Build, and only there. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6460) geode-build-version does not automatically update with a new version
Patrick Rhomberg created GEODE-6460:
---
Summary: geode-build-version does not automatically update with a
new version
Key: GEODE-6460
URL: https://issues.apache.org/jira/browse/GEODE-6460
Project: Geode
Issue Type: Improvement
Reporter: Patrick Rhomberg
We have recently rolled from 1.9.0 to 1.10.0 for our {{develop}} version
semver. Updating the pipeline YML
{noformat}
- name: geode-build-version
type: semver
source:
bucket: ((version-bucket))
driver: gcs
initial_version: 1.10.0
json_key: ((!concourse-gcp-key))
key: ((pipeline-prefix))((geode-build-branch))/version
{noformat}
to reference a new version in {{initial_version}} in insufficient to update the
pipeline's semver, as this value is only used when the file referenced in
{{key: ((pipeline-prefix))((geode-build-branch))/version}} does not exist.
We need to examine either a more robust way to store these version files (e.g.,
not using the branch name so that we can guarantee that the file does not exist
when we update the version) and/or introduce a way to easily bump the version
that is stored in that file (e.g., through a manually-fired Concourse job.) My
personal preference would be for the former.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-6449) Build and BuildSrc should not rely S3 to resolve dependencies
Patrick Rhomberg created GEODE-6449: --- Summary: Build and BuildSrc should not rely S3 to resolve dependencies Key: GEODE-6449 URL: https://issues.apache.org/jira/browse/GEODE-6449 Project: Geode Issue Type: Improvement Reporter: Patrick Rhomberg -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-6436) CI Failure: RebalanceOperationDUnitTest. testRecoverRedundancyBalancing
[
https://issues.apache.org/jira/browse/GEODE-6436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg reassigned GEODE-6436:
---
Assignee: Dan Smith
> CI Failure: RebalanceOperationDUnitTest. testRecoverRedundancyBalancing
> ---
>
> Key: GEODE-6436
> URL: https://issues.apache.org/jira/browse/GEODE-6436
> Project: Geode
> Issue Type: Bug
>Reporter: Patrick Rhomberg
>Assignee: Dan Smith
>Priority: Major
>
> {noformat}
> org.apache.geode.internal.cache.control.RebalanceOperationDUnitTest >
> testRecoverRedundancyBalancing FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.control.RebalanceOperationDUnitTest$35.run in
> VM 1 running on Host b422b7fbcaf6 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:406)
> at
> org.apache.geode.internal.cache.control.RebalanceOperationDUnitTest.recoverRedundancyBalancing(RebalanceOperationDUnitTest.java:985)
> at
> org.apache.geode.internal.cache.control.RebalanceOperationDUnitTest.testRecoverRedundancyBalancing(RebalanceOperationDUnitTest.java:883)
> Caused by:
> java.lang.AssertionError: expected:<1> but was:<2>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at
> org.apache.geode.internal.cache.control.RebalanceOperationDUnitTest$35.run(RebalanceOperationDUnitTest.java:979){noformat}
> Find CI failure here:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/414
> Find test results here:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.9.0-SNAPSHOT.0458/test-results/distributedTest/1550643578/index.html
> Find artifacts here:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.9.0-SNAPSHOT.0458/test-artifacts/1550643578/distributedtestfiles-OpenJDK8-1.9.0-SNAPSHOT.0458.tgz
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-6439) Bump jackson scala dependency version
Patrick Rhomberg created GEODE-6439: --- Summary: Bump jackson scala dependency version Key: GEODE-6439 URL: https://issues.apache.org/jira/browse/GEODE-6439 Project: Geode Issue Type: Improvement Reporter: Patrick Rhomberg -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-6435) CI Failure: SerialGatewaySenderQueueDUnitTest.testCreateMaximumSenders assertion fails
[
https://issues.apache.org/jira/browse/GEODE-6435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg reassigned GEODE-6435:
---
Assignee: Barry Oglesby
> CI Failure: SerialGatewaySenderQueueDUnitTest.testCreateMaximumSenders
> assertion fails
> --
>
> Key: GEODE-6435
> URL: https://issues.apache.org/jira/browse/GEODE-6435
> Project: Geode
> Issue Type: Bug
>Reporter: Patrick Rhomberg
>Assignee: Barry Oglesby
>Priority: Major
>
> {noformat}
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderQueueDUnitTest
> > testCreateMaximumSenders FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderQueueDUnitTest$$Lambda$390/0x000840596840.run
> in VM 2 running on Host 2e6d9f20266c with 8 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:406)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderQueueDUnitTest.testCreateMaximumSenders(SerialGatewaySenderQueueDUnitTest.java:370)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Condition with lambda
> expression in org.apache.geode.internal.cache.wan.WANTestBase that uses long
> was not fulfilled within 300 seconds.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:145)
> at
> org.awaitility.core.CallableCondition.await(CallableCondition.java:79)
> at
> org.awaitility.core.CallableCondition.await(CallableCondition.java:27)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:902)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:860)
> at
> org.apache.geode.internal.cache.wan.WANTestBase.verifyListenerEvents(WANTestBase.java:3542)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderQueueDUnitTest.lambda$testCreateMaximumSenders$faf964a3$1(SerialGatewaySenderQueueDUnitTest.java:370)
> java.lang.AssertionError: An exception occurred during asynchronous
> invocation.
> Caused by:
> java.rmi.ConnectIOException: error during JRMP connection
> establishment; nested exception is:
> java.net.SocketTimeoutException: Read timed out
> Caused by:
> java.net.SocketTimeoutException: Read timed out
> {noformat}
> Â
> See pipeline failure here:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/413]
> Find test results here:
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.9.0-SNAPSHOT.0456/test-results/distributedTest/1550631451/]
> Find artifacts here:
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.9.0-SNAPSHOT.0456/test-artifacts/1550631451/distributedtestfiles-OpenJDK11-1.9.0-SNAPSHOT.0456.tgz]
> Â
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-6436) CI Failure: RebalanceOperationDUnitTest. testRecoverRedundancyBalancing
[
https://issues.apache.org/jira/browse/GEODE-6436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg reassigned GEODE-6436:
---
Assignee: Jinmei Liao
> CI Failure: RebalanceOperationDUnitTest. testRecoverRedundancyBalancing
> ---
>
> Key: GEODE-6436
> URL: https://issues.apache.org/jira/browse/GEODE-6436
> Project: Geode
> Issue Type: Bug
>Reporter: Patrick Rhomberg
>Assignee: Jinmei Liao
>Priority: Major
>
> {noformat}
> org.apache.geode.internal.cache.control.RebalanceOperationDUnitTest >
> testRecoverRedundancyBalancing FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.control.RebalanceOperationDUnitTest$35.run in
> VM 1 running on Host b422b7fbcaf6 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:406)
> at
> org.apache.geode.internal.cache.control.RebalanceOperationDUnitTest.recoverRedundancyBalancing(RebalanceOperationDUnitTest.java:985)
> at
> org.apache.geode.internal.cache.control.RebalanceOperationDUnitTest.testRecoverRedundancyBalancing(RebalanceOperationDUnitTest.java:883)
> Caused by:
> java.lang.AssertionError: expected:<1> but was:<2>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at
> org.apache.geode.internal.cache.control.RebalanceOperationDUnitTest$35.run(RebalanceOperationDUnitTest.java:979){noformat}
> Find CI failure here:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/414
> Find test results here:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.9.0-SNAPSHOT.0458/test-results/distributedTest/1550643578/index.html
> Find artifacts here:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.9.0-SNAPSHOT.0458/test-artifacts/1550643578/distributedtestfiles-OpenJDK8-1.9.0-SNAPSHOT.0458.tgz
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-6422) CI Failure: ConcurrencyRuleTest. repeatUntilValue fails with TimeoutException
[
https://issues.apache.org/jira/browse/GEODE-6422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16773272#comment-16773272
]
Patrick Rhomberg commented on GEODE-6422:
-
I just bumped into this, too, with the same stacktrace.
> CI Failure: ConcurrencyRuleTest. repeatUntilValue fails with TimeoutException
> -
>
> Key: GEODE-6422
> URL: https://issues.apache.org/jira/browse/GEODE-6422
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Benjamin P Ross
>Priority: Major
>
> Stack Trace:Â
> {noformat}
> org.apache.geode.test.junit.rules.ConcurrencyRuleTest >Â
> repeatUntilValue(EXECUTE_IN_PARALLEL)Â [0]Â FAILED
> java.lang.RuntimeException:Â java.util.concurrent.TimeoutException
> atÂ
> org.apache.geode.test.junit.rules.ConcurrencyRule$ProtectedErrorCollector.verify(ConcurrencyRule.java:489)
> atÂ
> org.apache.geode.test.junit.rules.ConcurrencyRule.executeInParallel(ConcurrencyRule.java:154)
> atÂ
> org.apache.geode.test.junit.rules.ConcurrencyRuleTest$Execution.lambda$static$1(ConcurrencyRuleTest.java:619)
> atÂ
> org.apache.geode.test.junit.rules.ConcurrencyRuleTest$Execution.execute(ConcurrencyRuleTest.java:629)
> atÂ
> org.apache.geode.test.junit.rules.ConcurrencyRuleTest.repeatUntilValue(ConcurrencyRuleTest.java:419)
> Caused by:
> java.util.concurrent.TimeoutException
> at java.util.concurrent.FutureTask.get(FutureTask.java:205)
> atÂ
> org.apache.geode.test.junit.rules.ConcurrencyRule.awaitFuture(ConcurrencyRule.java:227)
> atÂ
> org.apache.geode.test.junit.rules.ConcurrencyRule.awaitFutures(ConcurrencyRule.java:219)
> atÂ
> org.apache.geode.test.junit.rules.ConcurrencyRule.executeInParallel(ConcurrencyRule.java:153)
> ... 3 more
> {noformat}
> Artifacts can be downloaded:
> gs://files-gemfire-dev/builds/gemfire-develop-main/1.9.0-build.0427/test-artifacts/1550270829/windows-unittestfiles-OpenJDK8-1.9.0-build.0427.tgz
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5817) CI Failure: StopServerAcceptanceTest.canStopServerByNameWhenConnectedOverHttp
[
https://issues.apache.org/jira/browse/GEODE-5817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16773261#comment-16773261
]
Patrick Rhomberg commented on GEODE-5817:
-
See again in a similar test run:
{noformat}
org.apache.geode.management.internal.cli.commands.StopServerWithSecurityAcceptanceTest
> canStopServerAsClusterAdminOverHttp FAILED
org.junit.ComparisonFailure: expected:<[0]> but was:<[1]>
at
jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:125)
at
org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:125)
at
org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:133)
at
org.apache.geode.management.internal.cli.commands.StopServerWithSecurityAcceptanceTest.startCluster(StopServerWithSecurityAcceptanceTest.java:110)
at
org.apache.geode.management.internal.cli.commands.StopServerWithSecurityAcceptanceTest.canStopServerAsClusterAdminOverHttp(StopServerWithSecurityAcceptanceTest.java:65)
{noformat}
See
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/AcceptanceTestOpenJDK11/builds/409
Complete artifacts here:
http://files.apachegeode-ci.info/builds/apache-develop-main/1.9.0-SNAPSHOT.0458/test-artifacts/1550640242/acceptancetestfiles-OpenJDK11-1.9.0-SNAPSHOT.0458.tgz
> CI Failure: StopServerAcceptanceTest.canStopServerByNameWhenConnectedOverHttp
> -
>
> Key: GEODE-5817
> URL: https://issues.apache.org/jira/browse/GEODE-5817
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Brian Rowe
>Assignee: Kenneth Howe
>Priority: Major
> Labels: swat
> Fix For: 1.9.0
>
>
> This appears to be the same issue as GEODE-5601, however, this is still
> occurring even when the acceptanceTests are being run serially (or at least,
> run with the fix for 5601).
> Example failures:
> from
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/AcceptanceTest/builds/47
> {noformat}org.apache.geode.management.internal.cli.commands.StopServerAcceptanceTest
> > canStopServerByNameWhenConnectedOverHttp 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.GfshExecution.awaitTermination(GfshExecution.java:124)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:125)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:112)
> at
> org.apache.geode.management.internal.cli.commands.StopServerAcceptanceTest.startCluster(StopServerAcceptanceTest.java:32){noformat}
> from
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/AcceptanceTest/builds/53
> {noformat}org.apache.geode.management.internal.cli.shell.StatusServerExitCodeAcceptanceTest
> > classMethod 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.GfshExecution.awaitTermination(GfshExecution.java:124)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:125)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:133)
> at
> org.apache.geode.management.internal.cli.shell.StatusServerExitCodeAcceptanceTest.classSetup(StatusServerExitCodeAcceptanceTest.java:66){noformat}
> Looking at the logs for these failures, we see the following in standard
> error:
> {noformat}
> The Cache Server process terminated unexpectedly with exit status 1. Please
> refer to the log file in
> /tmp/junit5496177071859309076/member-controller/server-lock-better-iota for
> full details.
> Exception in thread "main" java.lang.RuntimeException: An IO error occurred
> whi
[jira] [Created] (GEODE-6437) CI Failure: ClusterConfigLocatorRestartDUnitTest.serverRestartsAfterLocatorReconnects has suspect strings
Patrick Rhomberg created GEODE-6437:
---
Summary: CI Failure:
ClusterConfigLocatorRestartDUnitTest.serverRestartsAfterLocatorReconnects has
suspect strings
Key: GEODE-6437
URL: https://issues.apache.org/jira/browse/GEODE-6437
Project: Geode
Issue Type: Bug
Reporter: Patrick Rhomberg
{noformat}
org.apache.geode.management.internal.configuration.ClusterConfigLocatorRestartDUnitTest
> serverRestartsAfterLocatorReconnects 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 2176
[fatal 2019/02/20 05:35:48.883 UTC
tid=143] Membership service failure: member unexpectedly shut down shared,
unordered connection
org.apache.geode.ForcedDisconnectException: member unexpectedly shut down
shared, unordered connection
at
org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.forceDisconnect(GMSMembershipManager.java:2552)
at
org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.forceDisconnect(GMSJoinLeave.java:1075)
at
org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.processRemoveRequest(GMSJoinLeave.java:668)
at
org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.processMessage(GMSJoinLeave.java:1878)
at
org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1320)
at
org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1258)
at org.jgroups.JChannel.invokeCallback(JChannel.java:816)
at org.jgroups.JChannel.up(JChannel.java:741)
at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1077)
at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:792)
at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:433)
at
org.apache.geode.distributed.internal.membership.gms.messenger.StatRecorder.up(StatRecorder.java:73)
at
org.apache.geode.distributed.internal.membership.gms.messenger.AddressManager.up(AddressManager.java:72)
at org.jgroups.protocols.TP.passMessageUp(TP.java:1658)
at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1876)
at org.jgroups.util.DirectExecutor.execute(DirectExecutor.java:10)
at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1789)
at org.jgroups.protocols.TP.receive(TP.java:1714)
at
org.apache.geode.distributed.internal.membership.gms.messenger.Transport.receive(Transport.java:152)
at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701)
at java.lang.Thread.run(Thread.java:748)
{noformat}
Find CI failure here:
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/414
Find test results here:
http://files.apachegeode-ci.info/builds/apache-develop-main/1.9.0-SNAPSHOT.0458/test-results/distributedTest/1550643578/index.html
Find artifacts here:
http://files.apachegeode-ci.info/builds/apache-develop-main/1.9.0-SNAPSHOT.0458/test-artifacts/1550643578/distributedtestfiles-OpenJDK8-1.9.0-SNAPSHOT.0458.tgz
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-6436) CI Failure: RebalanceOperationDUnitTest. testRecoverRedundancyBalancing
Patrick Rhomberg created GEODE-6436:
---
Summary: CI Failure: RebalanceOperationDUnitTest.
testRecoverRedundancyBalancing
Key: GEODE-6436
URL: https://issues.apache.org/jira/browse/GEODE-6436
Project: Geode
Issue Type: Bug
Reporter: Patrick Rhomberg
{noformat}
org.apache.geode.internal.cache.control.RebalanceOperationDUnitTest >
testRecoverRedundancyBalancing FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.internal.cache.control.RebalanceOperationDUnitTest$35.run in
VM 1 running on Host b422b7fbcaf6 with 4 VMs
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579)
at org.apache.geode.test.dunit.VM.invoke(VM.java:406)
at
org.apache.geode.internal.cache.control.RebalanceOperationDUnitTest.recoverRedundancyBalancing(RebalanceOperationDUnitTest.java:985)
at
org.apache.geode.internal.cache.control.RebalanceOperationDUnitTest.testRecoverRedundancyBalancing(RebalanceOperationDUnitTest.java:883)
Caused by:
java.lang.AssertionError: expected:<1> but was:<2>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:645)
at org.junit.Assert.assertEquals(Assert.java:631)
at
org.apache.geode.internal.cache.control.RebalanceOperationDUnitTest$35.run(RebalanceOperationDUnitTest.java:979){noformat}
Find CI failure here:
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/414
Find test results here:
http://files.apachegeode-ci.info/builds/apache-develop-main/1.9.0-SNAPSHOT.0458/test-results/distributedTest/1550643578/index.html
Find artifacts here:
http://files.apachegeode-ci.info/builds/apache-develop-main/1.9.0-SNAPSHOT.0458/test-artifacts/1550643578/distributedtestfiles-OpenJDK8-1.9.0-SNAPSHOT.0458.tgz
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-6435) CI Failure: SerialGatewaySenderQueueDUnitTest.testCreateMaximumSenders assertion fails
Patrick Rhomberg created GEODE-6435:
---
Summary: CI Failure:
SerialGatewaySenderQueueDUnitTest.testCreateMaximumSenders assertion fails
Key: GEODE-6435
URL: https://issues.apache.org/jira/browse/GEODE-6435
Project: Geode
Issue Type: Bug
Reporter: Patrick Rhomberg
{noformat}
org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderQueueDUnitTest >
testCreateMaximumSenders FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderQueueDUnitTest$$Lambda$390/0x000840596840.run
in VM 2 running on Host 2e6d9f20266c with 8 VMs
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579)
at org.apache.geode.test.dunit.VM.invoke(VM.java:406)
at
org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderQueueDUnitTest.testCreateMaximumSenders(SerialGatewaySenderQueueDUnitTest.java:370)
Caused by:
org.awaitility.core.ConditionTimeoutException: Condition with lambda
expression in org.apache.geode.internal.cache.wan.WANTestBase that uses long
was not fulfilled within 300 seconds.
at
org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:145)
at
org.awaitility.core.CallableCondition.await(CallableCondition.java:79)
at
org.awaitility.core.CallableCondition.await(CallableCondition.java:27)
at
org.awaitility.core.ConditionFactory.until(ConditionFactory.java:902)
at
org.awaitility.core.ConditionFactory.until(ConditionFactory.java:860)
at
org.apache.geode.internal.cache.wan.WANTestBase.verifyListenerEvents(WANTestBase.java:3542)
at
org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderQueueDUnitTest.lambda$testCreateMaximumSenders$faf964a3$1(SerialGatewaySenderQueueDUnitTest.java:370)
java.lang.AssertionError: An exception occurred during asynchronous
invocation.
Caused by:
java.rmi.ConnectIOException: error during JRMP connection
establishment; nested exception is:
java.net.SocketTimeoutException: Read timed out
Caused by:
java.net.SocketTimeoutException: Read timed out
{noformat}
Â
See pipeline failure here:
[https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/413]
Find test results here:
[http://files.apachegeode-ci.info/builds/apache-develop-main/1.9.0-SNAPSHOT.0456/test-results/distributedTest/1550631451/]
Find artifacts here:
[http://files.apachegeode-ci.info/builds/apache-develop-main/1.9.0-SNAPSHOT.0456/test-artifacts/1550631451/distributedtestfiles-OpenJDK11-1.9.0-SNAPSHOT.0456.tgz]
Â
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-6427) CI Hang: ConcurrentSerialGatewaySenderOperationsOffHeapDUnitTest.testStopOneSerialGatewaySenderBothPrimary hangs in WANTestBase.createCache
[
https://issues.apache.org/jira/browse/GEODE-6427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg reassigned GEODE-6427:
---
Assignee: Jason Huynh (was: Patrick Rhomberg)
> CI Hang:
> ConcurrentSerialGatewaySenderOperationsOffHeapDUnitTest.testStopOneSerialGatewaySenderBothPrimary
> hangs in WANTestBase.createCache
> ---
>
> Key: GEODE-6427
> URL: https://issues.apache.org/jira/browse/GEODE-6427
> Project: Geode
> Issue Type: Bug
>Reporter: Patrick Rhomberg
>Assignee: Jason Huynh
>Priority: Major
>
> Failure in WindowsIntegrationTestOpenJDK8:
> https://concourse.gemfire-ci.info/teams/main/pipelines/gemfire-develop-main/jobs/DistributedTestOpenJDK11/builds/315
> Test artifacts available here (use {{gsutil cp}}):
> gs://files-gemfire-dev/builds/gemfire-develop-main/1.9.0-build.0413/test-artifacts/1549509280/distributedtestfiles-OpenJDK11-1.9.0-build.0413.tgz
> Â
> Relevant callstacks:
> {noformat}
> "Test worker" #27 prio=5 os_prio=0 cpu=2696.54ms elapsed=6226.69s
> tid=0x7f6f889d4800 nid=0x1b runnable [0x7f6f568b7000]
>java.lang.Thread.State: RUNNABLE
> at java.net.SocketInputStream.socketRead0(java.base@11.0.2/Native
> Method)
> at
> java.net.SocketInputStream.socketRead(java.base@11.0.2/SocketInputStream.java:115)
> at
> java.net.SocketInputStream.read(java.base@11.0.2/SocketInputStream.java:168)
> at
> java.net.SocketInputStream.read(java.base@11.0.2/SocketInputStream.java:140)
> at
> java.io.BufferedInputStream.fill(java.base@11.0.2/BufferedInputStream.java:252)
> at
> java.io.BufferedInputStream.read(java.base@11.0.2/BufferedInputStream.java:271)
> - locked <0xd0b7efc8> (a java.io.BufferedInputStream)
> at
> java.io.DataInputStream.readByte(java.base@11.0.2/DataInputStream.java:270)
> at
> sun.rmi.transport.StreamRemoteCall.executeCall(java.rmi@11.0.2/StreamRemoteCall.java:222)
> at
> sun.rmi.server.UnicastRef.invoke(java.rmi@11.0.2/UnicastRef.java:161)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(java.rmi@11.0.2/RemoteObjectInvocationHandler.java:209)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invoke(java.rmi@11.0.2/RemoteObjectInvocationHandler.java:161)
> at com.sun.proxy.$Proxy38.executeMethodOnObject(Unknown Source)
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:554)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:384)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDUnitTest.createSenderCaches(SerialGatewaySenderOperationsDUnitTest.java:122)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDUnitTest.testStopOneSerialGatewaySenderBothPrimary(SerialGatewaySenderOperationsDUnitTest.java:356)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@11.0.2/Native
> Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@11.0.2/NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@11.0.2/DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(java.base@11.0.2/Method.java:566)
> 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.ru
[jira] [Assigned] (GEODE-6427) CI Hang: ConcurrentSerialGatewaySenderOperationsOffHeapDUnitTest.testStopOneSerialGatewaySenderBothPrimary hangs in WANTestBase.createCache
[
https://issues.apache.org/jira/browse/GEODE-6427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg reassigned GEODE-6427:
---
Assignee: Patrick Rhomberg
> CI Hang:
> ConcurrentSerialGatewaySenderOperationsOffHeapDUnitTest.testStopOneSerialGatewaySenderBothPrimary
> hangs in WANTestBase.createCache
> ---
>
> Key: GEODE-6427
> URL: https://issues.apache.org/jira/browse/GEODE-6427
> Project: Geode
> Issue Type: Bug
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
>
> Failure in WindowsIntegrationTestOpenJDK8:
> https://concourse.gemfire-ci.info/teams/main/pipelines/gemfire-develop-main/jobs/DistributedTestOpenJDK11/builds/315
> Test artifacts available here (use {{gsutil cp}}):
> gs://files-gemfire-dev/builds/gemfire-develop-main/1.9.0-build.0413/test-artifacts/1549509280/distributedtestfiles-OpenJDK11-1.9.0-build.0413.tgz
> Â
> Relevant callstacks:
> {noformat}
> "Test worker" #27 prio=5 os_prio=0 cpu=2696.54ms elapsed=6226.69s
> tid=0x7f6f889d4800 nid=0x1b runnable [0x7f6f568b7000]
>java.lang.Thread.State: RUNNABLE
> at java.net.SocketInputStream.socketRead0(java.base@11.0.2/Native
> Method)
> at
> java.net.SocketInputStream.socketRead(java.base@11.0.2/SocketInputStream.java:115)
> at
> java.net.SocketInputStream.read(java.base@11.0.2/SocketInputStream.java:168)
> at
> java.net.SocketInputStream.read(java.base@11.0.2/SocketInputStream.java:140)
> at
> java.io.BufferedInputStream.fill(java.base@11.0.2/BufferedInputStream.java:252)
> at
> java.io.BufferedInputStream.read(java.base@11.0.2/BufferedInputStream.java:271)
> - locked <0xd0b7efc8> (a java.io.BufferedInputStream)
> at
> java.io.DataInputStream.readByte(java.base@11.0.2/DataInputStream.java:270)
> at
> sun.rmi.transport.StreamRemoteCall.executeCall(java.rmi@11.0.2/StreamRemoteCall.java:222)
> at
> sun.rmi.server.UnicastRef.invoke(java.rmi@11.0.2/UnicastRef.java:161)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(java.rmi@11.0.2/RemoteObjectInvocationHandler.java:209)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invoke(java.rmi@11.0.2/RemoteObjectInvocationHandler.java:161)
> at com.sun.proxy.$Proxy38.executeMethodOnObject(Unknown Source)
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:554)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:384)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDUnitTest.createSenderCaches(SerialGatewaySenderOperationsDUnitTest.java:122)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDUnitTest.testStopOneSerialGatewaySenderBothPrimary(SerialGatewaySenderOperationsDUnitTest.java:356)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@11.0.2/Native
> Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@11.0.2/NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@11.0.2/DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(java.base@11.0.2/Method.java:566)
> 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.statement
[jira] [Created] (GEODE-6427) CI Hang: ConcurrentSerialGatewaySenderOperationsOffHeapDUnitTest.testStopOneSerialGatewaySenderBothPrimary hangs in WANTestBase.createCache
Patrick Rhomberg created GEODE-6427:
---
Summary: CI Hang:
ConcurrentSerialGatewaySenderOperationsOffHeapDUnitTest.testStopOneSerialGatewaySenderBothPrimary
hangs in WANTestBase.createCache
Key: GEODE-6427
URL: https://issues.apache.org/jira/browse/GEODE-6427
Project: Geode
Issue Type: Bug
Reporter: Patrick Rhomberg
Failure in WindowsIntegrationTestOpenJDK8:
https://concourse.gemfire-ci.info/teams/main/pipelines/gemfire-develop-main/jobs/DistributedTestOpenJDK11/builds/315
Test artifacts available here (use {{gsutil cp}}):
gs://files-gemfire-dev/builds/gemfire-develop-main/1.9.0-build.0413/test-artifacts/1549509280/distributedtestfiles-OpenJDK11-1.9.0-build.0413.tgz
Â
Relevant callstacks:
{noformat}
"Test worker" #27 prio=5 os_prio=0 cpu=2696.54ms elapsed=6226.69s
tid=0x7f6f889d4800 nid=0x1b runnable [0x7f6f568b7000]
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(java.base@11.0.2/Native
Method)
at
java.net.SocketInputStream.socketRead(java.base@11.0.2/SocketInputStream.java:115)
at
java.net.SocketInputStream.read(java.base@11.0.2/SocketInputStream.java:168)
at
java.net.SocketInputStream.read(java.base@11.0.2/SocketInputStream.java:140)
at
java.io.BufferedInputStream.fill(java.base@11.0.2/BufferedInputStream.java:252)
at
java.io.BufferedInputStream.read(java.base@11.0.2/BufferedInputStream.java:271)
- locked <0xd0b7efc8> (a java.io.BufferedInputStream)
at
java.io.DataInputStream.readByte(java.base@11.0.2/DataInputStream.java:270)
at
sun.rmi.transport.StreamRemoteCall.executeCall(java.rmi@11.0.2/StreamRemoteCall.java:222)
at sun.rmi.server.UnicastRef.invoke(java.rmi@11.0.2/UnicastRef.java:161)
at
java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(java.rmi@11.0.2/RemoteObjectInvocationHandler.java:209)
at
java.rmi.server.RemoteObjectInvocationHandler.invoke(java.rmi@11.0.2/RemoteObjectInvocationHandler.java:161)
at com.sun.proxy.$Proxy38.executeMethodOnObject(Unknown Source)
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:554)
at org.apache.geode.test.dunit.VM.invoke(VM.java:384)
at
org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDUnitTest.createSenderCaches(SerialGatewaySenderOperationsDUnitTest.java:122)
at
org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDUnitTest.testStopOneSerialGatewaySenderBothPrimary(SerialGatewaySenderOperationsDUnitTest.java:356)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@11.0.2/Native
Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@11.0.2/NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@11.0.2/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@11.0.2/Method.java:566)
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:110)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
at
org.gradle.api.internal.task
[jira] [Created] (GEODE-6400) Expose artifacts that are suitable for composite consumption.
Patrick Rhomberg created GEODE-6400:
---
Summary: Expose artifacts that are suitable for composite
consumption.
Key: GEODE-6400
URL: https://issues.apache.org/jira/browse/GEODE-6400
Project: Geode
Issue Type: Sub-task
Reporter: Patrick Rhomberg
Artifacts exposed to composite builds are defined in the legacy
{{archives.artifacts}} publication style. However, this should / will / must
not change what our actual publication artifacts (with respect to the
{{maven-publish}} plugin).
This is also an opportunity to streamline some of our more gnarly code in both
{{geode-assembly}} and {{publish.gradle}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-6401) Create an example of a project that consumes Geode via composite building.
Patrick Rhomberg created GEODE-6401: --- Summary: Create an example of a project that consumes Geode via composite building. Key: GEODE-6401 URL: https://issues.apache.org/jira/browse/GEODE-6401 Project: Geode Issue Type: Sub-task Reporter: Patrick Rhomberg -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6399) Use java-platform to unify dependencyManagement in published artifacts
Patrick Rhomberg created GEODE-6399:
---
Summary: Use java-platform to unify dependencyManagement in
published artifacts
Key: GEODE-6399
URL: https://issues.apache.org/jira/browse/GEODE-6399
Project: Geode
Issue Type: Sub-task
Reporter: Patrick Rhomberg
Requires GEODE-6398.
Via {{java-platform}}, we can declare inter-subproject BOM dependencies that
resolve at configuration time, allowing us to bump dependency versions without
updating each of our ~30 {{expected-pom.xml}} files.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-6398) Upgrade Gradle to 5.2+
Patrick Rhomberg created GEODE-6398:
---
Summary: Upgrade Gradle to 5.2+
Key: GEODE-6398
URL: https://issues.apache.org/jira/browse/GEODE-6398
Project: Geode
Issue Type: Sub-task
Reporter: Patrick Rhomberg
In Gradle 5.2, the {{java-platform}} plugin allows for a simple, gradle-native
way to declare dependency constraints. Most importantly, this occurs at
configuration time, alleviating issues surrounding our previous attempt to
consume a single Geode BOM.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-6397) Allow Geode to participate in composite builds
Patrick Rhomberg created GEODE-6397: --- Summary: Allow Geode to participate in composite builds Key: GEODE-6397 URL: https://issues.apache.org/jira/browse/GEODE-6397 Project: Geode Issue Type: Improvement Reporter: Patrick Rhomberg As a developer of both Geode and a developer of a third-party tools consuming Geode, I would like to be able to test changes of the consuming library against a local build of Geode rather a specific, published version. While Gradle Composite Builds have a mixed reputation, Geode's own build should do what it can to mitigate difficulties surrounding composite building. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6395) Safeguard spotless custom rule bump
Patrick Rhomberg created GEODE-6395:
---
Summary: Safeguard spotless custom rule bump
Key: GEODE-6395
URL: https://issues.apache.org/jira/browse/GEODE-6395
Project: Geode
Issue Type: Improvement
Reporter: Patrick Rhomberg
The Spotless method {{bumpThisNumberIfACustomStepChanges}} should have its
input changed whenever a custom rule is changed or added. Failure to do so can
cause spotless to not execute, or to throw an NPE in rare instances.
Developers can easily overlook this however. As an alternative, we could pass
the sha of the spotless file itself to this method, ensuring that any change to
spotless will cause the spotless cache to invalidate itself.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-6395) Safeguard spotless custom rule bump
[
https://issues.apache.org/jira/browse/GEODE-6395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg reassigned GEODE-6395:
---
Assignee: Patrick Rhomberg
> Safeguard spotless custom rule bump
> ---
>
> Key: GEODE-6395
> URL: https://issues.apache.org/jira/browse/GEODE-6395
> Project: Geode
> Issue Type: Improvement
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
>
> The Spotless method {{bumpThisNumberIfACustomStepChanges}} should have its
> input changed whenever a custom rule is changed or added. Failure to do so
> can cause spotless to not execute, or to throw an NPE in rare instances.
> Developers can easily overlook this however. As an alternative, we could
> pass the sha of the spotless file itself to this method, ensuring that any
> change to spotless will cause the spotless cache to invalidate itself.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-6383) Build scripting should not violate modularity.
[
https://issues.apache.org/jira/browse/GEODE-6383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg updated GEODE-6383:
Description:
In many portions of our build scripting, we use the invasive,
modularity-breaking pattern of
{noformat}
subprojects {
configureSomething
}
{noformat}
As a result, within a single subproject, it is very difficult to know (without
prior experience) how the subproject is configured.
This ticket is intended to be a "parent" ticket for jobs that fall into the
following categories:
* Converting a plugin-script in {{gradle/}} to a class extending
{{Plugin}}.
* Moving a plugin to belong to {{buildSrc}}
* Converting invasive {{subproject [configuration]}} calls to be "opt-in" by
the subprojects that require the configuration, such as the work done in
GEODE-6237.
was:
In many portions of our build scripting, we use the invasive,
modularity-breaking pattern of
{noformat}
subprojects {
configureSomething
}
{noformat}
As a result, within a single subproject, it is very difficult to know (without
prior experience) how the subproject is configured.
This ticket is intended to be a "parent" ticket for jobs that fall into the
following categories:
* Converting a plugin-script in {{gradle/}} to a class extending
{{Plugin}}.
* Moving a plugin to belong to {{buildSrc}}
* Converting invasive {{subproject [configuration]}} calls to be "opt-in" by
the subprojects that require the configuration.
> Build scripting should not violate modularity.
> --
>
> Key: GEODE-6383
> URL: https://issues.apache.org/jira/browse/GEODE-6383
> Project: Geode
> Issue Type: Improvement
>Reporter: Patrick Rhomberg
>Priority: Major
>
> In many portions of our build scripting, we use the invasive,
> modularity-breaking pattern of
> {noformat}
> subprojects {
> configureSomething
> }
> {noformat}
> As a result, within a single subproject, it is very difficult to know
> (without prior experience) how the subproject is configured.
> This ticket is intended to be a "parent" ticket for jobs that fall into the
> following categories:
> * Converting a plugin-script in {{gradle/}} to a class extending
> {{Plugin}}.
> * Moving a plugin to belong to {{buildSrc}}
> * Converting invasive {{subproject [configuration]}} calls to be "opt-in" by
> the subprojects that require the configuration, such as the work done in
> GEODE-6237.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-6383) Build scripting should not violate modularity.
[
https://issues.apache.org/jira/browse/GEODE-6383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg updated GEODE-6383:
Description:
In many portions of our build scripting, we use the invasive,
modularity-breaking pattern of
{noformat}
subprojects {
configureSomething
}
{noformat}
This is particularly problematic when certain plugins or built-ins do not
integrate well with each other, e.g, Gradle 5.2's {{java-platform}} needing to
be applied before the {{java}} plugin.
As a result, within a single subproject, it is very difficult to know (without
prior experience) how the subproject is configured.
This ticket is intended to be a "parent" ticket for jobs that fall into the
following categories:
* Converting a plugin-script in {{gradle/}} to a class extending
{{Plugin}}.
* Moving a plugin to belong to {{buildSrc}}
* Converting invasive {{subproject [configuration]}} calls to be "opt-in" by
the subprojects that require the configuration, such as the work done in
GEODE-6237.
was:
In many portions of our build scripting, we use the invasive,
modularity-breaking pattern of
{noformat}
subprojects {
configureSomething
}
{noformat}
As a result, within a single subproject, it is very difficult to know (without
prior experience) how the subproject is configured.
This ticket is intended to be a "parent" ticket for jobs that fall into the
following categories:
* Converting a plugin-script in {{gradle/}} to a class extending
{{Plugin}}.
* Moving a plugin to belong to {{buildSrc}}
* Converting invasive {{subproject [configuration]}} calls to be "opt-in" by
the subprojects that require the configuration, such as the work done in
GEODE-6237.
> Build scripting should not violate modularity.
> --
>
> Key: GEODE-6383
> URL: https://issues.apache.org/jira/browse/GEODE-6383
> Project: Geode
> Issue Type: Improvement
>Reporter: Patrick Rhomberg
>Priority: Major
>
> In many portions of our build scripting, we use the invasive,
> modularity-breaking pattern of
> {noformat}
> subprojects {
> configureSomething
> }
> {noformat}
> This is particularly problematic when certain plugins or built-ins do not
> integrate well with each other, e.g, Gradle 5.2's {{java-platform}} needing
> to be applied before the {{java}} plugin.
> As a result, within a single subproject, it is very difficult to know
> (without prior experience) how the subproject is configured.
> This ticket is intended to be a "parent" ticket for jobs that fall into the
> following categories:
> * Converting a plugin-script in {{gradle/}} to a class extending
> {{Plugin}}.
> * Moving a plugin to belong to {{buildSrc}}
> * Converting invasive {{subproject [configuration]}} calls to be "opt-in" by
> the subprojects that require the configuration, such as the work done in
> GEODE-6237.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-6383) Build scripting should not violate modularity.
[
https://issues.apache.org/jira/browse/GEODE-6383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg updated GEODE-6383:
Description:
In many portions of our build scripting, we use the invasive,
modularity-breaking pattern of
{noformat}
subprojects {
configureSomething
}
{noformat}
As a result, within a single subproject, it is very difficult to know (without
prior experience) how the subproject is configured.
This ticket is intended to be a "parent" ticket for jobs that fall into the
following categories:
* Converting a plugin-script in {{gradle/}} to a class extending
{{Plugin}}.
* Moving a plugin to belong to {{buildSrc}}
* Converting invasive {{subproject [configuration]}} calls to be "opt-in" by
the subprojects that require the configuration.
was:
In many portions of our build scripting, we use the invasive,
modularity-breaking pattern of
{noformat}
subprojects {
configureSomething
}
{noformat}
As a result, within a single subproject, it is very difficult to know (without
prior experience) how the subproject is configured.
This ticket is intended to be a "parent" ticket for jobs that fall into the
following categories:
* Converting a plugin-script in {{gradle/}} to a class extending
{{Plugin}}.
* Moving a plugin to belong to {{buildSrc}}
* Converting invasive {{subproject {[configuration]}}} calls to be "opt-in" by
the subprojects that require the configuration.
> Build scripting should not violate modularity.
> --
>
> Key: GEODE-6383
> URL: https://issues.apache.org/jira/browse/GEODE-6383
> Project: Geode
> Issue Type: Improvement
>Reporter: Patrick Rhomberg
>Priority: Major
>
> In many portions of our build scripting, we use the invasive,
> modularity-breaking pattern of
> {noformat}
> subprojects {
> configureSomething
> }
> {noformat}
> As a result, within a single subproject, it is very difficult to know
> (without prior experience) how the subproject is configured.
> This ticket is intended to be a "parent" ticket for jobs that fall into the
> following categories:
> * Converting a plugin-script in {{gradle/}} to a class extending
> {{Plugin}}.
> * Moving a plugin to belong to {{buildSrc}}
> * Converting invasive {{subproject [configuration]}} calls to be "opt-in" by
> the subprojects that require the configuration.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-6383) Build scripting should not violate modularity.
Patrick Rhomberg created GEODE-6383:
---
Summary: Build scripting should not violate modularity.
Key: GEODE-6383
URL: https://issues.apache.org/jira/browse/GEODE-6383
Project: Geode
Issue Type: Improvement
Reporter: Patrick Rhomberg
In many portions of our build scripting, we use the invasive,
modularity-breaking pattern of
{noformat}
subprojects {
configureSomething
}
{noformat}
As a result, within a single subproject, it is very difficult to know (without
prior experience) how the subproject is configured.
This ticket is intended to be a "parent" ticket for jobs that fall into the
following categories:
* Converting a plugin-script in {{gradle/}} to a class extending
{{Plugin}}.
* Moving a plugin to belong to {{buildSrc}}
* Converting invasive {{subproject {[configuration]}}} calls to be "opt-in" by
the subprojects that require the configuration.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-6382) Remove dead code from build -- sanitizedName is now irrelevant
[ https://issues.apache.org/jira/browse/GEODE-6382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg reassigned GEODE-6382: --- Assignee: Patrick Rhomberg > Remove dead code from build -- sanitizedName is now irrelevant > --- > > Key: GEODE-6382 > URL: https://issues.apache.org/jira/browse/GEODE-6382 > Project: Geode > Issue Type: Improvement >Reporter: Patrick Rhomberg >Assignee: Patrick Rhomberg >Priority: Major > > By Gradle5 compliance, project names must not contain a forward-slash. This > utility is now an unnecessarily-complicated fetch of the project name. It > should be removed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6382) Remove dead code from build -- sanitizedName is now irrelevant
Patrick Rhomberg created GEODE-6382: --- Summary: Remove dead code from build -- sanitizedName is now irrelevant Key: GEODE-6382 URL: https://issues.apache.org/jira/browse/GEODE-6382 Project: Geode Issue Type: Improvement Reporter: Patrick Rhomberg By Gradle5 compliance, project names must not contain a forward-slash. This utility is now an unnecessarily-complicated fetch of the project name. It should be removed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6259) Simplify publication logic -- remove mavenSnapshotBucket
[
https://issues.apache.org/jira/browse/GEODE-6259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg resolved GEODE-6259.
-
Resolution: Fixed
> Simplify publication logic -- remove mavenSnapshotBucket
>
>
> Key: GEODE-6259
> URL: https://issues.apache.org/jira/browse/GEODE-6259
> Project: Geode
> Issue Type: Improvement
>Reporter: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> At the moment, the Maven target for publication is determined by:
> (1) If it was provided on the command line
> (2) If the version string indicates that it is a release version
> (3) If a "snapshot bucket" was provided on the commandline
> (4) Or a default snapshot location.
> The {{mavenSnapshotBucket}} is an unnecessary accessory that injects the
> provided string into a GCS url. A complete {{mavenRepository}} should be
> provided instead.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-6323) Configuration in doFirst and doLast blocks are not valid for task configuration.
Patrick Rhomberg created GEODE-6323:
---
Summary: Configuration in doFirst and doLast blocks are not valid
for task configuration.
Key: GEODE-6323
URL: https://issues.apache.org/jira/browse/GEODE-6323
Project: Geode
Issue Type: Bug
Components: ci
Reporter: Patrick Rhomberg
See
https://guides.gradle.org/using-build-cache/#suggestions_for_authoring_your_build
{{doFirst}} and {{doLast}} occur at execution, but the up-to-date state of the
task is required at configuration-time. More importantly, these task actions
are cacheable and can be returned incorrectly if the declared inputs to the
task are unchanged. Notably for {{gfshDepsJar}} and {{depsJar}}, if the
{{cp()}} changes, these changes will not be detected and a cached version of
the manifest can be used rather than the new intended classpath.
This is not an issue in the Concourse pipeline, since no cache exists, but it
can be troublesome for a developer.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-6323) Configuration in doFirst and doLast blocks are not valid for task configuration.
[
https://issues.apache.org/jira/browse/GEODE-6323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg reassigned GEODE-6323:
---
Assignee: Robert Houghton
> Configuration in doFirst and doLast blocks are not valid for task
> configuration.
>
>
> Key: GEODE-6323
> URL: https://issues.apache.org/jira/browse/GEODE-6323
> Project: Geode
> Issue Type: Bug
> Components: ci
>Reporter: Patrick Rhomberg
>Assignee: Robert Houghton
>Priority: Major
>
> See
> https://guides.gradle.org/using-build-cache/#suggestions_for_authoring_your_build
> {{doFirst}} and {{doLast}} occur at execution, but the up-to-date state of
> the task is required at configuration-time. More importantly, these task
> actions are cacheable and can be returned incorrectly if the declared inputs
> to the task are unchanged. Notably for {{gfshDepsJar}} and {{depsJar}}, if
> the {{cp()}} changes, these changes will not be detected and a cached version
> of the manifest can be used rather than the new intended classpath.
> This is not an issue in the Concourse pipeline, since no cache exists, but it
> can be troublesome for a developer.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-6314) CI: Build version should only be rolled, and should always be rolled, at the Build step
[ https://issues.apache.org/jira/browse/GEODE-6314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg reassigned GEODE-6314: --- Assignee: Patrick Rhomberg > CI: Build version should only be rolled, and should always be rolled, at the > Build step > --- > > Key: GEODE-6314 > URL: https://issues.apache.org/jira/browse/GEODE-6314 > Project: Geode > Issue Type: Bug > Components: ci >Reporter: Patrick Rhomberg >Assignee: Patrick Rhomberg >Priority: Major > > Currently, the build ID is bumped also at publish as well as Build, and Build > only bumps when it is successful. In its role as a single, meaningful > identifier, it should always be rolled at Build, and only there. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6314) CI: Build version should only be rolled, and should always be rolled, at the Build step
Patrick Rhomberg created GEODE-6314: --- Summary: CI: Build version should only be rolled, and should always be rolled, at the Build step Key: GEODE-6314 URL: https://issues.apache.org/jira/browse/GEODE-6314 Project: Geode Issue Type: Bug Components: ci Reporter: Patrick Rhomberg Currently, the build ID is bumped also at publish as well as Build, and Build only bumps when it is successful. In its role as a single, meaningful identifier, it should always be rolled at Build, and only there. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-6302) checkPom only checks dependencies, but not other Pom sections
[
https://issues.apache.org/jira/browse/GEODE-6302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg reassigned GEODE-6302:
---
Assignee: Patrick Rhomberg
> checkPom only checks dependencies, but not other Pom sections
> -
>
> Key: GEODE-6302
> URL: https://issues.apache.org/jira/browse/GEODE-6302
> Project: Geode
> Issue Type: Improvement
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
>
> Most notable, the {{dependencyManagement}} section can now change without the
> {{checkPom}} task failing.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-6302) checkPom only checks dependencies, but not other Pom sections
Patrick Rhomberg created GEODE-6302:
---
Summary: checkPom only checks dependencies, but not other Pom
sections
Key: GEODE-6302
URL: https://issues.apache.org/jira/browse/GEODE-6302
Project: Geode
Issue Type: Improvement
Reporter: Patrick Rhomberg
Most notable, the {{dependencyManagement}} section can now change without the
{{checkPom}} task failing.
--
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] [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] [Resolved] (GEODE-6252) Combine dependencies into dependencySets
[ https://issues.apache.org/jira/browse/GEODE-6252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg resolved GEODE-6252. - Resolution: Fixed > Combine dependencies into dependencySets > > > Key: GEODE-6252 > URL: https://issues.apache.org/jira/browse/GEODE-6252 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Rhomberg >Priority: Major > Labels: pull-request-available > Time Spent: 1h > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6259) Simplify publication logic -- remove mavenSnapshotBucket
Patrick Rhomberg created GEODE-6259:
---
Summary: Simplify publication logic -- remove mavenSnapshotBucket
Key: GEODE-6259
URL: https://issues.apache.org/jira/browse/GEODE-6259
Project: Geode
Issue Type: Improvement
Reporter: Patrick Rhomberg
At the moment, the Maven target for publication is determined by:
(1) If it was provided on the command line
(2) If the version string indicates that it is a release version
(3) If a "snapshot bucket" was provided on the commandline
(4) Or a default snapshot location.
The {{mavenSnapshotBucket}} is an unnecessary accessory that injects the
provided string into a GCS url. A complete {{mavenRepository}} should be
provided instead.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-6237) Publication should be "opt-in" rather than injected into all subprojects
[
https://issues.apache.org/jira/browse/GEODE-6237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg resolved GEODE-6237.
-
Resolution: Fixed
> Publication should be "opt-in" rather than injected into all subprojects
>
>
> Key: GEODE-6237
> URL: https://issues.apache.org/jira/browse/GEODE-6237
> Project: Geode
> Issue Type: Improvement
>Reporter: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Currently, we inject publication logic into all subprojects in our
> {{publish.gradle}}. Then, many subprojects "opt-out" of this via our custom
> {{disableMavenPublishing}} global method.
> Rather than activating publication for all modules, then disabling it for
> some select internal modules, it would be better for those modules we intend
> to publish to "opt-in" to publication and apply the plugin specifically to
> those modules. Moreover, this iterates us towards modularity within each
> subproject module, rather than the injection and tight-coupling that the
> {{subprojects}} and {{allprojects}} configurations represent.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-6252) Combine dependencies into dependencySets
Patrick Rhomberg created GEODE-6252: --- Summary: Combine dependencies into dependencySets Key: GEODE-6252 URL: https://issues.apache.org/jira/browse/GEODE-6252 Project: Geode Issue Type: Sub-task Reporter: Patrick Rhomberg -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6247) HostStatSampler posts suspect string stemming from native code in JDK11, causing failure in NetstatDUnitTest
Patrick Rhomberg created GEODE-6247:
---
Summary: HostStatSampler posts suspect string stemming from native
code in JDK11, causing failure in NetstatDUnitTest
Key: GEODE-6247
URL: https://issues.apache.org/jira/browse/GEODE-6247
Project: Geode
Issue Type: Bug
Reporter: Patrick Rhomberg
In JDK11 run
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/278:
{noformat}
org.apache.geode.management.internal.cli.NetstatDUnitTest > classMethod FAILED
java.lang.AssertionError: Suspicious strings were written to the log during
this run.
Fix the strings or use IgnoredException.addIgnoredException to ignore.
---
Found suspect string in log4j at line 2183
[fatal 2019/01/04 00:15:19.050 UTC tid=67] committed =
538968064 should be < max = 536870912
java.lang.IllegalArgumentException: committed = 538968064 should be < max =
536870912
at
java.management/java.lang.management.MemoryUsage.(MemoryUsage.java:166)
at java.management/sun.management.MemoryImpl.getMemoryUsage0(Native
Method)
at
java.management/sun.management.MemoryImpl.getHeapMemoryUsage(MemoryImpl.java:71)
at
org.apache.geode.internal.stats50.VMStats50.refresh(VMStats50.java:624)
at
org.apache.geode.internal.statistics.HostStatSampler.sampleSpecialStats(HostStatSampler.java:562)
at
org.apache.geode.internal.statistics.HostStatSampler.run(HostStatSampler.java:235)
at java.base/java.lang.Thread.run(Thread.java:834)
---
Found suspect string in log4j at line 2193
[fatal 2019/01/04 00:15:19.055 UTC tid=67] Uncaught exception
in thread Thread[StatSampler,10,RMI Runtime]
java.lang.IllegalArgumentException: committed = 538968064 should be < max =
536870912
at
java.management/java.lang.management.MemoryUsage.(MemoryUsage.java:166)
at java.management/sun.management.MemoryImpl.getMemoryUsage0(Native
Method)
at
java.management/sun.management.MemoryImpl.getHeapMemoryUsage(MemoryImpl.java:71)
at
org.apache.geode.internal.stats50.VMStats50.refresh(VMStats50.java:624)
at
org.apache.geode.internal.statistics.HostStatSampler.sampleSpecialStats(HostStatSampler.java:562)
at
org.apache.geode.internal.statistics.HostStatSampler.run(HostStatSampler.java:235)
at java.base/java.lang.Thread.run(Thread.java:834)
{noformat}
Test report at:
http://files.apachegeode-ci.info/builds/apache-develop-main/1.9.0-build.320/test-results/distributedTest/1546563376/
Artifacts at:
http://files.apachegeode-ci.info/builds/apache-develop-main/1.9.0-build.320/test-artifacts/1546563376/distributedtestfiles-OpenJDK11-1.9.0-build.320.tgz
This appears to be identical to the failure in GEODE-6046.
We note that the difference in reported values is exactly 2MB.
We note additionally that the suspect string itself appears during the
class-rule startup, but before any class test is executed.
Also possibly related to GEODE-6079, regarding how logs are written and the
possibility of buffers not flushing properly before suspect strings are
detected. It is not obvious that this suspect string failure does not truly
belong to another test.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-6237) Publication should be "opt-in" rather than injected into all subprojects
Patrick Rhomberg created GEODE-6237:
---
Summary: Publication should be "opt-in" rather than injected into
all subprojects
Key: GEODE-6237
URL: https://issues.apache.org/jira/browse/GEODE-6237
Project: Geode
Issue Type: Improvement
Reporter: Patrick Rhomberg
Currently, we inject publication logic into all subprojects in our
{{publish.gradle}}. Then, many subprojects "opt-out" of this via our custom
{{disableMavenPublishing}} global method.
Rather than activating publication for all modules, then disabling it for some
select internal modules, it would be better for those modules we intend to
publish to "opt-in" to publication and apply the plugin specifically to those
modules. Moreover, this iterates us towards modularity within each subproject
module, rather than the injection and tight-coupling that the {{subprojects}}
and {{allprojects}} configurations represent.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-6231) Increase timeout for DistributedTest jobs until effect of Pom sizes can be understood
[ https://issues.apache.org/jira/browse/GEODE-6231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg resolved GEODE-6231. - Resolution: Fixed > Increase timeout for DistributedTest jobs until effect of Pom sizes can be > understood > - > > Key: GEODE-6231 > URL: https://issues.apache.org/jira/browse/GEODE-6231 > Project: Geode > Issue Type: Bug >Reporter: Patrick Rhomberg >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > The recent resolution of injecting BOM contents directly into module POMs has > had the inexplicable side-effect of adding an hour to the length of some of > our DistributedTest suites. This has brought the "expected" runtime to be > close to the timeout of the task. > Increase the timeout until the cause of this issue can be found, understood, > and resolved. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6223) Build job(s) should include resolveDependencies task
[ https://issues.apache.org/jira/browse/GEODE-6223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg resolved GEODE-6223. - Resolution: Fixed > Build job(s) should include resolveDependencies task > > > Key: GEODE-6223 > URL: https://issues.apache.org/jira/browse/GEODE-6223 > Project: Geode > Issue Type: Improvement >Reporter: Patrick Rhomberg >Priority: Major > Labels: pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > > The recent BOM changes broke the resolveDependencies task (as the BOM was > required but was note declared as a dependency), but this went undetected in > both the precheckin and main CI pipelines, as the task is only targeted in > the creation of test images. > This task should be a part of the Build test job, to prevent image breakage > in the future. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6224) BOM task dependencies is inhospitable to external developers
[
https://issues.apache.org/jira/browse/GEODE-6224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg resolved GEODE-6224.
-
Resolution: Fixed
> BOM task dependencies is inhospitable to external developers
>
>
> Key: GEODE-6224
> URL: https://issues.apache.org/jira/browse/GEODE-6224
> Project: Geode
> Issue Type: Bug
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
> Time Spent: 50m
> Remaining Estimate: 0h
>
> As acknowledged in the commit message of GEODE-6198, our approach to depend
> on the bom publish task was heavy-handed. However, this extends farther than
> initially realized, as any consumer of Geode will also have to manage these
> task dependencies.
> Until a cleaner solution can be identified, the {{dependencyManagement}}
> block currently belonging to the BOM should be applied in place of the BOM.
> The subproject {{geode-all-bom}} should consume this block and publish a BOM
> that is, for now, reproduced in all other POMs.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-6214) Extend gradle property mavenRepository et al to be used beyond publication
[
https://issues.apache.org/jira/browse/GEODE-6214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg resolved GEODE-6214.
-
Resolution: Not A Problem
> Extend gradle property mavenRepository et al to be used beyond publication
> --
>
> Key: GEODE-6214
> URL: https://issues.apache.org/jira/browse/GEODE-6214
> Project: Geode
> Issue Type: Improvement
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
>
> Currently, the options {{mavenRepository}}, {{mavenUsername}}, and
> {{mavenPassword}} may be specified by a Geode consumer to specify where maven
> artifacts may be published. Given that a consumer may prefer to consume from
> this location also, this logic should be extended to also apply to the
> {{maven}} block where dependencies will be found.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-6231) Increase timeout for DistributedTest jobs until effect of Pom sizes can be understood
Patrick Rhomberg created GEODE-6231: --- Summary: Increase timeout for DistributedTest jobs until effect of Pom sizes can be understood Key: GEODE-6231 URL: https://issues.apache.org/jira/browse/GEODE-6231 Project: Geode Issue Type: Bug Reporter: Patrick Rhomberg The recent resolution of injecting BOM contents directly into module POMs has had the inexplicable side-effect of adding an hour to the length of some of our DistributedTest suites. This has brought the "expected" runtime to be close to the timeout of the task. Increase the timeout until the cause of this issue can be found, understood, and resolved. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6224) BOM task dependencies is inhospitable to external developers
Patrick Rhomberg created GEODE-6224:
---
Summary: BOM task dependencies is inhospitable to external
developers
Key: GEODE-6224
URL: https://issues.apache.org/jira/browse/GEODE-6224
Project: Geode
Issue Type: Bug
Reporter: Patrick Rhomberg
As acknowledged in the commit message of GEODE-6198, our approach to depend on
the bom publish task was heavy-handed. However, this extends farther than
initially realized, as any consumer of Geode will also have to manage these
task dependencies.
Until a cleaner solution can be identified, the {{dependencyManagement}} block
currently belonging to the BOM should be applied in place of the BOM. The
subproject {{geode-all-bom}} should consume this block and publish a BOM that
is, for now, reproduced in all other POMs.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-6224) BOM task dependencies is inhospitable to external developers
[
https://issues.apache.org/jira/browse/GEODE-6224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg reassigned GEODE-6224:
---
Assignee: Patrick Rhomberg
> BOM task dependencies is inhospitable to external developers
>
>
> Key: GEODE-6224
> URL: https://issues.apache.org/jira/browse/GEODE-6224
> Project: Geode
> Issue Type: Bug
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
>
> As acknowledged in the commit message of GEODE-6198, our approach to depend
> on the bom publish task was heavy-handed. However, this extends farther than
> initially realized, as any consumer of Geode will also have to manage these
> task dependencies.
> Until a cleaner solution can be identified, the {{dependencyManagement}}
> block currently belonging to the BOM should be applied in place of the BOM.
> The subproject {{geode-all-bom}} should consume this block and publish a BOM
> that is, for now, reproduced in all other POMs.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-6223) Build job(s) should include resolveDependencies task
Patrick Rhomberg created GEODE-6223: --- Summary: Build job(s) should include resolveDependencies task Key: GEODE-6223 URL: https://issues.apache.org/jira/browse/GEODE-6223 Project: Geode Issue Type: Improvement Reporter: Patrick Rhomberg The recent BOM changes broke the resolveDependencies task (as the BOM was required but was note declared as a dependency), but this went undetected in both the precheckin and main CI pipelines, as the task is only targeted in the creation of test images. This task should be a part of the Build test job, to prevent image breakage in the future. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-4811) Add a @Disabled annotation to various endpoints to facilitate feature-flagging.
[
https://issues.apache.org/jira/browse/GEODE-4811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg reassigned GEODE-4811:
---
Assignee: (was: Patrick Rhomberg)
> Add a @Disabled annotation to various endpoints to facilitate
> feature-flagging.
> ---
>
> Key: GEODE-4811
> URL: https://issues.apache.org/jira/browse/GEODE-4811
> Project: Geode
> Issue Type: New Feature
> Components: gfsh
>Reporter: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Many gfsh commands are mutually required by each other for full
> functionality. For instance, {{destroy jndi-binding}} is meaningless without
> the {{create jndi-binding}} command.
> As a developer, I would like to be able to coordinate release of multiple
> related commands at once, across multiple commits. A {{@FeatureFlag}}
> annotation on gfsh command classes would be extremely useful.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5366) DUnitLauncher does not respect the number of VMs requested in ClusterStartupRule
[
https://issues.apache.org/jira/browse/GEODE-5366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg resolved GEODE-5366.
-
Resolution: Won't Fix
> DUnitLauncher does not respect the number of VMs requested in
> ClusterStartupRule
>
>
> Key: GEODE-5366
> URL: https://issues.apache.org/jira/browse/GEODE-5366
> Project: Geode
> Issue Type: Sub-task
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
>
> The ClusterStartupRule has the method
> {noformat}
> @Override
> protected void before() throws Throwable {
> DUnitLauncher.launchIfNeeded();
> for (int i = 0; i < vmCount; i++) {
> Host.getHost(0).getVM(i);
> }
> restoreSystemProperties.before();
> occupiedVMs = new HashMap<>();
> }
> {noformat}
> By calling the no-arg {{launchIfNeeded}}, the number of requested VMs is not
> properly passed to the DUnitLauncher. This is not a problem if vmCount > 4,
> since the following loop will instantiate any extra VMs. However, if fewer
> than 4 VMs are requested, the DUnitLauncher will still spin up extra VMs,
> wasting cycles.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5032) Massage Configuration Objects for Better Intuition.
[ https://issues.apache.org/jira/browse/GEODE-5032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg resolved GEODE-5032. - Resolution: Fixed > Massage Configuration Objects for Better Intuition. > --- > > Key: GEODE-5032 > URL: https://issues.apache.org/jira/browse/GEODE-5032 > Project: Geode > Issue Type: Sub-task > Components: configuration >Reporter: Patrick Rhomberg >Assignee: Patrick Rhomberg >Priority: Major > Labels: pull-request-available > Time Spent: 3h 40m > Remaining Estimate: 0h > > For instance, various port fields are declared as Strings where an Integer > makes more sense. This is true for many "count" fields as well. > These may be best resolved via a JAXB bindings file and regenerating the > POJOs from scratch. Additionally if all the minor adjustments that have been > already made (removing the xsd:choice and manually enforcing it, having each > item implement CacheElement and have a getId() method) can also be resolved > via a bindings file, then the POJOs could be removed from the git tree and > generated during the build step, if desired. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-5365) A no-arg ClusterStartupRule constructor encourages bad developer practice
[ https://issues.apache.org/jira/browse/GEODE-5365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg resolved GEODE-5365. - Resolution: Won't Fix > A no-arg ClusterStartupRule constructor encourages bad developer practice > - > > Key: GEODE-5365 > URL: https://issues.apache.org/jira/browse/GEODE-5365 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Rhomberg >Assignee: Patrick Rhomberg >Priority: Major > > Many tests currently spin up more VMs than the test actually requires. This > is typically due to the ClusterStartupRule being instantiated using the > no-arg constructor. > Using four VMs by default may have once been convenient, but it encourages a > laissez faire attitude in test development. A developer should give due > thought to the number of VMs a test needs to instantiate. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6198) Manage dependencies via BOM
[ https://issues.apache.org/jira/browse/GEODE-6198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg resolved GEODE-6198. - Resolution: Fixed > Manage dependencies via BOM > --- > > Key: GEODE-6198 > URL: https://issues.apache.org/jira/browse/GEODE-6198 > Project: Geode > Issue Type: Improvement >Reporter: Patrick Rhomberg >Assignee: Patrick Rhomberg >Priority: Major > Labels: pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6189) Cleanup: remove unused scripts in ci/scripts/windows/
[
https://issues.apache.org/jira/browse/GEODE-6189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg resolved GEODE-6189.
-
Resolution: Fixed
> Cleanup: remove unused scripts in ci/scripts/windows/
> -
>
> Key: GEODE-6189
> URL: https://issues.apache.org/jira/browse/GEODE-6189
> Project: Geode
> Issue Type: Improvement
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> These scripts have been replaced / unified with {{execute_tests.sh}} and
> {{archive_results.sh}} and are unused anywhere within the codebase.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-6100) LogConsumer is creating instability in suspect string detection
[
https://issues.apache.org/jira/browse/GEODE-6100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg reassigned GEODE-6100:
---
Assignee: (was: Patrick Rhomberg)
> LogConsumer is creating instability in suspect string detection
> ---
>
> Key: GEODE-6100
> URL: https://issues.apache.org/jira/browse/GEODE-6100
> Project: Geode
> Issue Type: Bug
>Reporter: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
> Time Spent: 40m
> Remaining Estimate: 0h
>
> (Original ticket title: CI:
> CacheClientNotifierDUnitTest.testNormalClient2MultipleCacheServer failed with
> suspect strings)
> Failure at:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/163
> Failed with message:
> {noformat}
> org.apache.geode.internal.cache.wan.CacheClientNotifierDUnitTest >
> testNormalClient2MultipleCacheServer 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 3689
> /hom[warn 2018/11/27 21:24:25.124 UTC
> tid=179] Cache Client
> Updater Thread on ef956df2d60b(376):41003 port 28307
> (ef956df2d60b:28307): Caught following exception while attempting to create a
> server-to-client communication socket and will exit:
> org.apache.geode.cache.client.ServerRefusedConnectionException: inet_addr hostname>:28307 refused connection: A previous connection
> attempt from this client is still being processed:
> identity(172.17.0.8(381:loner):47756:85080f57,connection=1
> {noformat}
> Results viewable at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.9.0-build.198/test-results/distributedTest/1543356956/
> Artifacts available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.9.0-build.198/test-artifacts/1543356956/distributedtestfiles-OpenJDK8-1.9.0-build.198.tgz
> Possibly related to GEODE-5595 per the comment by Ken Howe, insofar as his
> comment also includes the same suspect string. Also quite possibly
> unrelated. You, dear reader, can find out!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-6214) Extend gradle property mavenRepository et al to be used beyond publication
[
https://issues.apache.org/jira/browse/GEODE-6214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg updated GEODE-6214:
Description: Currently, the options {{mavenRepository}}, {{mavenUsername}},
and {{mavenPassword}} may be specified by a Geode consumer to specify where
maven artifacts may be published. Given that a consumer may prefer to consume
from this location also, this logic should be extended to also apply to the
{{maven}} block where dependencies will be found. (was: Currently, the options
{{mavenRepository}}, {{mavenUsername}}, and {{mavenPassword}} may be specified
by a Geode consumer to specify where maven artifacts may be published. Given
that a consumer may prefer to consume from this location also, this logic
should be extended to also apply to the {{maven { }} block where dependencies
will be found.)
> Extend gradle property mavenRepository et al to be used beyond publication
> --
>
> Key: GEODE-6214
> URL: https://issues.apache.org/jira/browse/GEODE-6214
> Project: Geode
> Issue Type: Improvement
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
>
> Currently, the options {{mavenRepository}}, {{mavenUsername}}, and
> {{mavenPassword}} may be specified by a Geode consumer to specify where maven
> artifacts may be published. Given that a consumer may prefer to consume from
> this location also, this logic should be extended to also apply to the
> {{maven}} block where dependencies will be found.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-6214) Extend gradle property mavenRepository et al to be used beyond publication
[
https://issues.apache.org/jira/browse/GEODE-6214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg reassigned GEODE-6214:
---
Assignee: Patrick Rhomberg
> Extend gradle property mavenRepository et al to be used beyond publication
> --
>
> Key: GEODE-6214
> URL: https://issues.apache.org/jira/browse/GEODE-6214
> Project: Geode
> Issue Type: Improvement
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
>
> Currently, the options {{mavenRepository}}, {{mavenUsername}}, and
> {{mavenPassword}} may be specified by a Geode consumer to specify where maven
> artifacts may be published. Given that a consumer may prefer to consume from
> this location also, this logic should be extended to also apply to the
> {{maven { }} block where dependencies will be found.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-6214) Extend gradle property mavenRepository et al to be used beyond publication
Patrick Rhomberg created GEODE-6214:
---
Summary: Extend gradle property mavenRepository et al to be used
beyond publication
Key: GEODE-6214
URL: https://issues.apache.org/jira/browse/GEODE-6214
Project: Geode
Issue Type: Improvement
Reporter: Patrick Rhomberg
Currently, the options {{mavenRepository}}, {{mavenUsername}}, and
{{mavenPassword}} may be specified by a Geode consumer to specify where maven
artifacts may be published. Given that a consumer may prefer to consume from
this location also, this logic should be extended to also apply to the {{maven
{ }} block where dependencies will be found.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-6169) Use Spring Dependency-Management to streamline dependency versioning
[
https://issues.apache.org/jira/browse/GEODE-6169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg resolved GEODE-6169.
-
Resolution: Fixed
> Use Spring Dependency-Management to streamline dependency versioning
>
>
> Key: GEODE-6169
> URL: https://issues.apache.org/jira/browse/GEODE-6169
> Project: Geode
> Issue Type: Improvement
> Components: build
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Our use of the `dependency-versions.properties` is cumbersome, hard to read,
> and bloats the global namespace of the gradle project.
> Ideally, we would use the {{constraints}} configuration of our dependencies,
> but per the documentation
> [here|https://docs.gradle.org/current/userguide/managing_transitive_dependencies.html],
> POMs produced using this feature are incorrect (including {{scope}} in the
> {{dependencyManagement}} section of the pom).
> With {{22a5017745acd4ca22cbcb08b70cc3cedbb4b5fd}} / GEODE-6117, a small
> use-case of this library was introduced to streamline geode-client BOM
> generation.
> This library would be useful to apply to each of our subprojects, allowing
> simpler declaration of dependencies and eliminate the mix-and-match approach
> of explicit definition or delegation to {{project.'some-library.version'}}
> that seems pervasive.
> Lastly, this will integrate with the Nebula dependency linter (GEODE-5801),
> as the linter is currently unable to detect unused dependencies in the face
> of our concatenated string convention.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-6198) Manage dependencies via BOM
[ https://issues.apache.org/jira/browse/GEODE-6198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg reassigned GEODE-6198: --- Assignee: Patrick Rhomberg > Manage dependencies via BOM > --- > > Key: GEODE-6198 > URL: https://issues.apache.org/jira/browse/GEODE-6198 > Project: Geode > Issue Type: Improvement >Reporter: Patrick Rhomberg >Assignee: Patrick Rhomberg >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
