[jira] [Created] (GEODE-6022) Make cmake 3.12 the minimum version
Michael Martell created GEODE-6022: -- Summary: Make cmake 3.12 the minimum version Key: GEODE-6022 URL: https://issues.apache.org/jira/browse/GEODE-6022 Project: Geode Issue Type: Bug Components: native client Reporter: Michael Martell A number of projects in the clicache now use DOTNET_TARTET_FRAMEWORK to specify which version of the .NET framework to use. The cmake minimum should be changed from 3.10 to 3.12 in all CMakeLists.txt files. Also, the BUILDING.md should also be changed accordingly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5667) gfsh create gateway-receiver option "--manual-start" has counterintuitive default
[ https://issues.apache.org/jira/browse/GEODE-5667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-5667: -- Labels: pull-request-available (was: ) > gfsh create gateway-receiver option "--manual-start" has counterintuitive > default > - > > Key: GEODE-5667 > URL: https://issues.apache.org/jira/browse/GEODE-5667 > Project: Geode > Issue Type: Improvement > Components: docs, gfsh >Affects Versions: 1.6.0 >Reporter: Dave Barnes >Assignee: Juan José Ramos Cassella >Priority: Major > Labels: pull-request-available > > The "--manual-start" option for the `gfsh create gateway-receiver` command, > when specified without a value (=true or =false), should set > manual-start=true. > Current behavior is that if specified without a value, the parameter is set > to null, which invokes the system's default behavior, which happens to be > `false`. > This is counterintuitive to the user, who (I'm certain) would expect > `--manual-start` to result in the parameter being set to `true`. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6022) Make cmake 3.12 the minimum version
[ https://issues.apache.org/jira/browse/GEODE-6022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-6022: -- Labels: pull-request-available (was: ) > Make cmake 3.12 the minimum version > --- > > Key: GEODE-6022 > URL: https://issues.apache.org/jira/browse/GEODE-6022 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Michael Martell >Priority: Major > Labels: pull-request-available > > A number of projects in the clicache now use DOTNET_TARTET_FRAMEWORK to > specify which version of the .NET framework to use. The cmake minimum should > be changed from 3.10 to 3.12 in all CMakeLists.txt files. > > Also, the BUILDING.md should also be changed accordingly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-6023) synchronization on non-final variable
[
https://issues.apache.org/jira/browse/GEODE-6023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce Schuchardt reassigned GEODE-6023:
---
Assignee: Bruce Schuchardt
> synchronization on non-final variable
> -
>
> Key: GEODE-6023
> URL: https://issues.apache.org/jira/browse/GEODE-6023
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
>Priority: Major
>
> The class SocketCloser synchronizes on a non-final boxed instance variable,
> "closed".
> {code}
> synchronized (closed) {
> if (!this.closed) {
> this.closed = true;
> } else {
> return;
> }
> }
> {code}
> This is probably okay but it's flagged as an ERROR by LGTM scans and we
> shouldn't be using auto-boxed variables in non-test code.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-6023) synchronization on non-final variable
Bruce Schuchardt created GEODE-6023:
---
Summary: synchronization on non-final variable
Key: GEODE-6023
URL: https://issues.apache.org/jira/browse/GEODE-6023
Project: Geode
Issue Type: Bug
Components: membership
Reporter: Bruce Schuchardt
The class SocketCloser synchronizes on a non-final boxed instance variable,
"closed".
{code}
synchronized (closed) {
if (!this.closed) {
this.closed = true;
} else {
return;
}
}
{code}
This is probably okay but it's flagged as an ERROR by LGTM scans and we
shouldn't be using auto-boxed variables in non-test code.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-6023) synchronization on non-final variable
[
https://issues.apache.org/jira/browse/GEODE-6023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16681695#comment-16681695
]
Bruce Schuchardt commented on GEODE-6023:
-
This synchronization was added in this commit, which should probably be
scrutinized for other synchronization issues:
{noformat}
commit be4551191a17b9f50169f375798785ab5373e975
Author: Udo Kohlmeyer
Date: Tue Aug 22 09:45:05 2017 -0700
GEODE-3416: Reduce synchronization blockages in SocketCloser. This now
closes #702
Remove synchronization blocks around HashMap. Replace that implementation
with simpler ThreadPool that is not unbounded and does not grow as the
number of remoteAddress (clients/peers) are added
{noformat}
> synchronization on non-final variable
> -
>
> Key: GEODE-6023
> URL: https://issues.apache.org/jira/browse/GEODE-6023
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
>Priority: Major
>
> The class SocketCloser synchronizes on a non-final boxed instance variable,
> "closed".
> {code}
> synchronized (closed) {
> if (!this.closed) {
> this.closed = true;
> } else {
> return;
> }
> }
> {code}
> This is probably okay but it's flagged as an ERROR by LGTM scans and we
> shouldn't be using auto-boxed variables in non-test code.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-6024) checkPom fails
[
https://issues.apache.org/jira/browse/GEODE-6024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-6024:
-
Description:
{noformat}
FAILURE: Build completed with 10 failures.
{noformat}{noformat}
1: Task failed with an exception.
---
* Where:
Script '/home/geode/geode/gradle/publish.gradle' line: 180
* What went wrong:
Execution failed for task ':geode-connectors:checkPom'.
> The geode-connectors pom-default.xml has changed. Verify dependencies.
When changes have been approved, copy :
cp
/home/geode/geode/geode-connectors/build/publications/maven/pom-default.xml
file:/home/geode/geode/geode-connectors/src/test/resources/expected-pom.xml
Removed Dependencies
--
{http://maven.apache.org/POM/4.0.0}dependency[attributes={};
value=[{http://maven.apache.org/POM/4.0.0}groupId[attributes={};
value=[org.apache.geode]],
{http://maven.apache.org/POM/4.0.0}artifactId[attributes={};
value=[geode-common]],
{http://maven.apache.org/POM/4.0.0}version[attributes={};
value=[1.8.0-SNAPSHOT]],
{http://maven.apache.org/POM/4.0.0}scope[attributes={}; value=[compile
{http://maven.apache.org/POM/4.0.0}dependency[attributes={};
value=[{http://maven.apache.org/POM/4.0.0}groupId[attributes={};
value=[org.apache.geode]],
{http://maven.apache.org/POM/4.0.0}artifactId[attributes={};
value=[geode-core]], {http://maven.apache.org/POM/4.0.0}version[attributes={};
value=[1.8.0-SNAPSHOT]],
{http://maven.apache.org/POM/4.0.0}scope[attributes={}; value=[compile
New Dependencies
--
{http://maven.apache.org/POM/4.0.0}dependency[attributes={};
value=[{http://maven.apache.org/POM/4.0.0}groupId[attributes={};
value=[org.apache.geode]],
{http://maven.apache.org/POM/4.0.0}artifactId[attributes={};
value=[geode-common]],
{http://maven.apache.org/POM/4.0.0}version[attributes={};
value=[1.9.0-SNAPSHOT]],
{http://maven.apache.org/POM/4.0.0}scope[attributes={}; value=[compile
{http://maven.apache.org/POM/4.0.0}dependency[attributes={};
value=[{http://maven.apache.org/POM/4.0.0}groupId[attributes={};
value=[org.apache.geode]],
{http://maven.apache.org/POM/4.0.0}artifactId[attributes={};
value=[geode-core]], {http://maven.apache.org/POM/4.0.0}version[attributes={};
value=[1.9.0-SNAPSHOT]],
{http://maven.apache.org/POM/4.0.0}scope[attributes={}; value=[compile
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug
option to get more log output. Run with --scan to get full insights.
==
{noformat}{noformat}
2: Task failed with an exception.
---
* Where:
Script '/home/geode/geode/gradle/publish.gradle' line: 180
* What went wrong:
Execution failed for task ':geode-cq:checkPom'.
> The geode-cq pom-default.xml has changed. Verify dependencies.
When changes have been approved, copy :
cp /home/geode/geode/geode-cq/build/publications/maven/pom-default.xml
file:/home/geode/geode/geode-cq/src/test/resources/expected-pom.xml
Removed Dependencies
--
{http://maven.apache.org/POM/4.0.0}dependency[attributes={};
value=[{http://maven.apache.org/POM/4.0.0}groupId[attributes={};
value=[org.apache.geode]],
{http://maven.apache.org/POM/4.0.0}artifactId[attributes={};
value=[geode-core]], {http://maven.apache.org/POM/4.0.0}version[attributes={};
value=[1.8.0-SNAPSHOT]],
{http://maven.apache.org/POM/4.0.0}scope[attributes={}; value=[compile
New Dependencies
--
{http://maven.apache.org/POM/4.0.0}dependency[attributes={};
value=[{http://maven.apache.org/POM/4.0.0}groupId[attributes={};
value=[org.apache.geode]],
{http://maven.apache.org/POM/4.0.0}artifactId[attributes={};
value=[geode-core]], {http://maven.apache.org/POM/4.0.0}version[attributes={};
value=[1.9.0-SNAPSHOT]],
{http://maven.apache.org/POM/4.0.0}scope[attributes={}; value=[compile
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug
option to get more log output. Run with --scan to get full insights.
==
{noformat}{noformat}
3: Task failed with an exception.
---
* Where:
Script '/home/geode/geode/gradle/publish.gradle' line: 180
* What went wrong:
Execution failed for task ':geode-dunit:checkPom'.
> The geode-dunit pom-default.xml has changed. Verify dependencies.
When changes have been approved, copy :
cp /home/geode/geode/geode-dunit/build/publications/maven/pom-default.xml
file:/home/geode/geode/geode-dunit/src/test/resources/expected-pom.xml
Removed Dependencies
--
{http://maven.apache.org/POM/4.0.0}dependency[attributes={};
value=[{http://maven.apache.org/POM/4.0.0}groupId[attributes={};
value=[org.apache.geode]],
{http://maven.apache.org/POM/4.0.0}artifactId[attributes={};
value=[geode-core]],
[jira] [Created] (GEODE-6024) checkPom fails
Kirk Lund created GEODE-6024:
Summary: checkPom fails
Key: GEODE-6024
URL: https://issues.apache.org/jira/browse/GEODE-6024
Project: Geode
Issue Type: Bug
Reporter: Kirk Lund
{noformat}
FAILURE: Build completed with 10 failures.
{noformat}{noformat}
1: Task failed with an exception.
---
* Where:
Script '/home/geode/geode/gradle/publish.gradle' line: 180
* What went wrong:
Execution failed for task ':geode-connectors:checkPom'.
> The geode-connectors pom-default.xml has changed. Verify dependencies.
When changes have been approved, copy :
cp
/home/geode/geode/geode-connectors/build/publications/maven/pom-default.xml
file:/home/geode/geode/geode-connectors/src/test/resources/expected-pom.xml
Removed Dependencies
--
{http://maven.apache.org/POM/4.0.0}dependency[attributes={};
value=[{http://maven.apache.org/POM/4.0.0}groupId[attributes={};
value=[org.apache.geode]],
{http://maven.apache.org/POM/4.0.0}artifactId[attributes={};
value=[geode-common]],
{http://maven.apache.org/POM/4.0.0}version[attributes={};
value=[1.8.0-SNAPSHOT]],
{http://maven.apache.org/POM/4.0.0}scope[attributes={}; value=[compile
{http://maven.apache.org/POM/4.0.0}dependency[attributes={};
value=[{http://maven.apache.org/POM/4.0.0}groupId[attributes={};
value=[org.apache.geode]],
{http://maven.apache.org/POM/4.0.0}artifactId[attributes={};
value=[geode-core]], {http://maven.apache.org/POM/4.0.0}version[attributes={};
value=[1.8.0-SNAPSHOT]],
{http://maven.apache.org/POM/4.0.0}scope[attributes={}; value=[compile
New Dependencies
--
{http://maven.apache.org/POM/4.0.0}dependency[attributes={};
value=[{http://maven.apache.org/POM/4.0.0}groupId[attributes={};
value=[org.apache.geode]],
{http://maven.apache.org/POM/4.0.0}artifactId[attributes={};
value=[geode-common]],
{http://maven.apache.org/POM/4.0.0}version[attributes={};
value=[1.9.0-SNAPSHOT]],
{http://maven.apache.org/POM/4.0.0}scope[attributes={}; value=[compile
{http://maven.apache.org/POM/4.0.0}dependency[attributes={};
value=[{http://maven.apache.org/POM/4.0.0}groupId[attributes={};
value=[org.apache.geode]],
{http://maven.apache.org/POM/4.0.0}artifactId[attributes={};
value=[geode-core]], {http://maven.apache.org/POM/4.0.0}version[attributes={};
value=[1.9.0-SNAPSHOT]],
{http://maven.apache.org/POM/4.0.0}scope[attributes={}; value=[compile
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug
option to get more log output. Run with --scan to get full insights.
==
{noformat}{noformat}
2: Task failed with an exception.
---
* Where:
Script '/home/geode/geode/gradle/publish.gradle' line: 180
* What went wrong:
Execution failed for task ':geode-cq:checkPom'.
> The geode-cq pom-default.xml has changed. Verify dependencies.
When changes have been approved, copy :
cp /home/geode/geode/geode-cq/build/publications/maven/pom-default.xml
file:/home/geode/geode/geode-cq/src/test/resources/expected-pom.xml
Removed Dependencies
--
{http://maven.apache.org/POM/4.0.0}dependency[attributes={};
value=[{http://maven.apache.org/POM/4.0.0}groupId[attributes={};
value=[org.apache.geode]],
{http://maven.apache.org/POM/4.0.0}artifactId[attributes={};
value=[geode-core]], {http://maven.apache.org/POM/4.0.0}version[attributes={};
value=[1.8.0-SNAPSHOT]],
{http://maven.apache.org/POM/4.0.0}scope[attributes={}; value=[compile
New Dependencies
--
{http://maven.apache.org/POM/4.0.0}dependency[attributes={};
value=[{http://maven.apache.org/POM/4.0.0}groupId[attributes={};
value=[org.apache.geode]],
{http://maven.apache.org/POM/4.0.0}artifactId[attributes={};
value=[geode-core]], {http://maven.apache.org/POM/4.0.0}version[attributes={};
value=[1.9.0-SNAPSHOT]],
{http://maven.apache.org/POM/4.0.0}scope[attributes={}; value=[compile
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug
option to get more log output. Run with --scan to get full insights.
==
{noformat}{noformat}
3: Task failed with an exception.
---
* Where:
Script '/home/geode/geode/gradle/publish.gradle' line: 180
* What went wrong:
Execution failed for task ':geode-dunit:checkPom'.
> The geode-dunit pom-default.xml has changed. Verify dependencies.
When changes have been approved, copy :
cp /home/geode/geode/geode-dunit/build/publications/maven/pom-default.xml
file:/home/geode/geode/geode-dunit/src/test/resources/expected-pom.xml
Removed Dependencies
--
{http://maven.apache.org/POM/4.0.0}dependency[attributes={};
value=[{http://maven.apache.org/POM/4.0.0}groupId[attributes={};
value=[org.apache.geode]]
[jira] [Updated] (GEODE-6024) Develop build fails due to checkPom (unknown dependency added)
[
https://issues.apache.org/jira/browse/GEODE-6024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-6024:
-
Summary: Develop build fails due to checkPom (unknown dependency added)
(was: checkPom fails )
> Develop build fails due to checkPom (unknown dependency added)
> --
>
> Key: GEODE-6024
> URL: https://issues.apache.org/jira/browse/GEODE-6024
> Project: Geode
> Issue Type: Bug
>Reporter: Kirk Lund
>Priority: Major
>
> {noformat}
> FAILURE: Build completed with 10 failures.
> {noformat}{noformat}
> 1: Task failed with an exception.
> ---
> * Where:
> Script '/home/geode/geode/gradle/publish.gradle' line: 180
> * What went wrong:
> Execution failed for task ':geode-connectors:checkPom'.
> > The geode-connectors pom-default.xml has changed. Verify dependencies.
> When changes have been approved, copy :
>cp
> /home/geode/geode/geode-connectors/build/publications/maven/pom-default.xml
> file:/home/geode/geode/geode-connectors/src/test/resources/expected-pom.xml
> Removed Dependencies
> --
> {http://maven.apache.org/POM/4.0.0}dependency[attributes={};
> value=[{http://maven.apache.org/POM/4.0.0}groupId[attributes={};
> value=[org.apache.geode]],
> {http://maven.apache.org/POM/4.0.0}artifactId[attributes={};
> value=[geode-common]],
> {http://maven.apache.org/POM/4.0.0}version[attributes={};
> value=[1.8.0-SNAPSHOT]],
> {http://maven.apache.org/POM/4.0.0}scope[attributes={}; value=[compile
> {http://maven.apache.org/POM/4.0.0}dependency[attributes={};
> value=[{http://maven.apache.org/POM/4.0.0}groupId[attributes={};
> value=[org.apache.geode]],
> {http://maven.apache.org/POM/4.0.0}artifactId[attributes={};
> value=[geode-core]],
> {http://maven.apache.org/POM/4.0.0}version[attributes={};
> value=[1.8.0-SNAPSHOT]],
> {http://maven.apache.org/POM/4.0.0}scope[attributes={}; value=[compile
>
> New Dependencies
> --
> {http://maven.apache.org/POM/4.0.0}dependency[attributes={};
> value=[{http://maven.apache.org/POM/4.0.0}groupId[attributes={};
> value=[org.apache.geode]],
> {http://maven.apache.org/POM/4.0.0}artifactId[attributes={};
> value=[geode-common]],
> {http://maven.apache.org/POM/4.0.0}version[attributes={};
> value=[1.9.0-SNAPSHOT]],
> {http://maven.apache.org/POM/4.0.0}scope[attributes={}; value=[compile
> {http://maven.apache.org/POM/4.0.0}dependency[attributes={};
> value=[{http://maven.apache.org/POM/4.0.0}groupId[attributes={};
> value=[org.apache.geode]],
> {http://maven.apache.org/POM/4.0.0}artifactId[attributes={};
> value=[geode-core]],
> {http://maven.apache.org/POM/4.0.0}version[attributes={};
> value=[1.9.0-SNAPSHOT]],
> {http://maven.apache.org/POM/4.0.0}scope[attributes={}; value=[compile
>
> * Try:
> Run with --stacktrace option to get the stack trace. Run with --info or
> --debug option to get more log output. Run with --scan to get full insights.
> ==
> {noformat}{noformat}
> 2: Task failed with an exception.
> ---
> * Where:
> Script '/home/geode/geode/gradle/publish.gradle' line: 180
> * What went wrong:
> Execution failed for task ':geode-cq:checkPom'.
> > The geode-cq pom-default.xml has changed. Verify dependencies.
> When changes have been approved, copy :
>cp /home/geode/geode/geode-cq/build/publications/maven/pom-default.xml
> file:/home/geode/geode/geode-cq/src/test/resources/expected-pom.xml
> Removed Dependencies
> --
> {http://maven.apache.org/POM/4.0.0}dependency[attributes={};
> value=[{http://maven.apache.org/POM/4.0.0}groupId[attributes={};
> value=[org.apache.geode]],
> {http://maven.apache.org/POM/4.0.0}artifactId[attributes={};
> value=[geode-core]],
> {http://maven.apache.org/POM/4.0.0}version[attributes={};
> value=[1.8.0-SNAPSHOT]],
> {http://maven.apache.org/POM/4.0.0}scope[attributes={}; value=[compile
>
> New Dependencies
> --
> {http://maven.apache.org/POM/4.0.0}dependency[attributes={};
> value=[{http://maven.apache.org/POM/4.0.0}groupId[attributes={};
> value=[org.apache.geode]],
> {http://maven.apache.org/POM/4.0.0}artifactId[attributes={};
> value=[geode-core]],
> {http://maven.apache.org/POM/4.0.0}version[attributes={};
> value=[1.9.0-SNAPSHOT]],
> {http://maven.apache.org/POM/4.0.0}scope[attributes={}; value=[compile
>
> * Try:
> Run with --stacktrace option to get the stack trace. Run with --info or
> --debug option to get more log output. Run with --scan to get full insights.
> ==
> {noformat}{noformat}
> 3: Task failed with an exception.
> ---
> * Where:
> Script '/home/geode/geode/gradle/pu
[jira] [Updated] (GEODE-6024) Develop build fails due to checkPom (unknown dependency added)
[
https://issues.apache.org/jira/browse/GEODE-6024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-6024:
-
Component/s: build
> Develop build fails due to checkPom (unknown dependency added)
> --
>
> Key: GEODE-6024
> URL: https://issues.apache.org/jira/browse/GEODE-6024
> Project: Geode
> Issue Type: Bug
> Components: build
>Reporter: Kirk Lund
>Priority: Major
>
> Well, I don't see anywhere in this what unexpected dependency was added. We
> should probably print out what the unexpected dependency is.
> {noformat}
> FAILURE: Build completed with 10 failures.
> {noformat}{noformat}
> 1: Task failed with an exception.
> ---
> * Where:
> Script '/home/geode/geode/gradle/publish.gradle' line: 180
> * What went wrong:
> Execution failed for task ':geode-connectors:checkPom'.
> > The geode-connectors pom-default.xml has changed. Verify dependencies.
> When changes have been approved, copy :
>cp
> /home/geode/geode/geode-connectors/build/publications/maven/pom-default.xml
> file:/home/geode/geode/geode-connectors/src/test/resources/expected-pom.xml
> Removed Dependencies
> --
> {http://maven.apache.org/POM/4.0.0}dependency[attributes={};
> value=[{http://maven.apache.org/POM/4.0.0}groupId[attributes={};
> value=[org.apache.geode]],
> {http://maven.apache.org/POM/4.0.0}artifactId[attributes={};
> value=[geode-common]],
> {http://maven.apache.org/POM/4.0.0}version[attributes={};
> value=[1.8.0-SNAPSHOT]],
> {http://maven.apache.org/POM/4.0.0}scope[attributes={}; value=[compile
> {http://maven.apache.org/POM/4.0.0}dependency[attributes={};
> value=[{http://maven.apache.org/POM/4.0.0}groupId[attributes={};
> value=[org.apache.geode]],
> {http://maven.apache.org/POM/4.0.0}artifactId[attributes={};
> value=[geode-core]],
> {http://maven.apache.org/POM/4.0.0}version[attributes={};
> value=[1.8.0-SNAPSHOT]],
> {http://maven.apache.org/POM/4.0.0}scope[attributes={}; value=[compile
>
> New Dependencies
> --
> {http://maven.apache.org/POM/4.0.0}dependency[attributes={};
> value=[{http://maven.apache.org/POM/4.0.0}groupId[attributes={};
> value=[org.apache.geode]],
> {http://maven.apache.org/POM/4.0.0}artifactId[attributes={};
> value=[geode-common]],
> {http://maven.apache.org/POM/4.0.0}version[attributes={};
> value=[1.9.0-SNAPSHOT]],
> {http://maven.apache.org/POM/4.0.0}scope[attributes={}; value=[compile
> {http://maven.apache.org/POM/4.0.0}dependency[attributes={};
> value=[{http://maven.apache.org/POM/4.0.0}groupId[attributes={};
> value=[org.apache.geode]],
> {http://maven.apache.org/POM/4.0.0}artifactId[attributes={};
> value=[geode-core]],
> {http://maven.apache.org/POM/4.0.0}version[attributes={};
> value=[1.9.0-SNAPSHOT]],
> {http://maven.apache.org/POM/4.0.0}scope[attributes={}; value=[compile
>
> * Try:
> Run with --stacktrace option to get the stack trace. Run with --info or
> --debug option to get more log output. Run with --scan to get full insights.
> ==
> {noformat}{noformat}
> 2: Task failed with an exception.
> ---
> * Where:
> Script '/home/geode/geode/gradle/publish.gradle' line: 180
> * What went wrong:
> Execution failed for task ':geode-cq:checkPom'.
> > The geode-cq pom-default.xml has changed. Verify dependencies.
> When changes have been approved, copy :
>cp /home/geode/geode/geode-cq/build/publications/maven/pom-default.xml
> file:/home/geode/geode/geode-cq/src/test/resources/expected-pom.xml
> Removed Dependencies
> --
> {http://maven.apache.org/POM/4.0.0}dependency[attributes={};
> value=[{http://maven.apache.org/POM/4.0.0}groupId[attributes={};
> value=[org.apache.geode]],
> {http://maven.apache.org/POM/4.0.0}artifactId[attributes={};
> value=[geode-core]],
> {http://maven.apache.org/POM/4.0.0}version[attributes={};
> value=[1.8.0-SNAPSHOT]],
> {http://maven.apache.org/POM/4.0.0}scope[attributes={}; value=[compile
>
> New Dependencies
> --
> {http://maven.apache.org/POM/4.0.0}dependency[attributes={};
> value=[{http://maven.apache.org/POM/4.0.0}groupId[attributes={};
> value=[org.apache.geode]],
> {http://maven.apache.org/POM/4.0.0}artifactId[attributes={};
> value=[geode-core]],
> {http://maven.apache.org/POM/4.0.0}version[attributes={};
> value=[1.9.0-SNAPSHOT]],
> {http://maven.apache.org/POM/4.0.0}scope[attributes={}; value=[compile
>
> * Try:
> Run with --stacktrace option to get the stack trace. Run with --info or
> --debug option to get more log output. Run with --scan to get full insights.
> ==
> {noformat}{noformat}
> 3:
[jira] [Updated] (GEODE-6024) Develop build fails due to checkPom (unknown dependency added)
[
https://issues.apache.org/jira/browse/GEODE-6024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-6024:
-
Description:
Well, I don't see anywhere in this what unexpected dependency was added. We
should probably print out what the unexpected dependency is.
{noformat}
FAILURE: Build completed with 10 failures.
{noformat}{noformat}
1: Task failed with an exception.
---
* Where:
Script '/home/geode/geode/gradle/publish.gradle' line: 180
* What went wrong:
Execution failed for task ':geode-connectors:checkPom'.
> The geode-connectors pom-default.xml has changed. Verify dependencies.
When changes have been approved, copy :
cp
/home/geode/geode/geode-connectors/build/publications/maven/pom-default.xml
file:/home/geode/geode/geode-connectors/src/test/resources/expected-pom.xml
Removed Dependencies
--
{http://maven.apache.org/POM/4.0.0}dependency[attributes={};
value=[{http://maven.apache.org/POM/4.0.0}groupId[attributes={};
value=[org.apache.geode]],
{http://maven.apache.org/POM/4.0.0}artifactId[attributes={};
value=[geode-common]],
{http://maven.apache.org/POM/4.0.0}version[attributes={};
value=[1.8.0-SNAPSHOT]],
{http://maven.apache.org/POM/4.0.0}scope[attributes={}; value=[compile
{http://maven.apache.org/POM/4.0.0}dependency[attributes={};
value=[{http://maven.apache.org/POM/4.0.0}groupId[attributes={};
value=[org.apache.geode]],
{http://maven.apache.org/POM/4.0.0}artifactId[attributes={};
value=[geode-core]], {http://maven.apache.org/POM/4.0.0}version[attributes={};
value=[1.8.0-SNAPSHOT]],
{http://maven.apache.org/POM/4.0.0}scope[attributes={}; value=[compile
New Dependencies
--
{http://maven.apache.org/POM/4.0.0}dependency[attributes={};
value=[{http://maven.apache.org/POM/4.0.0}groupId[attributes={};
value=[org.apache.geode]],
{http://maven.apache.org/POM/4.0.0}artifactId[attributes={};
value=[geode-common]],
{http://maven.apache.org/POM/4.0.0}version[attributes={};
value=[1.9.0-SNAPSHOT]],
{http://maven.apache.org/POM/4.0.0}scope[attributes={}; value=[compile
{http://maven.apache.org/POM/4.0.0}dependency[attributes={};
value=[{http://maven.apache.org/POM/4.0.0}groupId[attributes={};
value=[org.apache.geode]],
{http://maven.apache.org/POM/4.0.0}artifactId[attributes={};
value=[geode-core]], {http://maven.apache.org/POM/4.0.0}version[attributes={};
value=[1.9.0-SNAPSHOT]],
{http://maven.apache.org/POM/4.0.0}scope[attributes={}; value=[compile
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug
option to get more log output. Run with --scan to get full insights.
==
{noformat}{noformat}
2: Task failed with an exception.
---
* Where:
Script '/home/geode/geode/gradle/publish.gradle' line: 180
* What went wrong:
Execution failed for task ':geode-cq:checkPom'.
> The geode-cq pom-default.xml has changed. Verify dependencies.
When changes have been approved, copy :
cp /home/geode/geode/geode-cq/build/publications/maven/pom-default.xml
file:/home/geode/geode/geode-cq/src/test/resources/expected-pom.xml
Removed Dependencies
--
{http://maven.apache.org/POM/4.0.0}dependency[attributes={};
value=[{http://maven.apache.org/POM/4.0.0}groupId[attributes={};
value=[org.apache.geode]],
{http://maven.apache.org/POM/4.0.0}artifactId[attributes={};
value=[geode-core]], {http://maven.apache.org/POM/4.0.0}version[attributes={};
value=[1.8.0-SNAPSHOT]],
{http://maven.apache.org/POM/4.0.0}scope[attributes={}; value=[compile
New Dependencies
--
{http://maven.apache.org/POM/4.0.0}dependency[attributes={};
value=[{http://maven.apache.org/POM/4.0.0}groupId[attributes={};
value=[org.apache.geode]],
{http://maven.apache.org/POM/4.0.0}artifactId[attributes={};
value=[geode-core]], {http://maven.apache.org/POM/4.0.0}version[attributes={};
value=[1.9.0-SNAPSHOT]],
{http://maven.apache.org/POM/4.0.0}scope[attributes={}; value=[compile
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug
option to get more log output. Run with --scan to get full insights.
==
{noformat}{noformat}
3: Task failed with an exception.
---
* Where:
Script '/home/geode/geode/gradle/publish.gradle' line: 180
* What went wrong:
Execution failed for task ':geode-dunit:checkPom'.
> The geode-dunit pom-default.xml has changed. Verify dependencies.
When changes have been approved, copy :
cp /home/geode/geode/geode-dunit/build/publications/maven/pom-default.xml
file:/home/geode/geode/geode-dunit/src/test/resources/expected-pom.xml
Removed Dependencies
--
{http://maven.apache.org/POM/4.0.0}dependency[attributes={};
value=[{http://maven.apache.org/POM/4.0.
[jira] [Assigned] (GEODE-6024) Develop build fails due to checkPom (unknown dependency added)
[
https://issues.apache.org/jira/browse/GEODE-6024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund reassigned GEODE-6024:
Assignee: Anthony Baker
> Develop build fails due to checkPom (unknown dependency added)
> --
>
> Key: GEODE-6024
> URL: https://issues.apache.org/jira/browse/GEODE-6024
> Project: Geode
> Issue Type: Bug
> Components: build
>Reporter: Kirk Lund
>Assignee: Anthony Baker
>Priority: Major
>
> Well, I don't see anywhere in this what unexpected dependency was added. We
> should probably print out what the unexpected dependency is.
> {noformat}
> FAILURE: Build completed with 10 failures.
> {noformat}{noformat}
> 1: Task failed with an exception.
> ---
> * Where:
> Script '/home/geode/geode/gradle/publish.gradle' line: 180
> * What went wrong:
> Execution failed for task ':geode-connectors:checkPom'.
> > The geode-connectors pom-default.xml has changed. Verify dependencies.
> When changes have been approved, copy :
>cp
> /home/geode/geode/geode-connectors/build/publications/maven/pom-default.xml
> file:/home/geode/geode/geode-connectors/src/test/resources/expected-pom.xml
> Removed Dependencies
> --
> {http://maven.apache.org/POM/4.0.0}dependency[attributes={};
> value=[{http://maven.apache.org/POM/4.0.0}groupId[attributes={};
> value=[org.apache.geode]],
> {http://maven.apache.org/POM/4.0.0}artifactId[attributes={};
> value=[geode-common]],
> {http://maven.apache.org/POM/4.0.0}version[attributes={};
> value=[1.8.0-SNAPSHOT]],
> {http://maven.apache.org/POM/4.0.0}scope[attributes={}; value=[compile
> {http://maven.apache.org/POM/4.0.0}dependency[attributes={};
> value=[{http://maven.apache.org/POM/4.0.0}groupId[attributes={};
> value=[org.apache.geode]],
> {http://maven.apache.org/POM/4.0.0}artifactId[attributes={};
> value=[geode-core]],
> {http://maven.apache.org/POM/4.0.0}version[attributes={};
> value=[1.8.0-SNAPSHOT]],
> {http://maven.apache.org/POM/4.0.0}scope[attributes={}; value=[compile
>
> New Dependencies
> --
> {http://maven.apache.org/POM/4.0.0}dependency[attributes={};
> value=[{http://maven.apache.org/POM/4.0.0}groupId[attributes={};
> value=[org.apache.geode]],
> {http://maven.apache.org/POM/4.0.0}artifactId[attributes={};
> value=[geode-common]],
> {http://maven.apache.org/POM/4.0.0}version[attributes={};
> value=[1.9.0-SNAPSHOT]],
> {http://maven.apache.org/POM/4.0.0}scope[attributes={}; value=[compile
> {http://maven.apache.org/POM/4.0.0}dependency[attributes={};
> value=[{http://maven.apache.org/POM/4.0.0}groupId[attributes={};
> value=[org.apache.geode]],
> {http://maven.apache.org/POM/4.0.0}artifactId[attributes={};
> value=[geode-core]],
> {http://maven.apache.org/POM/4.0.0}version[attributes={};
> value=[1.9.0-SNAPSHOT]],
> {http://maven.apache.org/POM/4.0.0}scope[attributes={}; value=[compile
>
> * Try:
> Run with --stacktrace option to get the stack trace. Run with --info or
> --debug option to get more log output. Run with --scan to get full insights.
> ==
> {noformat}{noformat}
> 2: Task failed with an exception.
> ---
> * Where:
> Script '/home/geode/geode/gradle/publish.gradle' line: 180
> * What went wrong:
> Execution failed for task ':geode-cq:checkPom'.
> > The geode-cq pom-default.xml has changed. Verify dependencies.
> When changes have been approved, copy :
>cp /home/geode/geode/geode-cq/build/publications/maven/pom-default.xml
> file:/home/geode/geode/geode-cq/src/test/resources/expected-pom.xml
> Removed Dependencies
> --
> {http://maven.apache.org/POM/4.0.0}dependency[attributes={};
> value=[{http://maven.apache.org/POM/4.0.0}groupId[attributes={};
> value=[org.apache.geode]],
> {http://maven.apache.org/POM/4.0.0}artifactId[attributes={};
> value=[geode-core]],
> {http://maven.apache.org/POM/4.0.0}version[attributes={};
> value=[1.8.0-SNAPSHOT]],
> {http://maven.apache.org/POM/4.0.0}scope[attributes={}; value=[compile
>
> New Dependencies
> --
> {http://maven.apache.org/POM/4.0.0}dependency[attributes={};
> value=[{http://maven.apache.org/POM/4.0.0}groupId[attributes={};
> value=[org.apache.geode]],
> {http://maven.apache.org/POM/4.0.0}artifactId[attributes={};
> value=[geode-core]],
> {http://maven.apache.org/POM/4.0.0}version[attributes={};
> value=[1.9.0-SNAPSHOT]],
> {http://maven.apache.org/POM/4.0.0}scope[attributes={}; value=[compile
>
> * Try:
> Run with --stacktrace option to get the stack trace. Run with --info or
> --debug option to get more log output. Run with --scan to get full insights.
> ==
[jira] [Created] (GEODE-6025) Add 'describe data-source' gfsh command
Benjamin Perry Ross created GEODE-6025:
--
Summary: Add 'describe data-source' gfsh command
Key: GEODE-6025
URL: https://issues.apache.org/jira/browse/GEODE-6025
Project: Geode
Issue Type: New Feature
Components: gfsh
Reporter: Benjamin Perry Ross
Given the recent addition of the alias {{create data-source}} for {{create
jndi-binding}} we want to add a matching alias command for {{describe
jndi-binding}}. The resulting command should be called {{describe data-source}}
and should behave the same as the {{describe jndi-binding}} command.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-6024) Develop build fails due to checkPom (unknown dependency added)
[
https://issues.apache.org/jira/browse/GEODE-6024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16681782#comment-16681782
]
Anthony Baker commented on GEODE-6024:
--
The problem is over-constrained tests. Bumping the build version causes this
failure (although {{checkPom}} doesn't seem to run consistently). IMO, we need
to relax the constraint in tests that check against an exact version of geode
in poms and classpath and assembly content. That is not adding any value and
is creating huge burden whenever the version number is incremented, both in
release branches and on develop.
Anyway, this change is reverted for now.
> Develop build fails due to checkPom (unknown dependency added)
> --
>
> Key: GEODE-6024
> URL: https://issues.apache.org/jira/browse/GEODE-6024
> Project: Geode
> Issue Type: Bug
> Components: build
>Reporter: Kirk Lund
>Assignee: Anthony Baker
>Priority: Major
>
> Well, I don't see anywhere in this what unexpected dependency was added. We
> should probably print out what the unexpected dependency is.
> {noformat}
> FAILURE: Build completed with 10 failures.
> {noformat}{noformat}
> 1: Task failed with an exception.
> ---
> * Where:
> Script '/home/geode/geode/gradle/publish.gradle' line: 180
> * What went wrong:
> Execution failed for task ':geode-connectors:checkPom'.
> > The geode-connectors pom-default.xml has changed. Verify dependencies.
> When changes have been approved, copy :
>cp
> /home/geode/geode/geode-connectors/build/publications/maven/pom-default.xml
> file:/home/geode/geode/geode-connectors/src/test/resources/expected-pom.xml
> Removed Dependencies
> --
> {http://maven.apache.org/POM/4.0.0}dependency[attributes={};
> value=[{http://maven.apache.org/POM/4.0.0}groupId[attributes={};
> value=[org.apache.geode]],
> {http://maven.apache.org/POM/4.0.0}artifactId[attributes={};
> value=[geode-common]],
> {http://maven.apache.org/POM/4.0.0}version[attributes={};
> value=[1.8.0-SNAPSHOT]],
> {http://maven.apache.org/POM/4.0.0}scope[attributes={}; value=[compile
> {http://maven.apache.org/POM/4.0.0}dependency[attributes={};
> value=[{http://maven.apache.org/POM/4.0.0}groupId[attributes={};
> value=[org.apache.geode]],
> {http://maven.apache.org/POM/4.0.0}artifactId[attributes={};
> value=[geode-core]],
> {http://maven.apache.org/POM/4.0.0}version[attributes={};
> value=[1.8.0-SNAPSHOT]],
> {http://maven.apache.org/POM/4.0.0}scope[attributes={}; value=[compile
>
> New Dependencies
> --
> {http://maven.apache.org/POM/4.0.0}dependency[attributes={};
> value=[{http://maven.apache.org/POM/4.0.0}groupId[attributes={};
> value=[org.apache.geode]],
> {http://maven.apache.org/POM/4.0.0}artifactId[attributes={};
> value=[geode-common]],
> {http://maven.apache.org/POM/4.0.0}version[attributes={};
> value=[1.9.0-SNAPSHOT]],
> {http://maven.apache.org/POM/4.0.0}scope[attributes={}; value=[compile
> {http://maven.apache.org/POM/4.0.0}dependency[attributes={};
> value=[{http://maven.apache.org/POM/4.0.0}groupId[attributes={};
> value=[org.apache.geode]],
> {http://maven.apache.org/POM/4.0.0}artifactId[attributes={};
> value=[geode-core]],
> {http://maven.apache.org/POM/4.0.0}version[attributes={};
> value=[1.9.0-SNAPSHOT]],
> {http://maven.apache.org/POM/4.0.0}scope[attributes={}; value=[compile
>
> * Try:
> Run with --stacktrace option to get the stack trace. Run with --info or
> --debug option to get more log output. Run with --scan to get full insights.
> ==
> {noformat}{noformat}
> 2: Task failed with an exception.
> ---
> * Where:
> Script '/home/geode/geode/gradle/publish.gradle' line: 180
> * What went wrong:
> Execution failed for task ':geode-cq:checkPom'.
> > The geode-cq pom-default.xml has changed. Verify dependencies.
> When changes have been approved, copy :
>cp /home/geode/geode/geode-cq/build/publications/maven/pom-default.xml
> file:/home/geode/geode/geode-cq/src/test/resources/expected-pom.xml
> Removed Dependencies
> --
> {http://maven.apache.org/POM/4.0.0}dependency[attributes={};
> value=[{http://maven.apache.org/POM/4.0.0}groupId[attributes={};
> value=[org.apache.geode]],
> {http://maven.apache.org/POM/4.0.0}artifactId[attributes={};
> value=[geode-core]],
> {http://maven.apache.org/POM/4.0.0}version[attributes={};
> value=[1.8.0-SNAPSHOT]],
> {http://maven.apache.org/POM/4.0.0}scope[attributes={}; value=[compile
>
> New Dependencies
> --
> {http://maven.apache.org/POM/4.0.0}dependency[attributes={};
> value=[{http://maven.apache.org/POM/4.0.0}groupId[attributes={};
> value=[or
[jira] [Resolved] (GEODE-6024) Develop build fails due to checkPom (unknown dependency added)
[
https://issues.apache.org/jira/browse/GEODE-6024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker resolved GEODE-6024.
--
Resolution: Fixed
> Develop build fails due to checkPom (unknown dependency added)
> --
>
> Key: GEODE-6024
> URL: https://issues.apache.org/jira/browse/GEODE-6024
> Project: Geode
> Issue Type: Bug
> Components: build
>Reporter: Kirk Lund
>Assignee: Anthony Baker
>Priority: Major
>
> Well, I don't see anywhere in this what unexpected dependency was added. We
> should probably print out what the unexpected dependency is.
> {noformat}
> FAILURE: Build completed with 10 failures.
> {noformat}{noformat}
> 1: Task failed with an exception.
> ---
> * Where:
> Script '/home/geode/geode/gradle/publish.gradle' line: 180
> * What went wrong:
> Execution failed for task ':geode-connectors:checkPom'.
> > The geode-connectors pom-default.xml has changed. Verify dependencies.
> When changes have been approved, copy :
>cp
> /home/geode/geode/geode-connectors/build/publications/maven/pom-default.xml
> file:/home/geode/geode/geode-connectors/src/test/resources/expected-pom.xml
> Removed Dependencies
> --
> {http://maven.apache.org/POM/4.0.0}dependency[attributes={};
> value=[{http://maven.apache.org/POM/4.0.0}groupId[attributes={};
> value=[org.apache.geode]],
> {http://maven.apache.org/POM/4.0.0}artifactId[attributes={};
> value=[geode-common]],
> {http://maven.apache.org/POM/4.0.0}version[attributes={};
> value=[1.8.0-SNAPSHOT]],
> {http://maven.apache.org/POM/4.0.0}scope[attributes={}; value=[compile
> {http://maven.apache.org/POM/4.0.0}dependency[attributes={};
> value=[{http://maven.apache.org/POM/4.0.0}groupId[attributes={};
> value=[org.apache.geode]],
> {http://maven.apache.org/POM/4.0.0}artifactId[attributes={};
> value=[geode-core]],
> {http://maven.apache.org/POM/4.0.0}version[attributes={};
> value=[1.8.0-SNAPSHOT]],
> {http://maven.apache.org/POM/4.0.0}scope[attributes={}; value=[compile
>
> New Dependencies
> --
> {http://maven.apache.org/POM/4.0.0}dependency[attributes={};
> value=[{http://maven.apache.org/POM/4.0.0}groupId[attributes={};
> value=[org.apache.geode]],
> {http://maven.apache.org/POM/4.0.0}artifactId[attributes={};
> value=[geode-common]],
> {http://maven.apache.org/POM/4.0.0}version[attributes={};
> value=[1.9.0-SNAPSHOT]],
> {http://maven.apache.org/POM/4.0.0}scope[attributes={}; value=[compile
> {http://maven.apache.org/POM/4.0.0}dependency[attributes={};
> value=[{http://maven.apache.org/POM/4.0.0}groupId[attributes={};
> value=[org.apache.geode]],
> {http://maven.apache.org/POM/4.0.0}artifactId[attributes={};
> value=[geode-core]],
> {http://maven.apache.org/POM/4.0.0}version[attributes={};
> value=[1.9.0-SNAPSHOT]],
> {http://maven.apache.org/POM/4.0.0}scope[attributes={}; value=[compile
>
> * Try:
> Run with --stacktrace option to get the stack trace. Run with --info or
> --debug option to get more log output. Run with --scan to get full insights.
> ==
> {noformat}{noformat}
> 2: Task failed with an exception.
> ---
> * Where:
> Script '/home/geode/geode/gradle/publish.gradle' line: 180
> * What went wrong:
> Execution failed for task ':geode-cq:checkPom'.
> > The geode-cq pom-default.xml has changed. Verify dependencies.
> When changes have been approved, copy :
>cp /home/geode/geode/geode-cq/build/publications/maven/pom-default.xml
> file:/home/geode/geode/geode-cq/src/test/resources/expected-pom.xml
> Removed Dependencies
> --
> {http://maven.apache.org/POM/4.0.0}dependency[attributes={};
> value=[{http://maven.apache.org/POM/4.0.0}groupId[attributes={};
> value=[org.apache.geode]],
> {http://maven.apache.org/POM/4.0.0}artifactId[attributes={};
> value=[geode-core]],
> {http://maven.apache.org/POM/4.0.0}version[attributes={};
> value=[1.8.0-SNAPSHOT]],
> {http://maven.apache.org/POM/4.0.0}scope[attributes={}; value=[compile
>
> New Dependencies
> --
> {http://maven.apache.org/POM/4.0.0}dependency[attributes={};
> value=[{http://maven.apache.org/POM/4.0.0}groupId[attributes={};
> value=[org.apache.geode]],
> {http://maven.apache.org/POM/4.0.0}artifactId[attributes={};
> value=[geode-core]],
> {http://maven.apache.org/POM/4.0.0}version[attributes={};
> value=[1.9.0-SNAPSHOT]],
> {http://maven.apache.org/POM/4.0.0}scope[attributes={}; value=[compile
>
> * Try:
> Run with --stacktrace option to get the stack trace. Run with --info or
> --debug option to get more log output. Run with --scan to get full insights.
> =
[jira] [Commented] (GEODE-6012) Invalid package listed in Dockerfile
[ https://issues.apache.org/jira/browse/GEODE-6012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16681791#comment-16681791 ] ASF subversion and git services commented on GEODE-6012: Commit 5cb8443c2cd861e986821cf8e0f1b86d27ce9a10 in geode-native's branch refs/heads/develop from [~igodwin] [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=5cb8443 ] GEODE-6012: Corrected package name in Dockerfile (#395) - libc++api-dev (non-existent) changed to libc++abi-dev > Invalid package listed in Dockerfile > > > Key: GEODE-6012 > URL: https://issues.apache.org/jira/browse/GEODE-6012 > Project: Geode > Issue Type: Task > Components: native client >Reporter: Ivan Godwin >Priority: Major > Labels: pull-request-available > Time Spent: 40m > Remaining Estimate: 0h > > The current version of docker/Dockerfile lists libc+\+api-dev as one of the > packages to be installed. This package does not exist, and prevents an image > from being built. The entry needs to be replaced with the intended package > name, libc++abi-dev. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (GEODE-5943) EvictionDUnitTest failed in jdk11
[
https://issues.apache.org/jira/browse/GEODE-5943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund reopened GEODE-5943:
--
This test has failed in DistributedTestOpenJDK8 #98
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/98
{noformat}
org.apache.geode.internal.cache.eviction.EvictionDUnitTest >
testDummyInlineNCentralizedEviction[offHeap=false] FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.internal.cache.eviction.EvictionDUnitTest$$Lambda$58/1839308999.call
in VM 0 running on Host a7d4026cfc8d with 4 VMs
at org.apache.geode.test.dunit.VM.invoke(VM.java:433)
at org.apache.geode.test.dunit.VM.invoke(VM.java:402)
at org.apache.geode.test.dunit.VM.invoke(VM.java:384)
at
org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:74)
at
org.apache.geode.internal.cache.eviction.EvictionDUnitTest.testDummyInlineNCentralizedEviction(EvictionDUnitTest.java:124)
Caused by:
org.awaitility.core.ConditionTimeoutException: Condition with lambda
expression in org.apache.geode.internal.cache.eviction.EvictionDUnitTest that
uses org.apache.geode.internal.cache.LocalRegion,
org.apache.geode.internal.cache.LocalRegionint 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:890)
at
org.awaitility.core.ConditionFactory.until(ConditionFactory.java:848)
at
org.apache.geode.internal.cache.eviction.EvictionDUnitTest.sendEventAndWaitForExpectedEviction(EvictionDUnitTest.java:249)
at
org.apache.geode.internal.cache.eviction.EvictionDUnitTest.lambda$testDummyInlineNCentralizedEviction$b8b59e6f$1(EvictionDUnitTest.java:124)
{noformat}
> EvictionDUnitTest failed in jdk11
> -
>
> Key: GEODE-5943
> URL: https://issues.apache.org/jira/browse/GEODE-5943
> Project: Geode
> Issue Type: Sub-task
>Reporter: Jinmei Liao
>Assignee: Jinmei Liao
>Priority: Major
> Labels: pull-request-available
> Time Spent: 2h
> Remaining Estimate: 0h
>
> org.apache.geode.internal.cache.eviction.EvictionDUnitTest >
> testDummyInlineNCentralizedEviction FAILED
> java.lang.AssertionError: expected:<8> but was:<6>
> 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.eviction.EvictionTestBase.validateNoOfEvictions(EvictionTestBase.java:405)
> at
> org.apache.geode.internal.cache.eviction.EvictionDUnitTest.testDummyInlineNCentralizedEviction(EvictionDUnitTest.java:49)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-6026) Lucene test classes should not be listed in Javadocs
Diane Hardman created GEODE-6026: Summary: Lucene test classes should not be listed in Javadocs Key: GEODE-6026 URL: https://issues.apache.org/jira/browse/GEODE-6026 Project: Geode Issue Type: Bug Components: lucene Reporter: Diane Hardman Fix For: 1.7.0 In the latest Javadocs for Lucene there are several test classes and utilities listed that should not be: package org.apache.geode.cache.lucene.test under package org.apache.geode.cache.lucene Class Summary: * DummyLuceneSerializer * LuceneIntegrationTest -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-3967) if put hits concurrent modification exception should still notify serial gateway sender
[ https://issues.apache.org/jira/browse/GEODE-3967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diane Hardman resolved GEODE-3967. -- My mistake, this should not have been reopened. > if put hits concurrent modification exception should still notify serial > gateway sender > --- > > Key: GEODE-3967 > URL: https://issues.apache.org/jira/browse/GEODE-3967 > Project: Geode > Issue Type: Bug > Components: wan >Reporter: xiaojian zhou >Assignee: xiaojian zhou >Priority: Major > Labels: pull-request-available > Fix For: 1.5.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > In serial gateway sender, the event arrives at secondary will be put into > unprocessedMap and wait for event from primary queue to distribute over, then > remove it from the unprocessedMap. > If the put at primary member (member with primary queue) failed with CME, the > event in unprocessedMap will never be removed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-6025) Add 'describe data-source' gfsh command
[
https://issues.apache.org/jira/browse/GEODE-6025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jianxia Chen reassigned GEODE-6025:
---
Assignee: Benjamin P Ross
> Add 'describe data-source' gfsh command
> ---
>
> Key: GEODE-6025
> URL: https://issues.apache.org/jira/browse/GEODE-6025
> Project: Geode
> Issue Type: New Feature
> Components: gfsh
>Reporter: Benjamin Perry Ross
>Assignee: Benjamin P Ross
>Priority: Major
>
> Given the recent addition of the alias {{create data-source}} for {{create
> jndi-binding}} we want to add a matching alias command for {{describe
> jndi-binding}}. The resulting command should be called {{describe
> data-source}} and should behave the same as the {{describe jndi-binding}}
> command.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-6021) Introducing Lombok
[ https://issues.apache.org/jira/browse/GEODE-6021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-6021: -- Labels: pull-request-available (was: ) > Introducing Lombok > -- > > Key: GEODE-6021 > URL: https://issues.apache.org/jira/browse/GEODE-6021 > Project: Geode > Issue Type: Improvement >Reporter: Aditya Anchuri >Priority: Major > Labels: pull-request-available > > Want to introduce Lombok into the Geode code. [https://projectlombok.org/] > We see the following advantages of using Lombok: > -> Less boilerplate code, reduces the size of some classes significantly. > -> Can use builder pattern implicitly, which allows for much better > composeability of an object. > -> Increased readability > More details: [https://projectlombok.org/features/all > ]PR: https://github.com/apache/geode/pull/2815 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-5379) affinityRetryCount should not be reseted after executeOnServer successfully
[ https://issues.apache.org/jira/browse/GEODE-5379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu resolved GEODE-5379. - Resolution: Fixed Fix Version/s: 1.7.0 > affinityRetryCount should not be reseted after executeOnServer successfully > > > Key: GEODE-5379 > URL: https://issues.apache.org/jira/browse/GEODE-5379 > Project: Geode > Issue Type: Bug > Components: transactions >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Currently affinityRetryCount is reseted after executeOnServer successfully in > executeWithServerAffinity. This is wrong, as TXFailoverOp executed after > server connection failure can succeed and reset the affinityRetryCount. This > could leads to StackOverflowError. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-3416) Reduce blocking for SocketCloser.asyncClose
[ https://issues.apache.org/jira/browse/GEODE-3416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16681802#comment-16681802 ] ASF subversion and git services commented on GEODE-3416: Commit 3b2ff449f057c20166470c41da07aa274d2ae2ad in geode's branch refs/heads/develop from [~bschuchardt] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=3b2ff44 ] GEODE-3416 Reduce synchronization blockages in SocketCreator Fixing LGTM complaint about synch on auto-boxed variable > Reduce blocking for SocketCloser.asyncClose > > > Key: GEODE-3416 > URL: https://issues.apache.org/jira/browse/GEODE-3416 > Project: Geode > Issue Type: Bug > Components: client/server >Affects Versions: 1.1.0, 1.1.1, 1.2.0, 1.2.1 >Reporter: Udo Kohlmeyer >Assignee: Udo Kohlmeyer >Priority: Major > Fix For: 1.3.0 > > > In the SocketCloser.asyncClose method, there is a synchronization block > around at HashMap. This synchronization will cause an effective > single-threaded processing capability when closing sockets. this effect > becomes more evident with a high number of clients. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5998) Redis adapter: add geospatial operations
[ https://issues.apache.org/jira/browse/GEODE-5998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16681808#comment-16681808 ] ASF subversion and git services commented on GEODE-5998: Commit b03f8f64c0c025440b502d0e9dadd57b78e3d7bb in geode's branch refs/heads/feature/GEODE-5998 from [~bschuchardt] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=b03f8f6 ] GEODE-5998 geospatial support Fixing LGTM complaints > Redis adapter: add geospatial operations > > > Key: GEODE-5998 > URL: https://issues.apache.org/jira/browse/GEODE-5998 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Galen O'Sullivan >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > Time Spent: 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6027) Separate ConfigObject from the ResultModel for configuration persistence
Kenneth Howe created GEODE-6027:
---
Summary: Separate ConfigObject from the ResultModel for
configuration persistence
Key: GEODE-6027
URL: https://issues.apache.org/jira/browse/GEODE-6027
Project: Geode
Issue Type: Improvement
Components: gfsh
Reporter: Kenneth Howe
Evolving the {{CommandExector}} class/workflow; as we're refactoring more
classes, making the following changes seems appropriate:
- Have {{updateClusterConfig}} return a boolean value indicating whether a
change was made or not
- Have {{updateClusterConfig}} receive the {{ResultModel}} as input
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-6027) Separate ConfigObject from the ResultModel for configuration persistence
[
https://issues.apache.org/jira/browse/GEODE-6027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe reassigned GEODE-6027:
---
Assignee: Kenneth Howe
> Separate ConfigObject from the ResultModel for configuration persistence
>
>
> Key: GEODE-6027
> URL: https://issues.apache.org/jira/browse/GEODE-6027
> Project: Geode
> Issue Type: Improvement
> Components: gfsh
>Reporter: Kenneth Howe
>Assignee: Kenneth Howe
>Priority: Major
>
> Evolving the {{CommandExector}} class/workflow; as we're refactoring more
> classes, making the following changes seems appropriate:
> - Have {{updateClusterConfig}} return a boolean value indicating whether a
> change was made or not
> - Have {{updateClusterConfig}} receive the {{ResultModel}} as input
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-6027) Separate ConfigObject from the ResultModel for configuration persistence
[
https://issues.apache.org/jira/browse/GEODE-6027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-6027:
--
Labels: pull-request-available (was: )
> Separate ConfigObject from the ResultModel for configuration persistence
>
>
> Key: GEODE-6027
> URL: https://issues.apache.org/jira/browse/GEODE-6027
> Project: Geode
> Issue Type: Improvement
> Components: gfsh
>Reporter: Kenneth Howe
>Assignee: Kenneth Howe
>Priority: Major
> Labels: pull-request-available
>
> Evolving the {{CommandExector}} class/workflow; as we're refactoring more
> classes, making the following changes seems appropriate:
> - Have {{updateClusterConfig}} return a boolean value indicating whether a
> change was made or not
> - Have {{updateClusterConfig}} receive the {{ResultModel}} as input
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5998) Redis adapter: add geospatial operations
[ https://issues.apache.org/jira/browse/GEODE-5998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16681849#comment-16681849 ] ASF subversion and git services commented on GEODE-5998: Commit 4ec514c362d77a45730fdd2080a318db0814cd96 in geode's branch refs/heads/feature/GEODE-5998b from [~bschuchardt] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=4ec514c ] GEODE-5998 geospatial support Fixing LGTM issues > Redis adapter: add geospatial operations > > > Key: GEODE-5998 > URL: https://issues.apache.org/jira/browse/GEODE-5998 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Galen O'Sullivan >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6028) Remove unnecessary comparison checks in the code.
nabarun created GEODE-6028: -- Summary: Remove unnecessary comparison checks in the code. Key: GEODE-6028 URL: https://issues.apache.org/jira/browse/GEODE-6028 Project: Geode Issue Type: Bug Reporter: nabarun Remove unnecessary checks in the code. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-6029) Add Unit test for DescribeJndiBindingCommand
[ https://issues.apache.org/jira/browse/GEODE-6029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin P Ross reassigned GEODE-6029: -- Assignee: Benjamin P Ross > Add Unit test for DescribeJndiBindingCommand > > > Key: GEODE-6029 > URL: https://issues.apache.org/jira/browse/GEODE-6029 > Project: Geode > Issue Type: Improvement > Components: gfsh >Reporter: Benjamin P Ross >Assignee: Benjamin P Ross >Priority: Major > > We want to add a unit test suite for the DescribeJndiBindingCommand to > improve our test coverage. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6029) Add Unit test for DescribeJndiBindingCommand
Benjamin P Ross created GEODE-6029: -- Summary: Add Unit test for DescribeJndiBindingCommand Key: GEODE-6029 URL: https://issues.apache.org/jira/browse/GEODE-6029 Project: Geode Issue Type: Improvement Components: gfsh Reporter: Benjamin P Ross We want to add a unit test suite for the DescribeJndiBindingCommand to improve our test coverage. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-6030) Upgrade commons-lang to commons-lang3
[ https://issues.apache.org/jira/browse/GEODE-6030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe reassigned GEODE-6030: - Assignee: Jens Deppe > Upgrade commons-lang to commons-lang3 > - > > Key: GEODE-6030 > URL: https://issues.apache.org/jira/browse/GEODE-6030 > Project: Geode > Issue Type: Task > Components: build >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6030) Upgrade commons-lang to commons-lang3
Jens Deppe created GEODE-6030: - Summary: Upgrade commons-lang to commons-lang3 Key: GEODE-6030 URL: https://issues.apache.org/jira/browse/GEODE-6030 Project: Geode Issue Type: Task Components: build Reporter: Jens Deppe -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6028) Remove unnecessary comparison checks in the code.
[ https://issues.apache.org/jira/browse/GEODE-6028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-6028: -- Labels: pull-request-available (was: ) > Remove unnecessary comparison checks in the code. > - > > Key: GEODE-6028 > URL: https://issues.apache.org/jira/browse/GEODE-6028 > Project: Geode > Issue Type: Bug >Reporter: nabarun >Priority: Major > Labels: pull-request-available > > Remove unnecessary checks in the code. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6031) Add getCache to ServerLauncher and LocatorLauncher APIs
Kirk Lund created GEODE-6031:
Summary: Add getCache to ServerLauncher and LocatorLauncher APIs
Key: GEODE-6031
URL: https://issues.apache.org/jira/browse/GEODE-6031
Project: Geode
Issue Type: Improvement
Components: core
Reporter: Kirk Lund
The ServerLauncher and LocatorLauncher APIs are used in two ways: 1) by GFSH to
fork a new Server or Locator, 2) by User to create a new Server or Locator
locally in a JVM.
This improvement adds getCache() to the APIs to enable the User in #2 to get a
reference without having to resort to invoking singleton getters.
{noformat}
/**
* Gets a reference to the Cache that was created by this ServerLauncher.
*
* @return a reference to the Cache
*/
public org.apache.geode.cache.Cache getCache();
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-6029) Add Unit test for DescribeJndiBindingCommand
[ https://issues.apache.org/jira/browse/GEODE-6029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-6029: -- Labels: pull-request-available (was: ) > Add Unit test for DescribeJndiBindingCommand > > > Key: GEODE-6029 > URL: https://issues.apache.org/jira/browse/GEODE-6029 > Project: Geode > Issue Type: Improvement > Components: gfsh >Reporter: Benjamin P Ross >Assignee: Benjamin P Ross >Priority: Major > Labels: pull-request-available > > We want to add a unit test suite for the DescribeJndiBindingCommand to > improve our test coverage. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6032) Entire object is serialized again (and again) when Delta.hasDelta returns false and client is using PROXY Region
[
https://issues.apache.org/jira/browse/GEODE-6032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-6032:
-
Priority: Critical (was: Major)
> Entire object is serialized again (and again) when Delta.hasDelta returns
> false and client is using PROXY Region
>
>
> Key: GEODE-6032
> URL: https://issues.apache.org/jira/browse/GEODE-6032
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Reporter: John Blum
>Priority: Critical
>
> Currently, if a cache client application is configured with a client
> {{PROXY}} Region, and the application is also using {{DataSerialization}} to
> de/serialize objects to/from the servers, and the application domain objects
> implement the {{org.apache.geode.Delta}} interface then Apache Geode will
> incorrectly send the entire object (again) when {{Delta.hasDelta}} returns
> *false*.
> It is understandable that the application domain object needs to be
> serialized in its entirety the first time the object is sent to the server(s)
> (or if the object is later, subsequently removed or has expired/been evicted,
> and then needs to be re-added for whatever reason).
> However, once the server(s) know about the object, then only ever a "delta"
> should be sent, and only when {{Delta.hasDelta()}} returns *true*.
> Otherwise, if {{Delta.hasDelta()}} returns *false*, then most certainly, the
> entire object should not be sent again, otherwise it is possible for the
> application to enter a race condition scenario where the object gets
> "overwritten", and as a results, the application can lose data (aka "_lost
> updates_").
> If users were to change their client Region data management policy from
> {{PROXY}} to {{CACHING_PROXY}} then this works as expected. Apache Geode
> will only send for and object it already knows about if there is actually a
> "delta", otherwise Geode does nothing (that is, does not send the object, or
> rather any delta to the servers since there is technically nothing to send).
> Obviously, in the {{CACHING_PROXY}} case, there is "local" state to compare
> against, and therefore, Geode knows about the object already, in that it
> "exists". It can therefore assess the object to determine if it is the
> same/unchanged, and not do anything in the case the {{Delta.hasDelta}}
> returns *false*, thus the "application" informing Geode there is nothing to
> send.
> Clearly, in the {{PROXY}} case, this "local" state does not exist, and
> therefore, Geode does not know whether the object (already) exists on the
> servers or not. So, if {{Delta.hasDelta()}} returns *false*, it is unsure
> whether the objects exists or not and so decides just to send the entire
> object again, a "_premature optimization_" to be sure, which now has
> sacrificed "_correctness_", and has amplified the possible "_race
> conditions_" on the application side.
> However, this is no different than if {{Delta.hasDelta()}} returns *true* and
> the object is *not yet* known by the servers. When the client sends just the
> delta in this case, the server will send back to the client, I don't know
> anything about this object for which the delta needs to be applied, and
> therefore, the client must turn around and send it the object anyway.
> So, in the {{PROXY}} case, it would be better if the client made a
> determination about whether the object truly exists on the server side or not
> before arbitrarily and falsely assuming the entire object should be sent
> again if the {{Delta.hasDelta()}} returns *false*. The client simply does
> not know and should "verify" before sending the object.
> Obviously this affects performance, but is a small price to pay (and the
> "correct" thing to do) compared with "_lost updates_" and amplifying "_race
> conditions_", client-side.
> There is also a situation where {{CACHING_PROXY}} client Regions can even
> *fail*, and that is when {{copy-on-read}} is set to *true*.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-6032) Entire object is serialized again (and again) when Delta.hasDelta returns false and client is using PROXY Region
John Blum created GEODE-6032:
Summary: Entire object is serialized again (and again) when
Delta.hasDelta returns false and client is using PROXY Region
Key: GEODE-6032
URL: https://issues.apache.org/jira/browse/GEODE-6032
Project: Geode
Issue Type: Bug
Components: client/server
Reporter: John Blum
Currently, if a cache client application is configured with a client {{PROXY}}
Region, and the application is also using {{DataSerialization}} to de/serialize
objects to/from the servers, and the application domain objects implement the
{{org.apache.geode.Delta}} interface then Apache Geode will incorrectly send
the entire object (again) when {{Delta.hasDelta}} returns *false*.
It is understandable that the application domain object needs to be serialized
in its entirety the first time the object is sent to the server(s) (or if the
object is later, subsequently removed or has expired/been evicted, and then
needs to be re-added for whatever reason).
However, once the server(s) know about the object, then only ever a "delta"
should be sent, and only when {{Delta.hasDelta()}} returns *true*. Otherwise,
if {{Delta.hasDelta()}} returns *false*, then most certainly, the entire object
should not be sent again, otherwise it is possible for the application to enter
a race condition scenario where the object gets "overwritten", and as a
results, the application can lose data (aka "_lost updates_").
If users were to change their client Region data management policy from
{{PROXY}} to {{CACHING_PROXY}} then this works as expected. Apache Geode will
only send for and object it already knows about if there is actually a "delta",
otherwise Geode does nothing (that is, does not send the object, or rather any
delta to the servers since there is technically nothing to send).
Obviously, in the {{CACHING_PROXY}} case, there is "local" state to compare
against, and therefore, Geode knows about the object already, in that it
"exists". It can therefore assess the object to determine if it is the
same/unchanged, and not do anything in the case the {{Delta.hasDelta}} returns
*false*, thus the "application" informing Geode there is nothing to send.
Clearly, in the {{PROXY}} case, this "local" state does not exist, and
therefore, Geode does not know whether the object (already) exists on the
servers or not. So, if {{Delta.hasDelta()}} returns *false*, it is unsure
whether the objects exists or not and so decides just to send the entire object
again, a "_premature optimization_" to be sure, which now has sacrificed
"_correctness_", and has amplified the possible "_race conditions_" on the
application side.
However, this is no different than if {{Delta.hasDelta()}} returns *true* and
the object is *not yet* known by the servers. When the client sends just the
delta in this case, the server will send back to the client, I don't know
anything about this object for which the delta needs to be applied, and
therefore, the client must turn around and send it the object anyway.
So, in the {{PROXY}} case, it would be better if the client made a
determination about whether the object truly exists on the server side or not
before arbitrarily and falsely assuming the entire object should be sent again
if the {{Delta.hasDelta()}} returns *false*. The client simply does not know
and should "verify" before sending the object.
Obviously this affects performance, but is a small price to pay (and the
"correct" thing to do) compared with "_lost updates_" and amplifying "_race
conditions_", client-side.
There is also a situation where {{CACHING_PROXY}} client Regions can even
*fail*, and that is when {{copy-on-read}} is set to *true*.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-6032) Entire object is serialized again (and again) when Delta.hasDelta returns false and client is using PROXY Region
[
https://issues.apache.org/jira/browse/GEODE-6032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-6032:
-
Description:
Currently, if a cache client application is...
1) configured with a client {{PROXY}} Region, and...
2) the application is also using {{DataSerialization}} to de/serialize objects
to/from the servers, and...
3) the application domain objects implement the {{org.apache.geode.Delta}}
interface then Apache Geode will incorrectly send the entire object (again)
when {{Delta.hasDelta}} returns *false*.
It is understandable that the application domain object needs to be serialized
in its entirety the first time the object is sent to the server(s) (or if the
object is later, subsequently removed or has expired/been evicted, and then
needs to be re-added for whatever reason).
However, once the server(s) know about the object, then only ever a "delta"
should be sent, and only when {{Delta.hasDelta()}} returns *true*. Otherwise,
if {{Delta.hasDelta()}} returns *false*, then most certainly, the entire object
should not be sent again, otherwise it is possible for the application to enter
a race condition scenario where the object gets "overwritten", and as a
results, the application can lose data (aka "_lost updates_").
If users were to change their client Region data management policy from
{{PROXY}} to {{CACHING_PROXY}} then this works as expected. Apache Geode will
only send for and object it already knows about if there is actually a "delta",
otherwise Geode does nothing (that is, does not send the object, or rather any
delta to the servers since there is technically nothing to send).
Obviously, in the {{CACHING_PROXY}} case, there is "local" state to compare
against, and therefore, Geode knows about the object already, in that it
"exists". It can therefore assess the object to determine if it is the
same/unchanged, and not do anything in the case the {{Delta.hasDelta}} returns
*false*, thus the "application" informing Geode there is nothing to send.
Clearly, in the {{PROXY}} case, this "local" state does not exist, and
therefore, Geode does not know whether the object (already) exists on the
servers or not. So, if {{Delta.hasDelta()}} returns *false*, it is unsure
whether the objects exists or not and so decides just to send the entire object
again, a "_premature optimization_" to be sure, which now has sacrificed
"_correctness_", and has amplified the possible "_race conditions_" on the
application side.
However, this is no different than if {{Delta.hasDelta()}} returns *true* and
the object is *not yet* known by the servers. When the client sends just the
delta in this case, the server will send back to the client, I don't know
anything about this object for which the delta needs to be applied, and
therefore, the client must turn around and send it the object anyway.
So, in the {{PROXY}} case, it would be better if the client made a
determination about whether the object truly exists on the server side or not
before arbitrarily and falsely assuming the entire object should be sent again
if the {{Delta.hasDelta()}} returns *false*. The client simply does not know
and should "verify" before sending the object.
Obviously this affects performance, but is a small price to pay (and the
"correct" thing to do) compared with "_lost updates_" and amplifying "_race
conditions_", client-side.
There is also a situation where {{CACHING_PROXY}} client Regions can even
*fail*, and that is when {{copy-on-read}} is set to *true*.
was:
Currently, if a cache client application is configured with a client {{PROXY}}
Region, and the application is also using {{DataSerialization}} to de/serialize
objects to/from the servers, and the application domain objects implement the
{{org.apache.geode.Delta}} interface then Apache Geode will incorrectly send
the entire object (again) when {{Delta.hasDelta}} returns *false*.
It is understandable that the application domain object needs to be serialized
in its entirety the first time the object is sent to the server(s) (or if the
object is later, subsequently removed or has expired/been evicted, and then
needs to be re-added for whatever reason).
However, once the server(s) know about the object, then only ever a "delta"
should be sent, and only when {{Delta.hasDelta()}} returns *true*. Otherwise,
if {{Delta.hasDelta()}} returns *false*, then most certainly, the entire object
should not be sent again, otherwise it is possible for the application to enter
a race condition scenario where the object gets "overwritten", and as a
results, the application can lose data (aka "_lost updates_").
If users were to change their client Region data management policy from
{{PROXY}} to {{CACHING_PROXY}} then this works as expected. Apache Geode will
only send for and object it already knows about if there is actually a "delta",
otherwise
[jira] [Updated] (GEODE-6032) Entire object is serialized again (and again) when Delta.hasDelta returns false and client is using PROXY Region
[
https://issues.apache.org/jira/browse/GEODE-6032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-6032:
-
Description:
Currently, if a cache client application is...
1) configured with a client {{PROXY}} Region, and...
2) the application is also using {{DataSerialization}} to de/serialize objects
to/from the servers, and...
3) the application domain objects implement the {{org.apache.geode.Delta}}
interface then Apache Geode will incorrectly send the entire object (again)
when {{Delta.hasDelta}} returns *false*.
It is understandable that the application domain object needs to be serialized
in its entirety the first time the object is sent to the server(s) (or if the
object is later, subsequently removed or has expired/been evicted, and then
needs to be re-added for whatever reason).
However, once the server(s) know about the object, then only ever a "delta"
should be sent, and only when {{Delta.hasDelta()}} returns *true*. Otherwise,
if {{Delta.hasDelta()}} returns *false*, then most certainly, the entire object
should not be sent again, otherwise it is possible for the application to enter
a race condition scenario where the object gets "overwritten", and as a
results, the application can lose data (aka "_lost updates_").
If users were to change their client Region data management policy from
{{PROXY}} to {{CACHING_PROXY}} then this works as expected. Apache Geode will
only send for and object it already knows about if there is actually a "delta",
otherwise Geode does nothing (that is, does not send the object, or rather any
delta to the servers since there is technically nothing to send).
Obviously, in the {{CACHING_PROXY}} case, there is "local" state to compare
against, and therefore, Geode knows about the object already, in that it
"exists". It can therefore assess the object to determine if it is the
same/unchanged, and not do anything in the case the {{Delta.hasDelta}} returns
*false*, thus the "application" informing Geode there is nothing to send.
Clearly, in the {{PROXY}} case, this "local" state does not exist, and
therefore, Geode does not know whether the object (already) exists on the
servers or not. So, if {{Delta.hasDelta()}} returns *false*, it is unsure
whether the objects exists or not and so decides just to send the entire object
again, a "_premature optimization_" to be sure, which now has sacrificed
"_correctness_", and has amplified the possible "_race conditions_" on the
application side.
However, this is no different than if {{Delta.hasDelta()}} returns *true* and
the object is *not yet* known by the servers. When the client sends just the
delta in this case, the server will send back to the client, I don't know
anything about this object for which the delta needs to be applied, and
therefore, the client must turn around and send it the object anyway.
So, in the {{PROXY}} case, it would be better if the client made a
determination about whether the object truly exists on the server side or not
before arbitrarily and falsely assuming the entire object should be sent again
if the {{Delta.hasDelta()}} returns *false*. The client simply does not know
and should "verify" before sending the object.
Obviously this affects performance, but is a small price to pay (and the
"correct" thing to do) compared with "_lost updates_" and amplifying "_race
conditions_", client-side.
There is also a situation where {{CACHING_PROXY}} client Regions can even
*fail*, and that is when {{copy-on-read}} is set to *true*.
To make matters worse, even the
[_Javadoc_|http://geode.apache.org/releases/latest/javadoc/org/apache/geode/Delta.html#hasDelta--]
explains and implies that only "_pending changes_" are written if they exist...
> "Returns true if this object has pending changes it can write out."
Of course, this doc is less than clear and very ambiguous about what exactly
happens. But, to be sure, it is certainly not consistent behavior between
different data management policies and certainly not correct!
was:
Currently, if a cache client application is...
1) configured with a client {{PROXY}} Region, and...
2) the application is also using {{DataSerialization}} to de/serialize objects
to/from the servers, and...
3) the application domain objects implement the {{org.apache.geode.Delta}}
interface then Apache Geode will incorrectly send the entire object (again)
when {{Delta.hasDelta}} returns *false*.
It is understandable that the application domain object needs to be serialized
in its entirety the first time the object is sent to the server(s) (or if the
object is later, subsequently removed or has expired/been evicted, and then
needs to be re-added for whatever reason).
However, once the server(s) know about the object, then only ever a "delta"
should be sent, and only when {{Delta.hasDelta()}} returns *true*. Otherwise,
if {{Delta.hasDelta
[jira] [Updated] (GEODE-6032) Entire object is serialized again (and again) when Delta.hasDelta returns false and client is using PROXY Region
[
https://issues.apache.org/jira/browse/GEODE-6032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-6032:
-
Description:
Currently, if a cache client application is...
1) configured with a client {{PROXY}} Region, and...
2) the application is also using {{DataSerialization}} to de/serialize objects
to/from the servers, and...
3) the application domain objects implement the {{org.apache.geode.Delta}}
interface then Apache Geode will incorrectly send the entire object (again)
when {{Delta.hasDelta}} returns *false*.
It is understandable that the application domain object needs to be serialized
in its entirety the first time the object is sent to the server(s) (or if the
object is later, subsequently removed or has expired/been evicted, and then
needs to be re-added for whatever reason).
However, once the server(s) know about the object, then only ever a "delta"
should be sent, and only when {{Delta.hasDelta()}} returns *true*. Otherwise,
if {{Delta.hasDelta()}} returns *false*, then most certainly, the entire object
should not be sent again, otherwise it is possible for the application to enter
a "_race condition_" scenario where the object gets "overwritten", and as a
results, the application can lose data (aka "_lost updates_").
If users were to change their client Region data management policy from
{{PROXY}} to {{CACHING_PROXY}} then this works as expected. Apache Geode will
only send for and object it already knows about if there is actually a "delta",
otherwise Geode does nothing (that is, does not send the object, or rather any
delta to the servers since there is technically nothing to send).
Obviously, in the {{CACHING_PROXY}} case, there is "local" state to compare
against, and therefore, Geode knows about the object already, in that it
"exists". It can therefore assess the object to determine if it is the
same/unchanged, and not do anything in the case the {{Delta.hasDelta}} returns
*false*, thus the "application" informing Geode there is nothing to send.
Clearly, in the {{PROXY}} case, this "local" state does not exist, and
therefore, Geode does not know whether the object (already) exists on the
servers or not. So, if {{Delta.hasDelta()}} returns *false*, it is unsure
whether the objects exists or not and so decides just to send the entire object
again, a "_premature optimization_" to be sure, which now has sacrificed
"_correctness_", and has amplified the possible "_race conditions_" on the
application side.
However, this is no different than if {{Delta.hasDelta()}} returns *true* and
the object is *not yet* known by the servers. When the client sends just the
delta in this case, the server will send back to the client, I don't know
anything about this object for which the delta needs to be applied, and
therefore, the client must turn around and send it the object anyway.
So, in the {{PROXY}} case, it would be better if the client made a
determination about whether the object truly exists on the server side or not
before arbitrarily and falsely assuming the entire object should be sent again
if the {{Delta.hasDelta()}} returns *false*. The client simply does not know
and should "verify" before sending the object.
Obviously this affects performance, but is a small price to pay (and the
"correct" thing to do) compared with "_lost updates_" and amplifying "_race
conditions_", client-side.
There is also a situation where {{CACHING_PROXY}} client Regions can even
*fail*, and that is when {{copy-on-read}} is set to *true*.
To make matters worse, even the
[_Javadoc_|http://geode.apache.org/releases/latest/javadoc/org/apache/geode/Delta.html#hasDelta--]
explains and implies that only "_pending changes_" are written if they exist...
> "Returns true if this object has pending changes it can write out."
Of course, this doc is less than clear and very ambiguous about what exactly
happens. But, to be sure, it is certainly not consistent in behavior when
different data management policies are effect, and most definitely not correct!
was:
Currently, if a cache client application is...
1) configured with a client {{PROXY}} Region, and...
2) the application is also using {{DataSerialization}} to de/serialize objects
to/from the servers, and...
3) the application domain objects implement the {{org.apache.geode.Delta}}
interface then Apache Geode will incorrectly send the entire object (again)
when {{Delta.hasDelta}} returns *false*.
It is understandable that the application domain object needs to be serialized
in its entirety the first time the object is sent to the server(s) (or if the
object is later, subsequently removed or has expired/been evicted, and then
needs to be re-added for whatever reason).
However, once the server(s) know about the object, then only ever a "delta"
should be sent, and only when {{Delta.hasDelta()}} returns *true*. Otherwise
[jira] [Commented] (GEODE-6016) Geode function execution in client transaction with singleHopEnabled is not transactional
[ https://issues.apache.org/jira/browse/GEODE-6016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16681914#comment-16681914 ] ASF subversion and git services commented on GEODE-6016: Commit c14d960f959abd20aaa98ba6308e37ad81ddb686 in geode's branch refs/heads/develop from pivotal-eshu [ https://gitbox.apache.org/repos/asf?p=geode.git;h=c14d960 ] Feature/geode 6016 (#2820) * GEODE-6016: Make client onRegion function transactional. * Do not use a function execution thread to send message to server even if singleHop is enabled when function is in transaction. * Throw UnsupportedOperationException if client executes onMembers function using transaction - to behave similar to onServers function when using transaction. > Geode function execution in client transaction with singleHopEnabled is not > transactional > - > > Key: GEODE-6016 > URL: https://issues.apache.org/jira/browse/GEODE-6016 > Project: Geode > Issue Type: Bug > Components: transactions >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > > When function execution with single hop enabled, a function execution thread > will execute the function. The function execution thread does not send a > transactional message to server and this causes the function execution non > transactional. > This occurs when txmanager.begin is invoked on client like the following: > txManager.begin(); > ResultCollector resultCollector = > execution.withFilter(keySet).execute(function); resultCollector.getResult(); > txManager.commit()/rollback(); > If txmanager.begin() is embedded in function body, there is no issue as > transaction starts on server directly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-6031) Add getCache to ServerLauncher and LocatorLauncher APIs
[
https://issues.apache.org/jira/browse/GEODE-6031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund reassigned GEODE-6031:
Assignee: Kirk Lund
> Add getCache to ServerLauncher and LocatorLauncher APIs
> ---
>
> Key: GEODE-6031
> URL: https://issues.apache.org/jira/browse/GEODE-6031
> Project: Geode
> Issue Type: Improvement
> Components: core
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
>
> The ServerLauncher and LocatorLauncher APIs are used in two ways: 1) by GFSH
> to fork a new Server or Locator, 2) by User to create a new Server or Locator
> locally in a JVM.
> This improvement adds getCache() to the APIs to enable the User in #2 to get
> a reference without having to resort to invoking singleton getters.
> {noformat}
> /**
> * Gets a reference to the Cache that was created by this ServerLauncher.
> *
> * @return a reference to the Cache
> */
> public org.apache.geode.cache.Cache getCache();
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-6016) Geode function execution in client transaction with singleHopEnabled is not transactional
[ https://issues.apache.org/jira/browse/GEODE-6016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu resolved GEODE-6016. - Resolution: Fixed Fix Version/s: 1.9.0 > Geode function execution in client transaction with singleHopEnabled is not > transactional > - > > Key: GEODE-6016 > URL: https://issues.apache.org/jira/browse/GEODE-6016 > Project: Geode > Issue Type: Bug > Components: transactions >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Fix For: 1.9.0 > > > When function execution with single hop enabled, a function execution thread > will execute the function. The function execution thread does not send a > transactional message to server and this causes the function execution non > transactional. > This occurs when txmanager.begin is invoked on client like the following: > txManager.begin(); > ResultCollector resultCollector = > execution.withFilter(keySet).execute(function); resultCollector.getResult(); > txManager.commit()/rollback(); > If txmanager.begin() is embedded in function body, there is no issue as > transaction starts on server directly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6032) Entire object is serialized again (and again) when Delta.hasDelta returns false and client is using PROXY Region
[
https://issues.apache.org/jira/browse/GEODE-6032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-6032:
-
Description:
Currently, if a cache client application is...
1) configured with a client {{PROXY}} Region, and...
2) the application is also using {{DataSerialization}} to de/serialize objects
to/from the servers, and...
3) the application domain objects implement the {{org.apache.geode.Delta}}
interface then Apache Geode will incorrectly send the entire object (again)
when {{Delta.hasDelta}} returns *false*.
It is understandable that the application domain object needs to be serialized
in its entirety the first time the object is sent to the server(s) (or if the
object is later, subsequently removed or has expired/been evicted, and then
needs to be re-added for whatever reason).
However, once the server(s) know about the object, then only ever a "delta"
should be sent, and only when {{Delta.hasDelta()}} returns *true*. Otherwise,
if {{Delta.hasDelta()}} returns *false*, then most certainly, the entire object
should not be sent again, otherwise it is possible for the application to enter
a "_race condition_" scenario where the object gets "overwritten", and as a
result, the application can lose data (aka "_lost updates_").
If users were to change their client Region data management policy from
{{PROXY}} to {{CACHING_PROXY}} then this works as expected. Apache Geode will
only send updates for an object it already knows about if there is actually a
"delta", otherwise Geode does nothing (that is, does not send the entire object
or any delta to the server(s) since there is technically nothing to send).
Obviously, in the {{CACHING_PROXY}} case, there is "local" state to compare
against, and therefore, Geode knows about the object already, in that it
"exists". It can therefore assess the object to determine if it is the
same/unchanged, and not do anything in the case where {{Delta.hasDelta()}}
returns *false*, thus the "application" informing Geode there is nothing to
send.
Clearly, in the {{PROXY}} case, there is no "local" state, and therefore, Geode
does not know whether the object (already) exists on the servers or not. So,
if {{Delta.hasDelta()}} returns *false*, it is unsure whether the objects
exists or not and so decides just to send the entire object again, a
"_premature optimization_" to be sure, which now has sacrificed
"_correctness_", and has amplified the possible "_race conditions_" on the
application side.
However, this is no different than if {{Delta.hasDelta()}} returns *true* and
the object is *not yet* known by the servers. When the client sends just the
delta in this case, the server will send back to the client, "I don't know
anything about this object for which the delta needs to be applied", and
therefore, the client must turn around and send it the entire object anyway.
So, in the {{PROXY}} case, it would be better if the client made a
determination about whether the object truly exists on the server side or not,
first, before arbitrarily and falsely assuming the entire object should be sent
again if the {{Delta.hasDelta()}} returns *false*. The client simply does not
know and should "verify" before sending the object.
Obviously, this affect will performance, but is a small price to pay (and the
"correct" thing to do) compared with "_lost updates_" and amplifying "_race
conditions_" on the client-side.
There is also a situation where {{CACHING_PROXY}} client Regions can even
*fail*, and that is when {{copy-on-read}} is set to *true*. Hopefully, this is
obvious why.
To make matters worse, even the
[_Javadoc_|http://geode.apache.org/releases/latest/javadoc/org/apache/geode/Delta.html#hasDelta--]
explains and implies that only "_pending changes_" are written if they exist...
> "Returns true if this object has pending changes it can write out."
Of course, this doc is less than clear and very ambiguous about what exactly
happens when ((hasDelta()) return *false*, which is "pertinent" information.
But, to be sure, it is certainly not consistent in behavior when different data
management policies are in effect, and most definitely not correct!
was:
Currently, if a cache client application is...
1) configured with a client {{PROXY}} Region, and...
2) the application is also using {{DataSerialization}} to de/serialize objects
to/from the servers, and...
3) the application domain objects implement the {{org.apache.geode.Delta}}
interface then Apache Geode will incorrectly send the entire object (again)
when {{Delta.hasDelta}} returns *false*.
It is understandable that the application domain object needs to be serialized
in its entirety the first time the object is sent to the server(s) (or if the
object is later, subsequently removed or has expired/been evicted, and then
needs to be re-added for whatever reason).
However, once the
[jira] [Updated] (GEODE-6032) Entire object is serialized again (and again) when Delta.hasDelta returns false and client is using PROXY Region
[
https://issues.apache.org/jira/browse/GEODE-6032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-6032:
-
Affects Version/s: 1.7.0
> Entire object is serialized again (and again) when Delta.hasDelta returns
> false and client is using PROXY Region
>
>
> Key: GEODE-6032
> URL: https://issues.apache.org/jira/browse/GEODE-6032
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.7.0
>Reporter: John Blum
>Priority: Critical
>
> Currently, if a cache client application is...
> 1) configured with a client {{PROXY}} Region, and...
> 2) the application is also using {{DataSerialization}} to de/serialize
> objects to/from the servers, and...
> 3) the application domain objects implement the {{org.apache.geode.Delta}}
> interface then Apache Geode will incorrectly send the entire object (again)
> when {{Delta.hasDelta}} returns *false*.
> It is understandable that the application domain object needs to be
> serialized in its entirety the first time the object is sent to the server(s)
> (or if the object is later, subsequently removed or has expired/been evicted,
> and then needs to be re-added for whatever reason).
> However, once the server(s) know about the object, then only ever a "delta"
> should be sent, and only when {{Delta.hasDelta()}} returns *true*.
> Otherwise, if {{Delta.hasDelta()}} returns *false*, then most certainly, the
> entire object should not be sent again, otherwise it is possible for the
> application to enter a "_race condition_" scenario where the object gets
> "overwritten", and as a result, the application can lose data (aka "_lost
> updates_").
> If users were to change their client Region data management policy from
> {{PROXY}} to {{CACHING_PROXY}} then this works as expected. Apache Geode
> will only send updates for an object it already knows about if there is
> actually a "delta", otherwise Geode does nothing (that is, does not send the
> entire object or any delta to the server(s) since there is technically
> nothing to send).
> Obviously, in the {{CACHING_PROXY}} case, there is "local" state to compare
> against, and therefore, Geode knows about the object already, in that it
> "exists". It can therefore assess the object to determine if it is the
> same/unchanged, and not do anything in the case where {{Delta.hasDelta()}}
> returns *false*, thus the "application" informing Geode there is nothing to
> send.
> Clearly, in the {{PROXY}} case, there is no "local" state, and therefore,
> Geode does not know whether the object (already) exists on the servers or
> not. So, if {{Delta.hasDelta()}} returns *false*, it is unsure whether the
> objects exists or not and so decides just to send the entire object again, a
> "_premature optimization_" to be sure, which now has sacrificed
> "_correctness_", and has amplified the possible "_race conditions_" on the
> application side.
> However, this is no different than if {{Delta.hasDelta()}} returns *true* and
> the object is *not yet* known by the servers. When the client sends just the
> delta in this case, the server will send back to the client, "I don't know
> anything about this object for which the delta needs to be applied", and
> therefore, the client must turn around and send it the entire object anyway.
> So, in the {{PROXY}} case, it would be better if the client made a
> determination about whether the object truly exists on the server side or
> not, first, before arbitrarily and falsely assuming the entire object should
> be sent again if the {{Delta.hasDelta()}} returns *false*. The client simply
> does not know and should "verify" before sending the object.
> Obviously, this affect will performance, but is a small price to pay (and the
> "correct" thing to do) compared with "_lost updates_" and amplifying "_race
> conditions_" on the client-side.
> There is also a situation where {{CACHING_PROXY}} client Regions can even
> *fail*, and that is when {{copy-on-read}} is set to *true*. Hopefully, this
> is obvious why.
> To make matters worse, even the
> [_Javadoc_|http://geode.apache.org/releases/latest/javadoc/org/apache/geode/Delta.html#hasDelta--]
> explains and implies that only "_pending changes_" are written if they
> exist...
> > "Returns true if this object has pending changes it can write out."
> Of course, this doc is less than clear and very ambiguous about what exactly
> happens when ((hasDelta()) return *false*, which is "pertinent" information.
> But, to be sure, it is certainly not consistent in behavior when different
> data management policies are in effect, and most definitely not correct!
--
This message was sent by Atlassian JIRA
(v7.6.3#76
[jira] [Updated] (GEODE-6032) Entire object is serialized again (and again) when Delta.hasDelta returns false and client is using PROXY Region
[
https://issues.apache.org/jira/browse/GEODE-6032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-6032:
-
Affects Version/s: 1.1.0
1.1.1
1.2.0
1.3.0
1.2.1
1.4.0
1.5.0
> Entire object is serialized again (and again) when Delta.hasDelta returns
> false and client is using PROXY Region
>
>
> Key: GEODE-6032
> URL: https://issues.apache.org/jira/browse/GEODE-6032
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.1.0, 1.1.1, 1.2.0, 1.3.0, 1.2.1, 1.4.0, 1.5.0, 1.6.0,
> 1.7.0
>Reporter: John Blum
>Priority: Critical
>
> Currently, if a cache client application is...
> 1) configured with a client {{PROXY}} Region, and...
> 2) the application is also using {{DataSerialization}} to de/serialize
> objects to/from the servers, and...
> 3) the application domain objects implement the {{org.apache.geode.Delta}}
> interface then Apache Geode will incorrectly send the entire object (again)
> when {{Delta.hasDelta}} returns *false*.
> It is understandable that the application domain object needs to be
> serialized in its entirety the first time the object is sent to the server(s)
> (or if the object is later, subsequently removed or has expired/been evicted,
> and then needs to be re-added for whatever reason).
> However, once the server(s) know about the object, then only ever a "delta"
> should be sent, and only when {{Delta.hasDelta()}} returns *true*.
> Otherwise, if {{Delta.hasDelta()}} returns *false*, then most certainly, the
> entire object should not be sent again, otherwise it is possible for the
> application to enter a "_race condition_" scenario where the object gets
> "overwritten", and as a result, the application can lose data (aka "_lost
> updates_").
> If users were to change their client Region data management policy from
> {{PROXY}} to {{CACHING_PROXY}} then this works as expected. Apache Geode
> will only send updates for an object it already knows about if there is
> actually a "delta", otherwise Geode does nothing (that is, does not send the
> entire object or any delta to the server(s) since there is technically
> nothing to send).
> Obviously, in the {{CACHING_PROXY}} case, there is "local" state to compare
> against, and therefore, Geode knows about the object already, in that it
> "exists". It can therefore assess the object to determine if it is the
> same/unchanged, and not do anything in the case where {{Delta.hasDelta()}}
> returns *false*, thus the "application" informing Geode there is nothing to
> send.
> Clearly, in the {{PROXY}} case, there is no "local" state, and therefore,
> Geode does not know whether the object (already) exists on the servers or
> not. So, if {{Delta.hasDelta()}} returns *false*, it is unsure whether the
> objects exists or not and so decides just to send the entire object again, a
> "_premature optimization_" to be sure, which now has sacrificed
> "_correctness_", and has amplified the possible "_race conditions_" on the
> application side.
> However, this is no different than if {{Delta.hasDelta()}} returns *true* and
> the object is *not yet* known by the servers. When the client sends just the
> delta in this case, the server will send back to the client, "I don't know
> anything about this object for which the delta needs to be applied", and
> therefore, the client must turn around and send it the entire object anyway.
> So, in the {{PROXY}} case, it would be better if the client made a
> determination about whether the object truly exists on the server side or
> not, first, before arbitrarily and falsely assuming the entire object should
> be sent again if the {{Delta.hasDelta()}} returns *false*. The client simply
> does not know and should "verify" before sending the object.
> Obviously, this affect will performance, but is a small price to pay (and the
> "correct" thing to do) compared with "_lost updates_" and amplifying "_race
> conditions_" on the client-side.
> There is also a situation where {{CACHING_PROXY}} client Regions can even
> *fail*, and that is when {{copy-on-read}} is set to *true*. Hopefully, this
> is obvious why.
> To make matters worse, even the
> [_Javadoc_|http://geode.apache.org/releases/latest/javadoc/org/apache/geode/Delta.html#hasDelta--]
> explains and implies that only "_pending changes_" are written if they
> exist...
> > "Returns true if this object has pending changes it can write out."
> Of course, this doc is less than clear and very ambiguous about what exactly
> happens when ((hasDelta()) return *false*, which is "pe
[jira] [Updated] (GEODE-6032) Entire object is serialized again (and again) when Delta.hasDelta returns false and client is using PROXY Region
[
https://issues.apache.org/jira/browse/GEODE-6032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-6032:
-
Affects Version/s: 1.6.0
> Entire object is serialized again (and again) when Delta.hasDelta returns
> false and client is using PROXY Region
>
>
> Key: GEODE-6032
> URL: https://issues.apache.org/jira/browse/GEODE-6032
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.1.0, 1.1.1, 1.2.0, 1.3.0, 1.2.1, 1.4.0, 1.5.0, 1.6.0,
> 1.7.0
>Reporter: John Blum
>Priority: Critical
>
> Currently, if a cache client application is...
> 1) configured with a client {{PROXY}} Region, and...
> 2) the application is also using {{DataSerialization}} to de/serialize
> objects to/from the servers, and...
> 3) the application domain objects implement the {{org.apache.geode.Delta}}
> interface then Apache Geode will incorrectly send the entire object (again)
> when {{Delta.hasDelta}} returns *false*.
> It is understandable that the application domain object needs to be
> serialized in its entirety the first time the object is sent to the server(s)
> (or if the object is later, subsequently removed or has expired/been evicted,
> and then needs to be re-added for whatever reason).
> However, once the server(s) know about the object, then only ever a "delta"
> should be sent, and only when {{Delta.hasDelta()}} returns *true*.
> Otherwise, if {{Delta.hasDelta()}} returns *false*, then most certainly, the
> entire object should not be sent again, otherwise it is possible for the
> application to enter a "_race condition_" scenario where the object gets
> "overwritten", and as a result, the application can lose data (aka "_lost
> updates_").
> If users were to change their client Region data management policy from
> {{PROXY}} to {{CACHING_PROXY}} then this works as expected. Apache Geode
> will only send updates for an object it already knows about if there is
> actually a "delta", otherwise Geode does nothing (that is, does not send the
> entire object or any delta to the server(s) since there is technically
> nothing to send).
> Obviously, in the {{CACHING_PROXY}} case, there is "local" state to compare
> against, and therefore, Geode knows about the object already, in that it
> "exists". It can therefore assess the object to determine if it is the
> same/unchanged, and not do anything in the case where {{Delta.hasDelta()}}
> returns *false*, thus the "application" informing Geode there is nothing to
> send.
> Clearly, in the {{PROXY}} case, there is no "local" state, and therefore,
> Geode does not know whether the object (already) exists on the servers or
> not. So, if {{Delta.hasDelta()}} returns *false*, it is unsure whether the
> objects exists or not and so decides just to send the entire object again, a
> "_premature optimization_" to be sure, which now has sacrificed
> "_correctness_", and has amplified the possible "_race conditions_" on the
> application side.
> However, this is no different than if {{Delta.hasDelta()}} returns *true* and
> the object is *not yet* known by the servers. When the client sends just the
> delta in this case, the server will send back to the client, "I don't know
> anything about this object for which the delta needs to be applied", and
> therefore, the client must turn around and send it the entire object anyway.
> So, in the {{PROXY}} case, it would be better if the client made a
> determination about whether the object truly exists on the server side or
> not, first, before arbitrarily and falsely assuming the entire object should
> be sent again if the {{Delta.hasDelta()}} returns *false*. The client simply
> does not know and should "verify" before sending the object.
> Obviously, this affect will performance, but is a small price to pay (and the
> "correct" thing to do) compared with "_lost updates_" and amplifying "_race
> conditions_" on the client-side.
> There is also a situation where {{CACHING_PROXY}} client Regions can even
> *fail*, and that is when {{copy-on-read}} is set to *true*. Hopefully, this
> is obvious why.
> To make matters worse, even the
> [_Javadoc_|http://geode.apache.org/releases/latest/javadoc/org/apache/geode/Delta.html#hasDelta--]
> explains and implies that only "_pending changes_" are written if they
> exist...
> > "Returns true if this object has pending changes it can write out."
> Of course, this doc is less than clear and very ambiguous about what exactly
> happens when ((hasDelta()) return *false*, which is "pertinent" information.
> But, to be sure, it is certainly not consistent in behavior when different
> data management policies are in effect, and most definitely not correc
[jira] [Updated] (GEODE-6032) Entire object is serialized again (and again) when Delta.hasDelta returns false and client is using PROXY Region
[
https://issues.apache.org/jira/browse/GEODE-6032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-6032:
-
Description:
Currently, if a cache client application is...
1) configured with a client {{PROXY}} Region, and...
2) the application is also using {{DataSerialization}} to de/serialize objects
to/from the servers, and...
3) the application domain objects implement the {{org.apache.geode.Delta}}
interface then Apache Geode will incorrectly send the entire object (again)
when {{Delta.hasDelta}} returns *false*.
It is understandable that the application domain object needs to be serialized
in its entirety the first time the object is sent to the server(s) (or if the
object is later, subsequently removed or has expired/been evicted, and then
needs to be re-added for whatever reason).
However, once the server(s) know about the object, then only ever a "delta"
should be sent, and only when {{Delta.hasDelta()}} returns *true*. Otherwise,
if {{Delta.hasDelta()}} returns *false*, then most certainly, the entire object
should not be sent again, otherwise it is possible for the application to enter
a race condition scenario where the object gets "overwritten", and as a
results, the application can lose data (aka "_lost updates_").
If users were to change their client Region data management policy from
{{PROXY}} to {{CACHING_PROXY}} then this works as expected. Apache Geode will
only send for and object it already knows about if there is actually a "delta",
otherwise Geode does nothing (that is, does not send the object, or rather any
delta to the servers since there is technically nothing to send).
Obviously, in the {{CACHING_PROXY}} case, there is "local" state to compare
against, and therefore, Geode knows about the object already, in that it
"exists". It can therefore assess the object to determine if it is the
same/unchanged, and not do anything in the case the {{Delta.hasDelta}} returns
*false*, thus the "application" informing Geode there is nothing to send.
Clearly, in the {{PROXY}} case, this "local" state does not exist, and
therefore, Geode does not know whether the object (already) exists on the
servers or not. So, if {{Delta.hasDelta()}} returns *false*, it is unsure
whether the objects exists or not and so decides just to send the entire object
again, a "_premature optimization_" to be sure, which now has sacrificed
"_correctness_", and has amplified the possible "_race conditions_" on the
application side.
However, this is no different than if {{Delta.hasDelta()}} returns *true* and
the object is *not yet* known by the servers. When the client sends just the
delta in this case, the server will send back to the client, I don't know
anything about this object for which the delta needs to be applied, and
therefore, the client must turn around and send it the object anyway.
So, in the {{PROXY}} case, it would be better if the client made a
determination about whether the object truly exists on the server side or not
before arbitrarily and falsely assuming the entire object should be sent again
if the {{Delta.hasDelta()}} returns *false*. The client simply does not know
and should "verify" before sending the object.
Obviously this affects performance, but is a small price to pay (and the
"correct" thing to do) compared with "_lost updates_" and amplifying "_race
conditions_", client-side.
There is also a situation where {{CACHING_PROXY}} client Regions can even
*fail*, and that is when {{copy-on-read}} is set to *true*.
To make matters worse, even the
[_Javadoc_|http://geode.apache.org/releases/latest/javadoc/org/apache/geode/Delta.html#hasDelta--]
explains and implies that only "_pending changes_" are written if they exist...
> "Returns true if this object has pending changes it can write out."
Of course, this doc is less than clear and very ambiguous about what exactly
happens. But, to be sure, it is certainly not consistent in behavior when
different data management policies are effect, and most definitely not correct!
was:
Currently, if a cache client application is...
1) configured with a client {{PROXY}} Region, and...
2) the application is also using {{DataSerialization}} to de/serialize objects
to/from the servers, and...
3) the application domain objects implement the {{org.apache.geode.Delta}}
interface then Apache Geode will incorrectly send the entire object (again)
when {{Delta.hasDelta}} returns *false*.
It is understandable that the application domain object needs to be serialized
in its entirety the first time the object is sent to the server(s) (or if the
object is later, subsequently removed or has expired/been evicted, and then
needs to be re-added for whatever reason).
However, once the server(s) know about the object, then only ever a "delta"
should be sent, and only when {{Delta.hasDelta()}} returns *true*. Otherwise,
i
[jira] [Updated] (GEODE-6032) Entire object is serialized again (and again) when Delta.hasDelta returns false and client is using PROXY Region
[
https://issues.apache.org/jira/browse/GEODE-6032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-6032:
-
Description:
Currently, if a cache client application is...
1) configured with a client {{PROXY}} Region, and...
2) the application is also using {{DataSerialization}} to de/serialize objects
to/from the servers, and...
3) the application domain objects implement the {{org.apache.geode.Delta}}
interface then Apache Geode will incorrectly send the entire object (again)
when {{Delta.hasDelta}} returns *false*.
It is understandable that the application domain object needs to be serialized
in its entirety the first time the object is sent to the server(s) (or if the
object is later, subsequently removed or has expired/been evicted, and then
needs to be re-added for whatever reason).
However, once the server(s) know about the object, then only ever a "delta"
should be sent, and only when {{Delta.hasDelta()}} returns *true*. Otherwise,
if {{Delta.hasDelta()}} returns *false*, then most certainly, the entire object
should not be sent again, otherwise it is possible for the application to enter
a "_race condition_" scenario where the object gets "overwritten", and as a
result, the application can lose data (aka "_lost updates_").
If users were to change their client Region data management policy from
{{PROXY}} to {{CACHING_PROXY}} then this works as expected. Apache Geode will
only send for and object it already knows about if there is actually a "delta",
otherwise Geode does nothing (that is, does not send the object, or rather any
delta to the servers since there is technically nothing to send).
Obviously, in the {{CACHING_PROXY}} case, there is "local" state to compare
against, and therefore, Geode knows about the object already, in that it
"exists". It can therefore assess the object to determine if it is the
same/unchanged, and not do anything in the case the {{Delta.hasDelta}} returns
*false*, thus the "application" informing Geode there is nothing to send.
Clearly, in the {{PROXY}} case, this "local" state does not exist, and
therefore, Geode does not know whether the object (already) exists on the
servers or not. So, if {{Delta.hasDelta()}} returns *false*, it is unsure
whether the objects exists or not and so decides just to send the entire object
again, a "_premature optimization_" to be sure, which now has sacrificed
"_correctness_", and has amplified the possible "_race conditions_" on the
application side.
However, this is no different than if {{Delta.hasDelta()}} returns *true* and
the object is *not yet* known by the servers. When the client sends just the
delta in this case, the server will send back to the client, I don't know
anything about this object for which the delta needs to be applied, and
therefore, the client must turn around and send it the object anyway.
So, in the {{PROXY}} case, it would be better if the client made a
determination about whether the object truly exists on the server side or not
before arbitrarily and falsely assuming the entire object should be sent again
if the {{Delta.hasDelta()}} returns *false*. The client simply does not know
and should "verify" before sending the object.
Obviously this affects performance, but is a small price to pay (and the
"correct" thing to do) compared with "_lost updates_" and amplifying "_race
conditions_", client-side.
There is also a situation where {{CACHING_PROXY}} client Regions can even
*fail*, and that is when {{copy-on-read}} is set to *true*.
To make matters worse, even the
[_Javadoc_|http://geode.apache.org/releases/latest/javadoc/org/apache/geode/Delta.html#hasDelta--]
explains and implies that only "_pending changes_" are written if they exist...
> "Returns true if this object has pending changes it can write out."
Of course, this doc is less than clear and very ambiguous about what exactly
happens. But, to be sure, it is certainly not consistent in behavior when
different data management policies are effect, and most definitely not correct!
was:
Currently, if a cache client application is...
1) configured with a client {{PROXY}} Region, and...
2) the application is also using {{DataSerialization}} to de/serialize objects
to/from the servers, and...
3) the application domain objects implement the {{org.apache.geode.Delta}}
interface then Apache Geode will incorrectly send the entire object (again)
when {{Delta.hasDelta}} returns *false*.
It is understandable that the application domain object needs to be serialized
in its entirety the first time the object is sent to the server(s) (or if the
object is later, subsequently removed or has expired/been evicted, and then
needs to be re-added for whatever reason).
However, once the server(s) know about the object, then only ever a "delta"
should be sent, and only when {{Delta.hasDelta()}} returns *true*. Otherwise,
[jira] [Updated] (GEODE-6032) Entire object is serialized again (and again) when Delta.hasDelta() returns false and client is using PROXY Region
[
https://issues.apache.org/jira/browse/GEODE-6032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-6032:
-
Summary: Entire object is serialized again (and again) when
Delta.hasDelta() returns false and client is using PROXY Region (was: Entire
object is serialized again (and again) when Delta.hasDelta returns false and
client is using PROXY Region)
> Entire object is serialized again (and again) when Delta.hasDelta() returns
> false and client is using PROXY Region
> --
>
> Key: GEODE-6032
> URL: https://issues.apache.org/jira/browse/GEODE-6032
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.1.0, 1.1.1, 1.2.0, 1.3.0, 1.2.1, 1.4.0, 1.5.0, 1.6.0,
> 1.7.0
>Reporter: John Blum
>Priority: Critical
>
> Currently, if a cache client application is...
> 1) configured with a client {{PROXY}} Region, and...
> 2) the application is also using {{DataSerialization}} to de/serialize
> objects to/from the servers, and...
> 3) the application domain objects implement the {{org.apache.geode.Delta}}
> interface then Apache Geode will incorrectly send the entire object (again)
> when {{Delta.hasDelta}} returns *false*.
> It is understandable that the application domain object needs to be
> serialized in its entirety the first time the object is sent to the server(s)
> (or if the object is later, subsequently removed or has expired/been evicted,
> and then needs to be re-added for whatever reason).
> However, once the server(s) know about the object, then only ever a "delta"
> should be sent, and only when {{Delta.hasDelta()}} returns *true*.
> Otherwise, if {{Delta.hasDelta()}} returns *false*, then most certainly, the
> entire object should not be sent again, otherwise it is possible for the
> application to enter a "_race condition_" scenario where the object gets
> "overwritten", and as a result, the application can lose data (aka "_lost
> updates_").
> If users were to change their client Region data management policy from
> {{PROXY}} to {{CACHING_PROXY}} then this works as expected. Apache Geode
> will only send updates for an object it already knows about if there is
> actually a "delta", otherwise Geode does nothing (that is, does not send the
> entire object or any delta to the server(s) since there is technically
> nothing to send).
> Obviously, in the {{CACHING_PROXY}} case, there is "local" state to compare
> against, and therefore, Geode knows about the object already, in that it
> "exists". It can therefore assess the object to determine if it is the
> same/unchanged, and not do anything in the case where {{Delta.hasDelta()}}
> returns *false*, thus the "application" informing Geode there is nothing to
> send.
> Clearly, in the {{PROXY}} case, there is no "local" state, and therefore,
> Geode does not know whether the object (already) exists on the servers or
> not. So, if {{Delta.hasDelta()}} returns *false*, it is unsure whether the
> objects exists or not and so decides just to send the entire object again, a
> "_premature optimization_" to be sure, which now has sacrificed
> "_correctness_", and has amplified the possible "_race conditions_" on the
> application side.
> However, this is no different than if {{Delta.hasDelta()}} returns *true* and
> the object is *not yet* known by the servers. When the client sends just the
> delta in this case, the server will send back to the client, "I don't know
> anything about this object for which the delta needs to be applied", and
> therefore, the client must turn around and send it the entire object anyway.
> So, in the {{PROXY}} case, it would be better if the client made a
> determination about whether the object truly exists on the server side or
> not, first, before arbitrarily and falsely assuming the entire object should
> be sent again if the {{Delta.hasDelta()}} returns *false*. The client simply
> does not know and should "verify" before sending the object.
> Obviously, this affect will performance, but is a small price to pay (and the
> "correct" thing to do) compared with "_lost updates_" and amplifying "_race
> conditions_" on the client-side.
> There is also a situation where {{CACHING_PROXY}} client Regions can even
> *fail*, and that is when {{copy-on-read}} is set to *true*. Hopefully, this
> is obvious why.
> To make matters worse, even the
> [_Javadoc_|http://geode.apache.org/releases/latest/javadoc/org/apache/geode/Delta.html#hasDelta--]
> explains and implies that only "_pending changes_" are written if they
> exist...
> > "Returns true if this object has pending changes it can write out."
> Of course, this doc is less than clear and very ambiguous about what exactly
> ha
[jira] [Created] (GEODE-6033) Make the DistributedTest Rules support VM bounce
Kirk Lund created GEODE-6033: Summary: Make the DistributedTest Rules support VM bounce Key: GEODE-6033 URL: https://issues.apache.org/jira/browse/GEODE-6033 Project: Geode Issue Type: Improvement Components: tests Reporter: Kirk Lund I just noticed that if you try to use SharedErrorCollector in a DistributedTest that uses vm.bounce, the after() in the Rule will through NullPointerException in the vm that was bounced because nothing ever invoked the before() in the new instance of that vm. Presumably all of the DistributedTest Rules may fail in this way after using bounce. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-6033) Make the DistributedTest Rules support VM bounce
[ https://issues.apache.org/jira/browse/GEODE-6033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund reassigned GEODE-6033: Assignee: Kirk Lund > Make the DistributedTest Rules support VM bounce > > > Key: GEODE-6033 > URL: https://issues.apache.org/jira/browse/GEODE-6033 > Project: Geode > Issue Type: Improvement > Components: tests >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > > I just noticed that if you try to use SharedErrorCollector in a > DistributedTest that uses vm.bounce, the after() in the Rule will through > NullPointerException in the vm that was bounced because nothing ever invoked > the before() in the new instance of that vm. > Presumably all of the DistributedTest Rules may fail in this way after using > bounce. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6030) Upgrade commons-lang to commons-lang3
[ https://issues.apache.org/jira/browse/GEODE-6030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-6030: -- Labels: pull-request-available (was: ) > Upgrade commons-lang to commons-lang3 > - > > Key: GEODE-6030 > URL: https://issues.apache.org/jira/browse/GEODE-6030 > Project: Geode > Issue Type: Task > Components: build >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6007) Remove use of snprintf in NC code base
[ https://issues.apache.org/jira/browse/GEODE-6007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Bender updated GEODE-6007: Description: This is bad practice in general, and may open us up to maliciousness. There are two main situations in which we find lots of usage of snprintf with raw char buffers, which are: * formatting messages for exceptions * formatting messages for logging For the exception messages, we should switch to something known to be safe - a vsxprintf implementation, boost::format, std::stringstream, whatever. As long as we stop declaring raw char buffers on the stack, it's all good For logging, the situation is even dumber. The various LOG* macros in the code _already_ take a format string and varargs, so as far as I know we essentially need to move the printf-style arguments into the logging macro and get rid of the other nonsense. We may even buy a tiny performance improvement due to the fact that that logging macros can be compiled out of the code. UPDATE: Report from running LGTM on our code may be found at [https://lgtm.com/projects/g/apache/geode-native/alerts/?mode=list.] This report has issues with tons of printf-style format specifiers, so it catches most of the snprintf stuff pointed out above. MANY OF THESE ARE BUFFER OVERFLOW ISSUES, and must be addressed in the name of security. was: This is bad practice in general, and may open us up to maliciousness. There are two main situations in which we find lots of usage of snprintf with raw char buffers, which are: * formatting messages for exceptions * formatting messages for logging For the exception messages, we should switch to something known to be safe - a vsxprintf implementation, boost::format, std::stringstream, whatever. As long as we stop declaring raw char buffers on the stack, it's all good For logging, the situation is even dumber. The various LOG* macros in the code _already_ take a format string and varargs, so as far as I know we essentially need to move the printf-style arguments into the logging macro and get rid of the other nonsense. We may even buy a tiny performance improvement due to the fact that that logging macros can be compiled out of the code. > Remove use of snprintf in NC code base > -- > > Key: GEODE-6007 > URL: https://issues.apache.org/jira/browse/GEODE-6007 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Blake Bender >Priority: Major > > This is bad practice in general, and may open us up to maliciousness. There > are two main situations in which we find lots of usage of snprintf with raw > char buffers, which are: > * formatting messages for exceptions > * formatting messages for logging > For the exception messages, we should switch to something known to be safe - > a vsxprintf implementation, boost::format, std::stringstream, whatever. As > long as we stop declaring raw char buffers on the stack, it's all good > > For logging, the situation is even dumber. The various LOG* macros in the > code _already_ take a format string and varargs, so as far as I know we > essentially need to move the printf-style arguments into the logging macro > and get rid of the other nonsense. We may even buy a tiny performance > improvement due to the fact that that logging macros can be compiled out of > the code. > > UPDATE: Report from running LGTM on our code may be found at > [https://lgtm.com/projects/g/apache/geode-native/alerts/?mode=list.] This > report has issues with tons of printf-style format specifiers, so it catches > most of the snprintf stuff pointed out above. MANY OF THESE ARE BUFFER > OVERFLOW ISSUES, and must be addressed in the name of security. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5957) Unexpected exception when executing an unknown function.
[ https://issues.apache.org/jira/browse/GEODE-5957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-5957: -- Labels: pull-request-available (was: ) > Unexpected exception when executing an unknown function. > > > Key: GEODE-5957 > URL: https://issues.apache.org/jira/browse/GEODE-5957 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Sai Boorlagadda >Priority: Major > Labels: pull-request-available > > libc++abi.dylib: terminating with uncaught exception of type > apache::geode::client::MessageException: : message from server could not be > handled -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6020) run non-gating jobs iff all gating jobs have passed
[ https://issues.apache.org/jira/browse/GEODE-6020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16682005#comment-16682005 ] ASF subversion and git services commented on GEODE-6020: Commit 70771cb2040032f9d3a50d16dad63fa13e083e0e in geode's branch refs/heads/develop from [~dcavender] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=70771cb ] Merge pull request #2816 from onichols-pivotal/GEODE-6020-run-non-gating-jobs-iff-all-gating-pass GEODE-6020 make non-gating jobs run only after all gating jobs have passed > run non-gating jobs iff all gating jobs have passed > --- > > Key: GEODE-6020 > URL: https://issues.apache.org/jira/browse/GEODE-6020 > Project: Geode > Issue Type: Sub-task > Components: ci >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > This fix would defer running Windows tests until the commit has passed all > tests on Linux. This would reduce resource usage when some test does not > pass, and would also alleviate the 18-jobs-tall stack in the Complete view. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6020) run non-gating jobs iff all gating jobs have passed
[ https://issues.apache.org/jira/browse/GEODE-6020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16682004#comment-16682004 ] ASF subversion and git services commented on GEODE-6020: Commit 70771cb2040032f9d3a50d16dad63fa13e083e0e in geode's branch refs/heads/develop from [~dcavender] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=70771cb ] Merge pull request #2816 from onichols-pivotal/GEODE-6020-run-non-gating-jobs-iff-all-gating-pass GEODE-6020 make non-gating jobs run only after all gating jobs have passed > run non-gating jobs iff all gating jobs have passed > --- > > Key: GEODE-6020 > URL: https://issues.apache.org/jira/browse/GEODE-6020 > Project: Geode > Issue Type: Sub-task > Components: ci >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > This fix would defer running Windows tests until the commit has passed all > tests on Linux. This would reduce resource usage when some test does not > pass, and would also alleviate the 18-jobs-tall stack in the Complete view. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6009) add Java11 to PR pipeline
[ https://issues.apache.org/jira/browse/GEODE-6009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16682001#comment-16682001 ] ASF subversion and git services commented on GEODE-6009: Commit 9b2a4239b79822ee6184e8fdbbf06a3de96c37bf in geode's branch refs/heads/develop from [~dcavender] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=9b2a423 ] Merge pull request #2806 from onichols-pivotal/GEODE-6009-add-java-11-to-PR-pipeline GEODE-6009 add Java 11 to PR pipeline > add Java11 to PR pipeline > - > > Key: GEODE-6009 > URL: https://issues.apache.org/jira/browse/GEODE-6009 > Project: Geode > Issue Type: Sub-task > Components: ci >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > Time Spent: 1h > Remaining Estimate: 0h > > Now that Java 11 is gating for the develop pipeline, it should be tested in > PR pipeline as well! Otherwise you can end up with a checkin that passes PR > but breaks develop, which has already happened at least once. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6020) run non-gating jobs iff all gating jobs have passed
[ https://issues.apache.org/jira/browse/GEODE-6020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16682003#comment-16682003 ] ASF subversion and git services commented on GEODE-6020: Commit a649956da9ad41584e57e1b390dbd7d88bfdf87c in geode's branch refs/heads/develop from [~onichols-pivotal] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=a649956 ] GEODE-6020 make non-gating jobs run only after all gating jobs have passed > run non-gating jobs iff all gating jobs have passed > --- > > Key: GEODE-6020 > URL: https://issues.apache.org/jira/browse/GEODE-6020 > Project: Geode > Issue Type: Sub-task > Components: ci >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > This fix would defer running Windows tests until the commit has passed all > tests on Linux. This would reduce resource usage when some test does not > pass, and would also alleviate the 18-jobs-tall stack in the Complete view. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6009) add Java11 to PR pipeline
[ https://issues.apache.org/jira/browse/GEODE-6009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16682000#comment-16682000 ] ASF subversion and git services commented on GEODE-6009: Commit d7aa60c1e6ec02ec01550afbf050961d08e326bb in geode's branch refs/heads/develop from [~onichols-pivotal] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=d7aa60c ] GEODE-6009 add Java 11 to PR pipeline > add Java11 to PR pipeline > - > > Key: GEODE-6009 > URL: https://issues.apache.org/jira/browse/GEODE-6009 > Project: Geode > Issue Type: Sub-task > Components: ci >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > Time Spent: 1h > Remaining Estimate: 0h > > Now that Java 11 is gating for the develop pipeline, it should be tested in > PR pipeline as well! Otherwise you can end up with a checkin that passes PR > but breaks develop, which has already happened at least once. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6031) Add getCache to ServerLauncher and LocatorLauncher APIs
[
https://issues.apache.org/jira/browse/GEODE-6031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-6031:
--
Labels: pull-request-available (was: )
> Add getCache to ServerLauncher and LocatorLauncher APIs
> ---
>
> Key: GEODE-6031
> URL: https://issues.apache.org/jira/browse/GEODE-6031
> Project: Geode
> Issue Type: Improvement
> Components: core
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: pull-request-available
>
> The ServerLauncher and LocatorLauncher APIs are used in two ways: 1) by GFSH
> to fork a new Server or Locator, 2) by User to create a new Server or Locator
> locally in a JVM.
> This improvement adds getCache() to the APIs to enable the User in #2 to get
> a reference without having to resort to invoking singleton getters.
> {noformat}
> /**
> * Gets a reference to the Cache that was created by this ServerLauncher.
> *
> * @return a reference to the Cache
> */
> public org.apache.geode.cache.Cache getCache();
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-6026) Lucene test classes should not be listed in Javadocs
[ https://issues.apache.org/jira/browse/GEODE-6026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob S. Barrett reassigned GEODE-6026: --- Assignee: Jacob S. Barrett > Lucene test classes should not be listed in Javadocs > > > Key: GEODE-6026 > URL: https://issues.apache.org/jira/browse/GEODE-6026 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: Diane Hardman >Assignee: Jacob S. Barrett >Priority: Major > Fix For: 1.7.0 > > > In the latest Javadocs for Lucene there are several test classes and > utilities listed that should not be: > package org.apache.geode.cache.lucene.test > under package org.apache.geode.cache.lucene Class Summary: > * DummyLuceneSerializer > * LuceneIntegrationTest -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6026) Lucene test classes should not be listed in Javadocs
[ https://issues.apache.org/jira/browse/GEODE-6026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-6026: -- Labels: pull-request-available (was: ) > Lucene test classes should not be listed in Javadocs > > > Key: GEODE-6026 > URL: https://issues.apache.org/jira/browse/GEODE-6026 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: Diane Hardman >Assignee: Jacob S. Barrett >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > > In the latest Javadocs for Lucene there are several test classes and > utilities listed that should not be: > package org.apache.geode.cache.lucene.test > under package org.apache.geode.cache.lucene Class Summary: > * DummyLuceneSerializer > * LuceneIntegrationTest -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6009) add Java11 to PR pipeline
[ https://issues.apache.org/jira/browse/GEODE-6009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16682002#comment-16682002 ] ASF subversion and git services commented on GEODE-6009: Commit 9b2a4239b79822ee6184e8fdbbf06a3de96c37bf in geode's branch refs/heads/develop from [~dcavender] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=9b2a423 ] Merge pull request #2806 from onichols-pivotal/GEODE-6009-add-java-11-to-PR-pipeline GEODE-6009 add Java 11 to PR pipeline > add Java11 to PR pipeline > - > > Key: GEODE-6009 > URL: https://issues.apache.org/jira/browse/GEODE-6009 > Project: Geode > Issue Type: Sub-task > Components: ci >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > Time Spent: 1h > Remaining Estimate: 0h > > Now that Java 11 is gating for the develop pipeline, it should be tested in > PR pipeline as well! Otherwise you can end up with a checkin that passes PR > but breaks develop, which has already happened at least once. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-5073) Native client should not access or modify internal regions
[ https://issues.apache.org/jira/browse/GEODE-5073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruce Schuchardt reassigned GEODE-5073: --- Assignee: Bruce Schuchardt > Native client should not access or modify internal regions > -- > > Key: GEODE-5073 > URL: https://issues.apache.org/jira/browse/GEODE-5073 > Project: Geode > Issue Type: Sub-task > Components: native client >Reporter: Darrel Schneider >Assignee: Bruce Schuchardt >Priority: Major > > When the server processes a message from a native client that contains a > region name, it should use getApplicationRegion instead of getRegion. > Note that fixing this for the java client may completely fix it for the > native client. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-5072) Java clients should not access or modify internal regions
[ https://issues.apache.org/jira/browse/GEODE-5072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruce Schuchardt reassigned GEODE-5072: --- Assignee: Bruce Schuchardt > Java clients should not access or modify internal regions > - > > Key: GEODE-5072 > URL: https://issues.apache.org/jira/browse/GEODE-5072 > Project: Geode > Issue Type: Sub-task > Components: client/server >Reporter: Darrel Schneider >Assignee: Bruce Schuchardt >Priority: Major > > When a server processes a client message that contains a region name, it > should use getApplicationRegion instead of getRegion. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-5074) REST dev client should not access or modify internal regions
[ https://issues.apache.org/jira/browse/GEODE-5074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruce Schuchardt reassigned GEODE-5074: --- Assignee: Bruce Schuchardt > REST dev client should not access or modify internal regions > > > Key: GEODE-5074 > URL: https://issues.apache.org/jira/browse/GEODE-5074 > Project: Geode > Issue Type: Sub-task > Components: rest (dev) >Reporter: Darrel Schneider >Assignee: Bruce Schuchardt >Priority: Major > > When a request is processed from a REST dev client that contains a region > name, then getApplicationRegion should be used instead of getRegion. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-3981) Cache should not provide access to internal regions from public APIs
[ https://issues.apache.org/jira/browse/GEODE-3981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruce Schuchardt reassigned GEODE-3981: --- Assignee: Bruce Schuchardt > Cache should not provide access to internal regions from public APIs > > > Key: GEODE-3981 > URL: https://issues.apache.org/jira/browse/GEODE-3981 > Project: Geode > Issue Type: Improvement >Reporter: Fred Krone >Assignee: Bruce Schuchardt >Priority: Major > > We should protect the user from accidentally modifying an internal region. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-5076) jmx client should not access or modify internal regions
[ https://issues.apache.org/jira/browse/GEODE-5076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruce Schuchardt reassigned GEODE-5076: --- Assignee: Bruce Schuchardt > jmx client should not access or modify internal regions > --- > > Key: GEODE-5076 > URL: https://issues.apache.org/jira/browse/GEODE-5076 > Project: Geode > Issue Type: Sub-task > Components: jmx >Reporter: Darrel Schneider >Assignee: Bruce Schuchardt >Priority: Major > > When a request from a jmx client (including gfsh) is processed that contains > a region name, then getApplicationRegion should be used instead of getRegion. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-5075) REST admin client should not access or modify internal regions
[ https://issues.apache.org/jira/browse/GEODE-5075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruce Schuchardt reassigned GEODE-5075: --- Assignee: Bruce Schuchardt > REST admin client should not access or modify internal regions > -- > > Key: GEODE-5075 > URL: https://issues.apache.org/jira/browse/GEODE-5075 > Project: Geode > Issue Type: Sub-task > Components: rest (admin) >Reporter: Darrel Schneider >Assignee: Bruce Schuchardt >Priority: Major > > When a request is processed from a REST admin client that contains a region > name, then getApplicationRegion should be called instead of getRegion -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6034) Protobuf clients should not access or modify internal regions
Bruce Schuchardt created GEODE-6034: --- Summary: Protobuf clients should not access or modify internal regions Key: GEODE-6034 URL: https://issues.apache.org/jira/browse/GEODE-6034 Project: Geode Issue Type: Sub-task Reporter: Bruce Schuchardt -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-6034) Protobuf clients should not access or modify internal regions
[ https://issues.apache.org/jira/browse/GEODE-6034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruce Schuchardt reassigned GEODE-6034: --- Assignee: Bruce Schuchardt > Protobuf clients should not access or modify internal regions > - > > Key: GEODE-6034 > URL: https://issues.apache.org/jira/browse/GEODE-6034 > Project: Geode > Issue Type: Sub-task >Reporter: Bruce Schuchardt >Assignee: Bruce Schuchardt >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5993) QueryMonitor can throw RejectedExecutionException due to race
[ https://issues.apache.org/jira/browse/GEODE-5993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16682056#comment-16682056 ] ASF subversion and git services commented on GEODE-5993: Commit aab0198e8478d4246042b2eb889c8ce7e28bb52e in geode's branch refs/heads/develop from [~propeller] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=aab0198 ] GEODE-5993: Eliminate race in monitorQueryThread() (#2818) A race existed between setting low memory in the heap monitor thread, and checking the low memory state in query monitoring thread. The cancelation executor was shut down and no longer accepting new tasks when this race occurred, causing a RejectedExecutionException. This commit solves that problem by encapsulating the scheduling behavior using the state design pattern. Co-authored-by: Ryan McMahon Co-authored-by: Bill Burcham > QueryMonitor can throw RejectedExecutionException due to race > - > > Key: GEODE-5993 > URL: https://issues.apache.org/jira/browse/GEODE-5993 > Project: Geode > Issue Type: Bug > Components: querying >Reporter: Ryan McMahon >Assignee: Ryan McMahon >Priority: Major > Labels: pull-request-available > Fix For: 1.8.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > It is possible for a RejectedExecutionException to be thrown due to the > following race: > Thread 1) > - Call monitorQueryThread() and pass LOW_MEMORY check > Thread 2) > - Call cancelAllQueriesDueToMemory() > - Shutdown executor > Thread 1) > - Schedule cancellation task results in RejectedExecutionException -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6009) add Java11 to PR pipeline
[ https://issues.apache.org/jira/browse/GEODE-6009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16682073#comment-16682073 ] ASF subversion and git services commented on GEODE-6009: Commit 75d7ed8a49d64dd76bcab0a63bccad2e33539d84 in geode's branch refs/heads/develop from [~dcavender] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=75d7ed8 ] Merge pull request #2834 from onichols-pivotal/GEODE-6009-add-Java11-PR-checks GEODE-6009 add Java 11 PR checks to github > add Java11 to PR pipeline > - > > Key: GEODE-6009 > URL: https://issues.apache.org/jira/browse/GEODE-6009 > Project: Geode > Issue Type: Sub-task > Components: ci >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > Time Spent: 1h 20m > Remaining Estimate: 0h > > Now that Java 11 is gating for the develop pipeline, it should be tested in > PR pipeline as well! Otherwise you can end up with a checkin that passes PR > but breaks develop, which has already happened at least once. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6009) add Java11 to PR pipeline
[ https://issues.apache.org/jira/browse/GEODE-6009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16682072#comment-16682072 ] ASF subversion and git services commented on GEODE-6009: Commit 4f9580a009f68dfe87768c90285e666e07795ecb in geode's branch refs/heads/develop from [~onichols-pivotal] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=4f9580a ] GEODE-6009 add Java 11 PR checks to github > add Java11 to PR pipeline > - > > Key: GEODE-6009 > URL: https://issues.apache.org/jira/browse/GEODE-6009 > Project: Geode > Issue Type: Sub-task > Components: ci >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > Time Spent: 1h 20m > Remaining Estimate: 0h > > Now that Java 11 is gating for the develop pipeline, it should be tested in > PR pipeline as well! Otherwise you can end up with a checkin that passes PR > but breaks develop, which has already happened at least once. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6009) add Java11 to PR pipeline
[ https://issues.apache.org/jira/browse/GEODE-6009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16682074#comment-16682074 ] ASF subversion and git services commented on GEODE-6009: Commit 75d7ed8a49d64dd76bcab0a63bccad2e33539d84 in geode's branch refs/heads/develop from [~dcavender] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=75d7ed8 ] Merge pull request #2834 from onichols-pivotal/GEODE-6009-add-Java11-PR-checks GEODE-6009 add Java 11 PR checks to github > add Java11 to PR pipeline > - > > Key: GEODE-6009 > URL: https://issues.apache.org/jira/browse/GEODE-6009 > Project: Geode > Issue Type: Sub-task > Components: ci >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > Time Spent: 1h 20m > Remaining Estimate: 0h > > Now that Java 11 is gating for the develop pipeline, it should be tested in > PR pipeline as well! Otherwise you can end up with a checkin that passes PR > but breaks develop, which has already happened at least once. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6035) Increase backlog for peer-to-peer connection formation
Bruce Schuchardt created GEODE-6035: --- Summary: Increase backlog for peer-to-peer connection formation Key: GEODE-6035 URL: https://issues.apache.org/jira/browse/GEODE-6035 Project: Geode Issue Type: Bug Components: membership Reporter: Bruce Schuchardt The default ServerSocket backlog is 10 but it should be raised to something more like 500. I think the supposition was that an attempt to connect when the backlog is full would cause an IOConnection but experiments show that this isn't the case. The Java socket implementation keeps trying for something like 25 seconds before giving up. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-6035) Increase backlog for peer-to-peer connection formation
[ https://issues.apache.org/jira/browse/GEODE-6035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruce Schuchardt reassigned GEODE-6035: --- Assignee: Bruce Schuchardt > Increase backlog for peer-to-peer connection formation > -- > > Key: GEODE-6035 > URL: https://issues.apache.org/jira/browse/GEODE-6035 > Project: Geode > Issue Type: Improvement > Components: membership >Reporter: Bruce Schuchardt >Assignee: Bruce Schuchardt >Priority: Minor > > The default ServerSocket backlog is 10 but it should be raised to something > more like 500. I think the supposition was that an attempt to connect when > the backlog is full would cause an IOConnection but experiments show that > this isn't the case. The Java socket implementation keeps trying for > something like 25 seconds before giving up. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6035) Increase backlog for peer-to-peer connection formation
[ https://issues.apache.org/jira/browse/GEODE-6035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruce Schuchardt updated GEODE-6035: Priority: Minor (was: Major) > Increase backlog for peer-to-peer connection formation > -- > > Key: GEODE-6035 > URL: https://issues.apache.org/jira/browse/GEODE-6035 > Project: Geode > Issue Type: Improvement > Components: membership >Reporter: Bruce Schuchardt >Priority: Minor > > The default ServerSocket backlog is 10 but it should be raised to something > more like 500. I think the supposition was that an attempt to connect when > the backlog is full would cause an IOConnection but experiments show that > this isn't the case. The Java socket implementation keeps trying for > something like 25 seconds before giving up. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6016) Geode function execution in client transaction with singleHopEnabled is not transactional
[ https://issues.apache.org/jira/browse/GEODE-6016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu updated GEODE-6016: Affects Version/s: 1.1.0 > Geode function execution in client transaction with singleHopEnabled is not > transactional > - > > Key: GEODE-6016 > URL: https://issues.apache.org/jira/browse/GEODE-6016 > Project: Geode > Issue Type: Bug > Components: transactions >Affects Versions: 1.1.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Fix For: 1.9.0 > > > When function execution with single hop enabled, a function execution thread > will execute the function. The function execution thread does not send a > transactional message to server and this causes the function execution non > transactional. > This occurs when txmanager.begin is invoked on client like the following: > txManager.begin(); > ResultCollector resultCollector = > execution.withFilter(keySet).execute(function); resultCollector.getResult(); > txManager.commit()/rollback(); > If txmanager.begin() is embedded in function body, there is no issue as > transaction starts on server directly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6035) Increase backlog for peer-to-peer connection formation
[ https://issues.apache.org/jira/browse/GEODE-6035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruce Schuchardt updated GEODE-6035: Issue Type: Improvement (was: Bug) > Increase backlog for peer-to-peer connection formation > -- > > Key: GEODE-6035 > URL: https://issues.apache.org/jira/browse/GEODE-6035 > Project: Geode > Issue Type: Improvement > Components: membership >Reporter: Bruce Schuchardt >Priority: Major > > The default ServerSocket backlog is 10 but it should be raised to something > more like 500. I think the supposition was that an attempt to connect when > the backlog is full would cause an IOConnection but experiments show that > this isn't the case. The Java socket implementation keeps trying for > something like 25 seconds before giving up. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5072) Java clients should not access or modify internal regions
[ https://issues.apache.org/jira/browse/GEODE-5072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16682094#comment-16682094 ] ASF subversion and git services commented on GEODE-5072: Commit 98927d1f49221b3cd617337299c799de5470e072 in geode's branch refs/heads/feature/GEODE-5072 from [~bschuchardt] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=98927d1 ] GEODE-5072 Java clients should not access or modify internal regions Modified the kind of cache available to client/server command processing in order to restrict access to internal regions. > Java clients should not access or modify internal regions > - > > Key: GEODE-5072 > URL: https://issues.apache.org/jira/browse/GEODE-5072 > Project: Geode > Issue Type: Sub-task > Components: client/server >Reporter: Darrel Schneider >Assignee: Bruce Schuchardt >Priority: Major > Labels: pull-request-available > > When a server processes a client message that contains a region name, it > should use getApplicationRegion instead of getRegion. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4728) Geode Native Documentation Improvements
[ https://issues.apache.org/jira/browse/GEODE-4728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16682097#comment-16682097 ] ASF subversion and git services commented on GEODE-4728: Commit 5ec2c17cb7a0f58403c2aae094927305266d2ea5 in geode-native's branch refs/heads/develop from [~dbarnes97] [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=5ec2c17 ] GEODE-4728 Geode NC doc: Add a Security topic > Geode Native Documentation Improvements > --- > > Key: GEODE-4728 > URL: https://issues.apache.org/jira/browse/GEODE-4728 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Addison >Priority: Major > Labels: pull-request-available > Time Spent: 3h 40m > Remaining Estimate: 0h > > This ticket will capture a series of changes to the Geode Native docs to > bring them inline with the updated API. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5072) Java clients should not access or modify internal regions
[ https://issues.apache.org/jira/browse/GEODE-5072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-5072: -- Labels: pull-request-available (was: ) > Java clients should not access or modify internal regions > - > > Key: GEODE-5072 > URL: https://issues.apache.org/jira/browse/GEODE-5072 > Project: Geode > Issue Type: Sub-task > Components: client/server >Reporter: Darrel Schneider >Assignee: Bruce Schuchardt >Priority: Major > Labels: pull-request-available > > When a server processes a client message that contains a region name, it > should use getApplicationRegion instead of getRegion. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6036) sanctionedDataSerializables.txt is in a different order from the generated code
Galen O'Sullivan created GEODE-6036: --- Summary: sanctionedDataSerializables.txt is in a different order from the generated code Key: GEODE-6036 URL: https://issues.apache.org/jira/browse/GEODE-6036 Project: Geode Issue Type: Bug Components: serialization, tests Reporter: Galen O'Sullivan This means that if anyone tries to merge something and copy the actual over the expected, it will result in a huge diff. Let's do that copy with no changes and make reviewing other changes easier. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-6036) sanctionedDataSerializables.txt is in a different order from the generated code
[ https://issues.apache.org/jira/browse/GEODE-6036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Galen O'Sullivan reassigned GEODE-6036: --- Assignee: Galen O'Sullivan > sanctionedDataSerializables.txt is in a different order from the generated > code > --- > > Key: GEODE-6036 > URL: https://issues.apache.org/jira/browse/GEODE-6036 > Project: Geode > Issue Type: Bug > Components: serialization, tests >Reporter: Galen O'Sullivan >Assignee: Galen O'Sullivan >Priority: Major > > This means that if anyone tries to merge something and copy the actual over > the expected, it will result in a huge diff. Let's do that copy with no > changes and make reviewing other changes easier. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-6010) JDBC Connector should automatically configure JDBCLoader and JDBCAsyncWriter
[
https://issues.apache.org/jira/browse/GEODE-6010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider reassigned GEODE-6010:
---
Assignee: Darrel Schneider (was: Jianxia Chen)
> JDBC Connector should automatically configure JDBCLoader and JDBCAsyncWriter
>
>
> Key: GEODE-6010
> URL: https://issues.apache.org/jira/browse/GEODE-6010
> Project: Geode
> Issue Type: Improvement
> Components: extensions
>Reporter: Jianxia Chen
>Assignee: Darrel Schneider
>Priority: Major
>
> *As a* Geode user
> *When* I create a JDBC mapping using the create jdbc-mapping command
> *Then* I should not be required to perform additional configuration to get
> the data flowing between Geode and relational database.
> Currently, the user is expected to specify a CacheLoader and an
> AsyncEventQueue, which should not be required. We should also go ahead and
> create an async event queue with default values when a jdbc-mapping is
> created. (one queue per mapping)
>
> *Acceptance Criteria:*
> *Given* that a *partitioned* region has previously been created
> *When* a mapping is created using {{create jdbc-mapping}} command
> *Then* {{list async-event-queues}} command shows a newly created *parallel*
> AEQ
> *And* {{describe region}} command shows our cache-loader and
> async-event-queue-id configured
> *Given* that a *replicated* region has previously been created
> *When* a mapping is created using {{create jdbc-mapping}} command
> *Then* {{list async-event-queues}} command shows a newly created *serial* AEQ
> *And* {{describe region}} command shows our cache-loader and
> async-event-queue-id configured
> If cluster configuration is not enabled, it should throw an error.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-6010) JDBC Connector should automatically configure JDBCLoader and JDBCAsyncWriter
[
https://issues.apache.org/jira/browse/GEODE-6010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-6010:
--
Labels: pull-request-available (was: )
> JDBC Connector should automatically configure JDBCLoader and JDBCAsyncWriter
>
>
> Key: GEODE-6010
> URL: https://issues.apache.org/jira/browse/GEODE-6010
> Project: Geode
> Issue Type: Improvement
> Components: extensions
>Reporter: Jianxia Chen
>Assignee: Darrel Schneider
>Priority: Major
> Labels: pull-request-available
>
> *As a* Geode user
> *When* I create a JDBC mapping using the create jdbc-mapping command
> *Then* I should not be required to perform additional configuration to get
> the data flowing between Geode and relational database.
> Currently, the user is expected to specify a CacheLoader and an
> AsyncEventQueue, which should not be required. We should also go ahead and
> create an async event queue with default values when a jdbc-mapping is
> created. (one queue per mapping)
>
> *Acceptance Criteria:*
> *Given* that a *partitioned* region has previously been created
> *When* a mapping is created using {{create jdbc-mapping}} command
> *Then* {{list async-event-queues}} command shows a newly created *parallel*
> AEQ
> *And* {{describe region}} command shows our cache-loader and
> async-event-queue-id configured
> *Given* that a *replicated* region has previously been created
> *When* a mapping is created using {{create jdbc-mapping}} command
> *Then* {{list async-event-queues}} command shows a newly created *serial* AEQ
> *And* {{describe region}} command shows our cache-loader and
> async-event-queue-id configured
> If cluster configuration is not enabled, it should throw an error.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
