[jira] [Commented] (GEODE-2203) gfsh status locator/server - Give more descriptive output on empty parameter
[
https://issues.apache.org/jira/browse/GEODE-2203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500350#comment-16500350
]
Barbara Pruijn commented on GEODE-2203:
---
If no option is specified, the output is misleading.
{code:java}
gfsh>start locator --name=l1
Starting a Geode Locator in /Users/bpruijn/geode_tmp/l1...
Locator in /Users/bpruijn/geode_tmp/l1 on 10.118.20.117[10334] as l1 is
currently online.
Process ID: 20034
Uptime: 5 seconds
Geode Version: 1.8.0-SNAPSHOT
Java Version: 1.8.0_151
Log File: /Users/bpruijn/geode_tmp/l1/l1.log
JVM Arguments: -Dgemfire.enable-cluster-configuration=true
-Dgemfire.load-cluster-configuration-from-dir=false
-Dgemfire.launcher.registerSignalHandlers=true -Djava.awt.headless=true
-Dsun.rmi.dgc.server.gcInterval=9223372036854775806
Class-Path:
/Users/bpruijn/workspace/gemfire/open/geode-assembly/build/install/apache-geode/lib/geode-core-1.8.0-SNAPSHOT.jar:/Users/bpruijn/workspace/gemfire/open/geode-assembly/build/install/apache-geode/lib/geode-dependencies.jar
Successfully connected to: JMX Manager [host=10.118.20.117, port=1099]
Cluster configuration service is up and running.
gfsh>status locator
Locator in /Users/bpruijn/geode_tmp on 10.118.20.117[10334] is currently not
responding.
gfsh>status locator --name=l1
Locator in /Users/bpruijn/geode_tmp/l1 on 10.118.20.117[10334] as l1 is
currently online.
Process ID: 20034
Uptime: 26 seconds
Geode Version: 1.8.0-SNAPSHOT
Java Version: 1.8.0_151
Log File: /Users/bpruijn/geode_tmp/l1/l1.log
JVM Arguments: -Dgemfire.enable-cluster-configuration=true
-Dgemfire.load-cluster-configuration-from-dir=false
-Dgemfire.launcher.registerSignalHandlers=true -Djava.awt.headless=true
-Dsun.rmi.dgc.server.gcInterval=9223372036854775806
Class-Path:
/Users/bpruijn/workspace/gemfire/open/geode-assembly/build/install/apache-geode/lib/geode-core-1.8.0-SNAPSHOT.jar:/Users/bpruijn/workspace/gemfire/open/geode-assembly/build/install/apache-geode/lib/geode-dependencies.jar
Cluster configuration service is up and running.
{code}
> gfsh status locator/server - Give more descriptive output on empty parameter
>
>
> Key: GEODE-2203
> URL: https://issues.apache.org/jira/browse/GEODE-2203
> Project: Geode
> Issue Type: Improvement
> Components: gfsh
>Reporter: Alyssa Kim
>Priority: Minor
> Labels: StatusLocatorCommand, StatusServerCommand, gfsh, status
>
> Currently, executing some status commands in gfsh without valid parameters
> gives a vague explanation/output that might be misleading. Although we have
> help for usage description, displaying 'null' as an output
> might not be the best idea.
> Current Result
> {code}
> gfsh>status locator
> null
> {code}
> {code}
> gfsh>status server
> Server in
> C:\Users\XXX\git\incubator-geode\geode-assembly\build\install\apache-geode\bin
> on null is currently not responding.
> {code}
> Improvement
> {code}
> gfsh>status locator
> SYNTAX
> status locator [--name=value] [--host=value] [--port=value] [--pid=value]
> Use help status locator to display detailed usage information
> {code}
> {code}
> gfsh>status server
> SYNTAX
> status server [--name=value] [--pid=value] [--dir=value]
> Use help status server to display detailed usage information
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (GEODE-5204) Add 'get/set cluster-config' gfsh command
[
https://issues.apache.org/jira/browse/GEODE-5204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16489235#comment-16489235
]
Barbara Pruijn edited comment on GEODE-5204 at 5/24/18 4:28 PM:
After more consideration, we have decided to add the set functionality to the
existing import cluster-configuration command.
The following options will be added:
{code:java}
import cluster-configuration --xml --group --action{code}
The options --xml and --group will work combined.
Default value for --action is apply. This will apply the given configuration
to the cluster and will store the configuration in the cluster configuration.
If the cluster is running and has configuration and data, this will fail.
The other value for --action is stage. This will put the configuration in the
cluster configuration but will not apply it to the running servers.
The --action will also work with the --zip option.
The get functionality will be added to the existing export
cluster-configuration command:
{code:java}
export cluster-configuration --file{code}
will export the cluster configuration xml in one file and not a zipped
directory structure. It will also not include the jar files.
was (Author: bpruijn):
After more consideration, we have decided to add this functionality to the
existing import cluster-configuration command.
The following options will be added:
{code:java}
import cluster-configuration --xml --group --action{code}
The options --xml and --group will work combined.
Default value for --action is apply. This will apply the given configuration to
the cluster and will store the configuration in the cluster configuration. If
the cluster is running and has configuration and data, this will fail.
The other value for --action is stage. This will put the configuration in the
cluster configuration but will not apply it to the running servers.
The --action will also work with the --zip option.
> Add 'get/set cluster-config' gfsh command
> -
>
> Key: GEODE-5204
> URL: https://issues.apache.org/jira/browse/GEODE-5204
> Project: Geode
> Issue Type: Improvement
> Components: docs, gfsh
>Reporter: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Add a new gfsh command to update an existing cluster config xml.
> The command should only update the cluster configuration and not affect the
> config of running servers (this will be added later).
> The set command should take options {{\-\-group}}, {{\-\-xml}} and
> {{\-\-properties}}. The default group should be {{"cluster"}}.
> The command should only need to be run on a single locator and have changes
> propagated to all other locators.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5204) Add 'get/set cluster-config' gfsh command
[
https://issues.apache.org/jira/browse/GEODE-5204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16489235#comment-16489235
]
Barbara Pruijn commented on GEODE-5204:
---
After more consideration, we have decided to add this functionality to the
existing import cluster-configuration command.
The following options will be added:
{code:java}
import cluster-configuration --xml --group --action{code}
The options --xml and --group will work combined.
Default value for --action is apply. This will apply the given configuration to
the cluster and will store the configuration in the cluster configuration. If
the cluster is running and has configuration and data, this will fail.
The other value for --action is stage. This will put the configuration in the
cluster configuration but will not apply it to the running servers.
The --action will also work with the --zip option.
> Add 'get/set cluster-config' gfsh command
> -
>
> Key: GEODE-5204
> URL: https://issues.apache.org/jira/browse/GEODE-5204
> Project: Geode
> Issue Type: Improvement
> Components: docs, gfsh
>Reporter: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Add a new gfsh command to update an existing cluster config xml.
> The command should only update the cluster configuration and not affect the
> config of running servers (this will be added later).
> The set command should take options {{\-\-group}}, {{\-\-xml}} and
> {{\-\-properties}}. The default group should be {{"cluster"}}.
> The command should only need to be run on a single locator and have changes
> propagated to all other locators.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5204) Add 'get/set cluster-config' gfsh command
[
https://issues.apache.org/jira/browse/GEODE-5204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn updated GEODE-5204:
--
Component/s: docs
> Add 'get/set cluster-config' gfsh command
> -
>
> Key: GEODE-5204
> URL: https://issues.apache.org/jira/browse/GEODE-5204
> Project: Geode
> Issue Type: Improvement
> Components: docs, gfsh
>Reporter: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Add a new gfsh command to update an existing cluster config xml.
> The command should only update the cluster configuration and not affect the
> config of running servers (this will be added later).
> The set command should take options {{\-\-group}}, {{\-\-xml}} and
> {{\-\-properties}}. The default group should be {{"cluster"}}.
> The command should only need to be run on a single locator and have changes
> propagated to all other locators.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5230) Pulse does not work when SSL is enabled for JMX
[
https://issues.apache.org/jira/browse/GEODE-5230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn resolved GEODE-5230.
---
Resolution: Fixed
> Pulse does not work when SSL is enabled for JMX
> ---
>
> Key: GEODE-5230
> URL: https://issues.apache.org/jira/browse/GEODE-5230
> Project: Geode
> Issue Type: Bug
> Components: pulse
>Reporter: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> If I start a locator with SSL enabled {{ssl-components=ALL}} then Pulse does
> not work. When logging in I see an error message like:
> {noformat}
> Connecting ...
> Failed to retrieve RMIServer stub: javax.naming.CommunicationException [Root
> exception is java.rmi.ConnectIOException: error during JRMP connection
> establishment; nested exception is: javax.net.ssl.SSLHandshakeException:
> sun.security.validator.ValidatorException: PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target]
> {noformat}
> pulse.log shows the same:
> {noformat}
> Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable
> to find valid certification path to requested target
> at
> sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
> ~[?:1.8.0_161]
> at
> sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
> ~[?:1.8.0_161]
> at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280)
> ~[?:1.8.0_161]
> at
> sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:392)
> ~[?:1.8.0_161]
> at
> sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:302)
> ~[?:1.8.0_161]
> at sun.security.validator.Validator.validate(Validator.java:260)
> ~[?:1.8.0_161]
> at
> sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324)
> ~[?:1.8.0_161]
> at
> sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:229)
> ~[?:1.8.0_161]
> at
> sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:124)
> ~[?:1.8.0_161]
> at
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1596)
> ~[?:1.8.0_161]
> at
> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
> ~[?:1.8.0_161]
> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1052)
> ~[?:1.8.0_161]
> at sun.security.ssl.Handshaker.process_record(Handshaker.java:987)
> ~[?:1.8.0_161]
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1072)
> ~[?:1.8.0_161]
> at
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1385)
> ~[?:1.8.0_161]
> at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:757)
> ~[?:1.8.0_161]
> at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123)
> ~[?:1.8.0_161]
> at
> java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
> ~[?:1.8.0_161]
> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
> ~[?:1.8.0_161]
> at java.io.DataOutputStream.flush(DataOutputStream.java:123)
> ~[?:1.8.0_161]
> at
> sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:229)
> ~[?:1.8.0_161]
> at
> sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:202)
> ~[?:1.8.0_161]
> at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:338)
> ~[?:1.8.0_161]
> at
> sun.rmi.registry.RegistryImpl_Stub.lookup(RegistryImpl_Stub.java:112)
> ~[?:1.8.0_161]
> at
> com.sun.jndi.rmi.registry.RegistryContext.lookup(RegistryContext.java:132)
> ~[?:1.8.0_161]
> at
> com.sun.jndi.toolkit.url.GenericURLContext.lookup(GenericURLContext.java:205)
> ~[?:1.8.0_161]
> at javax.naming.InitialContext.lookup(InitialContext.java:417)
> ~[?:1.8.0_161]
> at
> javax.management.remote.rmi.RMIConnector.findRMIServerJNDI(RMIConnector.java:1955)
> ~[?:1.8.0_161]
> at
> javax.management.remote.rmi.RMIConnector.findRMIServer(RMIConnector.java:1922)
> ~[?:1.8.0_161]
> at
> javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:287)
> ~[?:1.8.0_161]
> ... 92 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5230) Pulse does not work when SSL is enabled for JMX
[
https://issues.apache.org/jira/browse/GEODE-5230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn updated GEODE-5230:
--
Fix Version/s: 1.7.0
> Pulse does not work when SSL is enabled for JMX
> ---
>
> Key: GEODE-5230
> URL: https://issues.apache.org/jira/browse/GEODE-5230
> Project: Geode
> Issue Type: Bug
> Components: pulse
>Reporter: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> If I start a locator with SSL enabled {{ssl-components=ALL}} then Pulse does
> not work. When logging in I see an error message like:
> {noformat}
> Connecting ...
> Failed to retrieve RMIServer stub: javax.naming.CommunicationException [Root
> exception is java.rmi.ConnectIOException: error during JRMP connection
> establishment; nested exception is: javax.net.ssl.SSLHandshakeException:
> sun.security.validator.ValidatorException: PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target]
> {noformat}
> pulse.log shows the same:
> {noformat}
> Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable
> to find valid certification path to requested target
> at
> sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
> ~[?:1.8.0_161]
> at
> sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
> ~[?:1.8.0_161]
> at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280)
> ~[?:1.8.0_161]
> at
> sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:392)
> ~[?:1.8.0_161]
> at
> sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:302)
> ~[?:1.8.0_161]
> at sun.security.validator.Validator.validate(Validator.java:260)
> ~[?:1.8.0_161]
> at
> sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324)
> ~[?:1.8.0_161]
> at
> sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:229)
> ~[?:1.8.0_161]
> at
> sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:124)
> ~[?:1.8.0_161]
> at
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1596)
> ~[?:1.8.0_161]
> at
> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
> ~[?:1.8.0_161]
> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1052)
> ~[?:1.8.0_161]
> at sun.security.ssl.Handshaker.process_record(Handshaker.java:987)
> ~[?:1.8.0_161]
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1072)
> ~[?:1.8.0_161]
> at
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1385)
> ~[?:1.8.0_161]
> at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:757)
> ~[?:1.8.0_161]
> at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123)
> ~[?:1.8.0_161]
> at
> java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
> ~[?:1.8.0_161]
> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
> ~[?:1.8.0_161]
> at java.io.DataOutputStream.flush(DataOutputStream.java:123)
> ~[?:1.8.0_161]
> at
> sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:229)
> ~[?:1.8.0_161]
> at
> sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:202)
> ~[?:1.8.0_161]
> at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:338)
> ~[?:1.8.0_161]
> at
> sun.rmi.registry.RegistryImpl_Stub.lookup(RegistryImpl_Stub.java:112)
> ~[?:1.8.0_161]
> at
> com.sun.jndi.rmi.registry.RegistryContext.lookup(RegistryContext.java:132)
> ~[?:1.8.0_161]
> at
> com.sun.jndi.toolkit.url.GenericURLContext.lookup(GenericURLContext.java:205)
> ~[?:1.8.0_161]
> at javax.naming.InitialContext.lookup(InitialContext.java:417)
> ~[?:1.8.0_161]
> at
> javax.management.remote.rmi.RMIConnector.findRMIServerJNDI(RMIConnector.java:1955)
> ~[?:1.8.0_161]
> at
> javax.management.remote.rmi.RMIConnector.findRMIServer(RMIConnector.java:1922)
> ~[?:1.8.0_161]
> at
> javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:287)
> ~[?:1.8.0_161]
> ... 92 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5194) Relax Gfsh version checking on connect, allow connecting to different patch versions
[
https://issues.apache.org/jira/browse/GEODE-5194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn resolved GEODE-5194.
---
Resolution: Fixed
> Relax Gfsh version checking on connect, allow connecting to different patch
> versions
>
>
> Key: GEODE-5194
> URL: https://issues.apache.org/jira/browse/GEODE-5194
> Project: Geode
> Issue Type: Improvement
> Components: gfsh
>Reporter: Kenneth Howe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently Gfsh, {{connect}} command will only connect to locator with the
> same exact version. Patch versions should not add or change functionality of
> commands, so for Gfsh version {{x.y.z}} connection to locator with same major
> and minor, {{x.y}}, version with a different patch, {{.z}}, should be allowed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5001) Update logj4 dependency to better integrate with Spring
[
https://issues.apache.org/jira/browse/GEODE-5001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn resolved GEODE-5001.
---
Resolution: Fixed
> Update logj4 dependency to better integrate with Spring
> ---
>
> Key: GEODE-5001
> URL: https://issues.apache.org/jira/browse/GEODE-5001
> Project: Geode
> Issue Type: Improvement
> Components: build, logging
>Reporter: Anthony Baker
>Assignee: Barbara Pruijn
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> The current geode log4j dependency is v2.8.2. Spring (Boot, Data, etc) use
> log4j v2.11.0. This make integration challenging. We should upgrade our
> dependency to match Spring. This will make it easier for our users to write
> geode applications.
> Checking for other updates using
> {noformat}
> gradle dependencyUpdates
> find . -name report.txt | xargs grep -e "\]$" | grep -v "org.apache.geode" |
> tr -s " " | cut -d' ' -f3- | sort | uniq | less
> {noformat}
> show that we have some other libraries that can be updated as well:
> {noformat}
> com.fasterxml.jackson.core:jackson-annotations [2.9.4 -> 2.9.5]
> com.fasterxml.jackson.core:jackson-core [2.9.4 -> 2.9.5]
> com.fasterxml.jackson.core:jackson-databind [2.9.4 -> 2.9.5]
> com.fasterxml.jackson.module:jackson-module-scala_2.10 [2.9.4 -> 2.9.5]
> com.google.guava:guava [24.0-jre -> 24.1-jre]
> com.google.protobuf:protoc [3.5.1 -> 3.5.1-1]
> com.zaxxer:HikariCP [2.7.6 -> 3.0.0]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-4959) Attempt to create multiple gw receivers results an error on gfsh console.
[
https://issues.apache.org/jira/browse/GEODE-4959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn resolved GEODE-4959.
---
Resolution: Fixed
> Attempt to create multiple gw receivers results an error on gfsh console.
> -
>
> Key: GEODE-4959
> URL: https://issues.apache.org/jira/browse/GEODE-4959
> Project: Geode
> Issue Type: Bug
> Components: docs, gfsh
>Reporter: Sai Boorlagadda
>Assignee: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> {{There are several issues with create gateway-receiver command.}}
> 1) Starting 1.4.0, with GEODE-3987 there is an enforcement of one gwr per
> node in the xsd. So when user attempts to create multiple gwr show a better
> error message then showing "*ERROR: java.lang.IllegalStateException*".
> {noformat}
> gfsh>start server --locators=localhost[10334]
> Starting a Geode Server in
> /Users/sboorlagadda/workspace/debug/geode/apache-geode-1.4.0/bin/walk-proud-feet...
> ...
> Server in
> /Users/sboorlagadda/workspace/debug/geode/apache-geode-1.4.0/bin/walk-proud-feet
> on sais-mbp-2.netgear.com[40404] as walk-proud-feet is currently online.
> Process ID: 35197
> Uptime: 4 seconds
> Geode Version: 1.4.0
> Java Version: 1.8.0_151
> Log File:
> /Users/sboorlagadda/workspace/debug/geode/apache-geode-1.4.0/bin/walk-proud-feet/walk-proud-feet.log
> JVM Arguments: -Dgemfire.locators=localhost[10334]
> -Dgemfire.start-dev-rest-api=false -Dgemfire.use-cluster-configuration=true
> -XX:OnOutOfMemoryError=kill -KILL %p
> -Dgemfire.launcher.registerSignalHandlers=true -Djava.awt.headless=true
> -Dsun.rmi.dgc.server.gcInterval=9223372036854775806
> Class-Path:
> /Users/sboorlagadda/workspace/debug/geode/apache-geode-1.4.0/lib/geode-core-1.4.0.jar:/Users/sboorlagadda/workspace/debug/geode/apache-geode-1.4.0/lib/geode-dependencies.jar
> gfsh>create gateway-receiver
> Member | Status
> --- |
> ---
> walk-proud-feet | GatewayReceiver created on member "walk-proud-feet" and
> will listen on the port "5,221"
> gfsh>create gateway-receiver
> Member | Status
> --- |
> -
> walk-proud-feet | ERROR: java.lang.IllegalStateException: A Gateway Receiver
> already exists on this member.{noformat}
> 2) create gwr command should enforce only one gwr can be created as with
> GEODE-3987, xsd supports only one.
> 3) create gwr command is storing the gwr in cluster config when created with
> --member option.
> As there is no enforcement until 1.3 and with above stated issues with gfsh,
> it could happen that some one could end up a cluster with multiple gwr
> created in cluster configuration and could prevent them to upgrade to 1.4.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5001) Update logj4 dependency to better integrate with Spring
[
https://issues.apache.org/jira/browse/GEODE-5001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn updated GEODE-5001:
--
Fix Version/s: 1.7.0
> Update logj4 dependency to better integrate with Spring
> ---
>
> Key: GEODE-5001
> URL: https://issues.apache.org/jira/browse/GEODE-5001
> Project: Geode
> Issue Type: Improvement
> Components: build, logging
>Reporter: Anthony Baker
>Assignee: Barbara Pruijn
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> The current geode log4j dependency is v2.8.2. Spring (Boot, Data, etc) use
> log4j v2.11.0. This make integration challenging. We should upgrade our
> dependency to match Spring. This will make it easier for our users to write
> geode applications.
> Checking for other updates using
> {noformat}
> gradle dependencyUpdates
> find . -name report.txt | xargs grep -e "\]$" | grep -v "org.apache.geode" |
> tr -s " " | cut -d' ' -f3- | sort | uniq | less
> {noformat}
> show that we have some other libraries that can be updated as well:
> {noformat}
> com.fasterxml.jackson.core:jackson-annotations [2.9.4 -> 2.9.5]
> com.fasterxml.jackson.core:jackson-core [2.9.4 -> 2.9.5]
> com.fasterxml.jackson.core:jackson-databind [2.9.4 -> 2.9.5]
> com.fasterxml.jackson.module:jackson-module-scala_2.10 [2.9.4 -> 2.9.5]
> com.google.guava:guava [24.0-jre -> 24.1-jre]
> com.google.protobuf:protoc [3.5.1 -> 3.5.1-1]
> com.zaxxer:HikariCP [2.7.6 -> 3.0.0]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5185) Correct recent backward-compatibility violation in 'create gateway-receiver' command.
[
https://issues.apache.org/jira/browse/GEODE-5185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn resolved GEODE-5185.
---
Resolution: Fixed
> Correct recent backward-compatibility violation in 'create gateway-receiver'
> command.
> -
>
> Key: GEODE-5185
> URL: https://issues.apache.org/jira/browse/GEODE-5185
> Project: Geode
> Issue Type: Bug
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Commit {{4dff0cde9c3abca2dad03897c055e9c443a81b60}} changed {{create
> gateway-receiver}} to fail if any server fails to create the gateway receiver
> when the {{if-not-exists}} command is not given. This is inconsistent with
> the expected behavior of previous minor releases.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5185) Correct recent backward-compatibility violation in 'create gateway-receiver' command.
[
https://issues.apache.org/jira/browse/GEODE-5185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn updated GEODE-5185:
--
Fix Version/s: 1.7.0
> Correct recent backward-compatibility violation in 'create gateway-receiver'
> command.
> -
>
> Key: GEODE-5185
> URL: https://issues.apache.org/jira/browse/GEODE-5185
> Project: Geode
> Issue Type: Bug
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Commit {{4dff0cde9c3abca2dad03897c055e9c443a81b60}} changed {{create
> gateway-receiver}} to fail if any server fails to create the gateway receiver
> when the {{if-not-exists}} command is not given. This is inconsistent with
> the expected behavior of previous minor releases.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-4959) Attempt to create multiple gw receivers results an error on gfsh console.
[
https://issues.apache.org/jira/browse/GEODE-4959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn updated GEODE-4959:
--
Fix Version/s: 1.7.0
> Attempt to create multiple gw receivers results an error on gfsh console.
> -
>
> Key: GEODE-4959
> URL: https://issues.apache.org/jira/browse/GEODE-4959
> Project: Geode
> Issue Type: Bug
> Components: docs, gfsh
>Reporter: Sai Boorlagadda
>Assignee: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> {{There are several issues with create gateway-receiver command.}}
> 1) Starting 1.4.0, with GEODE-3987 there is an enforcement of one gwr per
> node in the xsd. So when user attempts to create multiple gwr show a better
> error message then showing "*ERROR: java.lang.IllegalStateException*".
> {noformat}
> gfsh>start server --locators=localhost[10334]
> Starting a Geode Server in
> /Users/sboorlagadda/workspace/debug/geode/apache-geode-1.4.0/bin/walk-proud-feet...
> ...
> Server in
> /Users/sboorlagadda/workspace/debug/geode/apache-geode-1.4.0/bin/walk-proud-feet
> on sais-mbp-2.netgear.com[40404] as walk-proud-feet is currently online.
> Process ID: 35197
> Uptime: 4 seconds
> Geode Version: 1.4.0
> Java Version: 1.8.0_151
> Log File:
> /Users/sboorlagadda/workspace/debug/geode/apache-geode-1.4.0/bin/walk-proud-feet/walk-proud-feet.log
> JVM Arguments: -Dgemfire.locators=localhost[10334]
> -Dgemfire.start-dev-rest-api=false -Dgemfire.use-cluster-configuration=true
> -XX:OnOutOfMemoryError=kill -KILL %p
> -Dgemfire.launcher.registerSignalHandlers=true -Djava.awt.headless=true
> -Dsun.rmi.dgc.server.gcInterval=9223372036854775806
> Class-Path:
> /Users/sboorlagadda/workspace/debug/geode/apache-geode-1.4.0/lib/geode-core-1.4.0.jar:/Users/sboorlagadda/workspace/debug/geode/apache-geode-1.4.0/lib/geode-dependencies.jar
> gfsh>create gateway-receiver
> Member | Status
> --- |
> ---
> walk-proud-feet | GatewayReceiver created on member "walk-proud-feet" and
> will listen on the port "5,221"
> gfsh>create gateway-receiver
> Member | Status
> --- |
> -
> walk-proud-feet | ERROR: java.lang.IllegalStateException: A Gateway Receiver
> already exists on this member.{noformat}
> 2) create gwr command should enforce only one gwr can be created as with
> GEODE-3987, xsd supports only one.
> 3) create gwr command is storing the gwr in cluster config when created with
> --member option.
> As there is no enforcement until 1.3 and with above stated issues with gfsh,
> it could happen that some one could end up a cluster with multiple gwr
> created in cluster configuration and could prevent them to upgrade to 1.4.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5194) Relax Gfsh version checking on connect, allow connecting to different patch versions
[
https://issues.apache.org/jira/browse/GEODE-5194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn updated GEODE-5194:
--
Fix Version/s: 1.7.0
> Relax Gfsh version checking on connect, allow connecting to different patch
> versions
>
>
> Key: GEODE-5194
> URL: https://issues.apache.org/jira/browse/GEODE-5194
> Project: Geode
> Issue Type: Improvement
> Components: gfsh
>Reporter: Kenneth Howe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently Gfsh, {{connect}} command will only connect to locator with the
> same exact version. Patch versions should not add or change functionality of
> commands, so for Gfsh version {{x.y.z}} connection to locator with same major
> and minor, {{x.y}}, version with a different patch, {{.z}}, should be allowed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5204) Add 'get/set cluster-config' gfsh command
[
https://issues.apache.org/jira/browse/GEODE-5204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16474763#comment-16474763
]
Barbara Pruijn commented on GEODE-5204:
---
As part of the set cluster-config command, we need to verify that the XSD
syntax is valid. If not valid, return an error.
> Add 'get/set cluster-config' gfsh command
> -
>
> Key: GEODE-5204
> URL: https://issues.apache.org/jira/browse/GEODE-5204
> Project: Geode
> Issue Type: Improvement
> Components: gfsh
>Reporter: Jens Deppe
>Priority: Major
>
> Add a new gfsh command to update an existing cluster config xml.
> The command should only update the cluster configuration and not affect the
> config of running servers (this will be added later).
> The set command should take options {{\-\-group}}, {{\-\-xml}} and
> {{\-\-properties}}. The default group should be {{"cluster"}}.
> The command should only need to be run on a single locator and have changes
> propagated to all other locators.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-2668) Add gfsh command to destroy gateway receiver
[
https://issues.apache.org/jira/browse/GEODE-2668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn resolved GEODE-2668.
---
Resolution: Fixed
> Add gfsh command to destroy gateway receiver
>
>
> Key: GEODE-2668
> URL: https://issues.apache.org/jira/browse/GEODE-2668
> Project: Geode
> Issue Type: Sub-task
> Components: docs, gfsh
>Reporter: Swapnil Bawaskar
>Assignee: Kenneth Howe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> Currently, there is a {{create gateway-receiver}} command, but no
> corresponding destroy command.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-2668) Add gfsh command to destroy gateway receiver
[
https://issues.apache.org/jira/browse/GEODE-2668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn updated GEODE-2668:
--
Fix Version/s: 1.7.0
> Add gfsh command to destroy gateway receiver
>
>
> Key: GEODE-2668
> URL: https://issues.apache.org/jira/browse/GEODE-2668
> Project: Geode
> Issue Type: Sub-task
> Components: docs, gfsh
>Reporter: Swapnil Bawaskar
>Assignee: Kenneth Howe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> Currently, there is a {{create gateway-receiver}} command, but no
> corresponding destroy command.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5146) WAN Information view in Pulse shows wrong status for remote clusters
[ https://issues.apache.org/jira/browse/GEODE-5146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barbara Pruijn resolved GEODE-5146. --- Resolution: Fixed > WAN Information view in Pulse shows wrong status for remote clusters > > > Key: GEODE-5146 > URL: https://issues.apache.org/jira/browse/GEODE-5146 > Project: Geode > Issue Type: Bug > Components: pulse >Reporter: Sai Boorlagadda >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > GEODE-2186 fixed to address that the status should be cumulative and not just > the last sender's status, but introduced *connection status* of remote > cluster based on gateway sender being running rather than being connected. > This ticket is to fix the connection status to infer from > GatewaySenderMXBean.isConnected while considering whether sender is a serial > or parallel. > * serial - primary connected -> true > * serial - primary not connected -> false > * parallel - all members connected -> true > * parallel - not all members connected -> false -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5146) WAN Information view in Pulse shows wrong status for remote clusters
[ https://issues.apache.org/jira/browse/GEODE-5146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barbara Pruijn updated GEODE-5146: -- Fix Version/s: 1.7.0 > WAN Information view in Pulse shows wrong status for remote clusters > > > Key: GEODE-5146 > URL: https://issues.apache.org/jira/browse/GEODE-5146 > Project: Geode > Issue Type: Bug > Components: pulse >Reporter: Sai Boorlagadda >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > GEODE-2186 fixed to address that the status should be cumulative and not just > the last sender's status, but introduced *connection status* of remote > cluster based on gateway sender being running rather than being connected. > This ticket is to fix the connection status to infer from > GatewaySenderMXBean.isConnected while considering whether sender is a serial > or parallel. > * serial - primary connected -> true > * serial - primary not connected -> false > * parallel - all members connected -> true > * parallel - not all members connected -> false -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-5143) rename ClusterConfigurationService
[ https://issues.apache.org/jira/browse/GEODE-5143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barbara Pruijn resolved GEODE-5143. --- Resolution: Fixed > rename ClusterConfigurationService > -- > > Key: GEODE-5143 > URL: https://issues.apache.org/jira/browse/GEODE-5143 > Project: Geode > Issue Type: Sub-task > Components: configuration, docs >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > The term ClusterConfigurationService is ambiguous. People have grand ideas > about what it should do which is way outside of the current scope of making a > public API for retrieving and persisting cluster configuration. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5143) rename ClusterConfigurationService
[ https://issues.apache.org/jira/browse/GEODE-5143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barbara Pruijn updated GEODE-5143: -- Fix Version/s: 1.7.0 > rename ClusterConfigurationService > -- > > Key: GEODE-5143 > URL: https://issues.apache.org/jira/browse/GEODE-5143 > Project: Geode > Issue Type: Sub-task > Components: configuration, docs >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > The term ClusterConfigurationService is ambiguous. People have grand ideas > about what it should do which is way outside of the current scope of making a > public API for retrieving and persisting cluster configuration. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-5165) Avoid OOME when scanning for annotated classes
[ https://issues.apache.org/jira/browse/GEODE-5165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barbara Pruijn resolved GEODE-5165. --- Resolution: Fixed > Avoid OOME when scanning for annotated classes > -- > > Key: GEODE-5165 > URL: https://issues.apache.org/jira/browse/GEODE-5165 > Project: Geode > Issue Type: Bug > Components: configuration, docs >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > when we scan the entire classpath for a certain annotated class, we ran into > OOME in our test environment. Need to add a capability to limit the packages > to scan if geode.packagesToScan system property is set. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5165) Avoid OOME when scanning for annotated classes
[ https://issues.apache.org/jira/browse/GEODE-5165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barbara Pruijn updated GEODE-5165: -- Fix Version/s: 1.7.0 > Avoid OOME when scanning for annotated classes > -- > > Key: GEODE-5165 > URL: https://issues.apache.org/jira/browse/GEODE-5165 > Project: Geode > Issue Type: Bug > Components: configuration, docs >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > when we scan the entire classpath for a certain annotated class, we ran into > OOME in our test environment. Need to add a capability to limit the packages > to scan if geode.packagesToScan system property is set. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-5010) Introduce *ResultModel objects to replace *ResultData
[ https://issues.apache.org/jira/browse/GEODE-5010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barbara Pruijn resolved GEODE-5010. --- Resolution: Fixed > Introduce *ResultModel objects to replace *ResultData > - > > Key: GEODE-5010 > URL: https://issues.apache.org/jira/browse/GEODE-5010 > Project: Geode > Issue Type: Sub-task > Components: docs, gfsh >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 3h 40m > Remaining Estimate: 0h > > Introduce POJOs to be used as replacements for CompositeResultData, > TabularResultData, InfoResultData and ErrorResultData. > These POJOs will be json serializable using Jackson > Provide ability to use both legacy and these new POJOs until all commands > have been migrated. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5010) Introduce *ResultModel objects to replace *ResultData
[ https://issues.apache.org/jira/browse/GEODE-5010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barbara Pruijn updated GEODE-5010: -- Fix Version/s: 1.7.0 > Introduce *ResultModel objects to replace *ResultData > - > > Key: GEODE-5010 > URL: https://issues.apache.org/jira/browse/GEODE-5010 > Project: Geode > Issue Type: Sub-task > Components: docs, gfsh >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 3h 40m > Remaining Estimate: 0h > > Introduce POJOs to be used as replacements for CompositeResultData, > TabularResultData, InfoResultData and ErrorResultData. > These POJOs will be json serializable using Jackson > Provide ability to use both legacy and these new POJOs until all commands > have been migrated. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4860) make sure the extensions xsd is upgradable
[ https://issues.apache.org/jira/browse/GEODE-4860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barbara Pruijn updated GEODE-4860: -- Fix Version/s: 1.7.0 > make sure the extensions xsd is upgradable > -- > > Key: GEODE-4860 > URL: https://issues.apache.org/jira/browse/GEODE-4860 > Project: Geode > Issue Type: Sub-task > Components: configuration >Reporter: Jinmei Liao >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 20m > Remaining Estimate: 0h > > when other module uses a different version of their own xsd (jdbc-2.0.xsd). > We should have a strategy to make sure rolling upgrade still work. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-4860) make sure the extensions xsd is upgradable
[ https://issues.apache.org/jira/browse/GEODE-4860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barbara Pruijn resolved GEODE-4860. --- Resolution: Fixed > make sure the extensions xsd is upgradable > -- > > Key: GEODE-4860 > URL: https://issues.apache.org/jira/browse/GEODE-4860 > Project: Geode > Issue Type: Sub-task > Components: configuration >Reporter: Jinmei Liao >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 20m > Remaining Estimate: 0h > > when other module uses a different version of their own xsd (jdbc-2.0.xsd). > We should have a strategy to make sure rolling upgrade still work. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5083) Alter region --name option no longer auto completes
[ https://issues.apache.org/jira/browse/GEODE-5083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barbara Pruijn updated GEODE-5083: -- Fix Version/s: 1.7.0 > Alter region --name option no longer auto completes > --- > > Key: GEODE-5083 > URL: https://issues.apache.org/jira/browse/GEODE-5083 > Project: Geode > Issue Type: Bug > Components: gfsh >Reporter: Jinmei Liao >Priority: Major > Labels: pull-request-available, quick_to_fix > Fix For: 1.7.0 > > Time Spent: 40m > Remaining Estimate: 0h > > when "alter region --name=" is typed, tabbing should show a list of available > regions -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-5083) Alter region --name option no longer auto completes
[ https://issues.apache.org/jira/browse/GEODE-5083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barbara Pruijn resolved GEODE-5083. --- Resolution: Fixed > Alter region --name option no longer auto completes > --- > > Key: GEODE-5083 > URL: https://issues.apache.org/jira/browse/GEODE-5083 > Project: Geode > Issue Type: Bug > Components: gfsh >Reporter: Jinmei Liao >Priority: Major > Labels: pull-request-available, quick_to_fix > Fix For: 1.7.0 > > Time Spent: 40m > Remaining Estimate: 0h > > when "alter region --name=" is typed, tabbing should show a list of available > regions -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-2668) Add gfsh command to destroy gateway receiver
[
https://issues.apache.org/jira/browse/GEODE-2668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16459110#comment-16459110
]
Barbara Pruijn commented on GEODE-2668:
---
If the gateway receiver does not exist and we run the destroy gateway receiver
command, we should get an error that the gateway receiver doesn't exist.
We should *not* state:
{code:java}
gfsh>destroy gateway-receiver
This change is not persisted in the cluster configuration, either because the
cluster configuration service is not running or the command is operating on
targeted members.
Member | Status
-- | --
s1 | ERROR: Gateway receiver not found.{code}
We should state:
{{Gateway receiver not found.}}
> Add gfsh command to destroy gateway receiver
>
>
> Key: GEODE-2668
> URL: https://issues.apache.org/jira/browse/GEODE-2668
> Project: Geode
> Issue Type: Sub-task
> Components: docs, gfsh
>Reporter: Swapnil Bawaskar
>Priority: Major
> Labels: pull-request-available
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> Currently, there is a {{create gateway-receiver}} command, but no
> corresponding destroy command.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-4794) ConfigurePDXCommand Fails When Using Defaults
[
https://issues.apache.org/jira/browse/GEODE-4794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16456859#comment-16456859
]
Barbara Pruijn commented on GEODE-4794:
---
{code:java}
gfsh> configure pdx{code}
needs to be run before members are running. If this command is run and cluster
config has been disabled, the command will return the following error:
{code:java}
gfsh>configure pdx
Configure pdx failed because cluster configuration is disabled.
{code}
Also updated help text to display default values on default parameters.
> ConfigurePDXCommand Fails When Using Defaults
> -
>
> Key: GEODE-4794
> URL: https://issues.apache.org/jira/browse/GEODE-4794
> Project: Geode
> Issue Type: Bug
> Components: docs, gfsh
>Reporter: Juan José Ramos Cassella
>Assignee: Joey McAllister
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> While working on a fix for GEODE-4771 I've came across another bug: the
> {{configure pdx}} command fails when no parameters are specified, even when
> we state in the [User
> Guide|http://geode.apache.org/docs/guide/14/tools_modules/gfsh/command-pages/configure.html]
> that no parameters are mandatory.
> The source code doesn't generate a valid XML fragment when none of the
> parameters are set and, as such, the resulting {{XmlEntity}} ends up being
> empty, so a {{NullPointerException}} is thrown when the command tries to
> persist the changes to the cluster configuration service:
> {code:java}
> [error 2018/03/07 11:07:48.242 GMT locator1
> tid=0x55] error updating cluster configuration for group cluster
> java.lang.NullPointerException
> at java.io.StringReader.(StringReader.java:50)
> at
> org.apache.geode.management.internal.configuration.utils.XmlUtils.createNode(XmlUtils.java:242)
> at
> org.apache.geode.management.internal.configuration.utils.XmlUtils.addNewNode(XmlUtils.java:133)
> at
> org.apache.geode.distributed.internal.ClusterConfigurationService.addXmlEntity(ClusterConfigurationService.java:204)
> at
> org.apache.geode.management.internal.cli.commands.ConfigurePDXCommand.lambda$configurePDX$0(ConfigurePDXCommand.java:131)
> at
> org.apache.geode.management.internal.cli.commands.GfshCommand.persistClusterConfiguration(GfshCommand.java:72)
> at
> org.apache.geode.management.internal.cli.commands.ConfigurePDXCommand.configurePDX(ConfigurePDXCommand.java:130)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.springframework.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:216)
> at
> org.apache.geode.management.internal.cli.remote.CommandExecutor.invokeCommand(CommandExecutor.java:97)
> at
> org.apache.geode.management.internal.cli.remote.CommandExecutor.execute(CommandExecutor.java:45)
> at
> org.apache.geode.management.internal.cli.remote.CommandExecutor.execute(CommandExecutor.java:39)
> at
> org.apache.geode.management.internal.cli.remote.OnlineCommandProcessor.executeCommand(OnlineCommandProcessor.java:133)
> at
> org.apache.geode.management.internal.beans.MemberMBeanBridge.processCommand(MemberMBeanBridge.java:1579)
> at
> org.apache.geode.management.internal.beans.MemberMBean.processCommand(MemberMBean.java:412)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
> at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
> at
> com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:193)
> at
> com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:175)
> at
> com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:117)
> at
> com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:54)
> at
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
>
[jira] [Updated] (GEODE-4794) ConfigurePDXCommand Fails When Using Defaults
[
https://issues.apache.org/jira/browse/GEODE-4794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn updated GEODE-4794:
--
Fix Version/s: 1.7.0
> ConfigurePDXCommand Fails When Using Defaults
> -
>
> Key: GEODE-4794
> URL: https://issues.apache.org/jira/browse/GEODE-4794
> Project: Geode
> Issue Type: Bug
> Components: docs, gfsh
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> While working on a fix for GEODE-4771 I've came across another bug: the
> {{configure pdx}} command fails when no parameters are specified, even when
> we state in the [User
> Guide|http://geode.apache.org/docs/guide/14/tools_modules/gfsh/command-pages/configure.html]
> that no parameters are mandatory.
> The source code doesn't generate a valid XML fragment when none of the
> parameters are set and, as such, the resulting {{XmlEntity}} ends up being
> empty, so a {{NullPointerException}} is thrown when the command tries to
> persist the changes to the cluster configuration service:
> {code:java}
> [error 2018/03/07 11:07:48.242 GMT locator1
> tid=0x55] error updating cluster configuration for group cluster
> java.lang.NullPointerException
> at java.io.StringReader.(StringReader.java:50)
> at
> org.apache.geode.management.internal.configuration.utils.XmlUtils.createNode(XmlUtils.java:242)
> at
> org.apache.geode.management.internal.configuration.utils.XmlUtils.addNewNode(XmlUtils.java:133)
> at
> org.apache.geode.distributed.internal.ClusterConfigurationService.addXmlEntity(ClusterConfigurationService.java:204)
> at
> org.apache.geode.management.internal.cli.commands.ConfigurePDXCommand.lambda$configurePDX$0(ConfigurePDXCommand.java:131)
> at
> org.apache.geode.management.internal.cli.commands.GfshCommand.persistClusterConfiguration(GfshCommand.java:72)
> at
> org.apache.geode.management.internal.cli.commands.ConfigurePDXCommand.configurePDX(ConfigurePDXCommand.java:130)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.springframework.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:216)
> at
> org.apache.geode.management.internal.cli.remote.CommandExecutor.invokeCommand(CommandExecutor.java:97)
> at
> org.apache.geode.management.internal.cli.remote.CommandExecutor.execute(CommandExecutor.java:45)
> at
> org.apache.geode.management.internal.cli.remote.CommandExecutor.execute(CommandExecutor.java:39)
> at
> org.apache.geode.management.internal.cli.remote.OnlineCommandProcessor.executeCommand(OnlineCommandProcessor.java:133)
> at
> org.apache.geode.management.internal.beans.MemberMBeanBridge.processCommand(MemberMBeanBridge.java:1579)
> at
> org.apache.geode.management.internal.beans.MemberMBean.processCommand(MemberMBean.java:412)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
> at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
> at
> com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:193)
> at
> com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:175)
> at
> com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:117)
> at
> com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:54)
> at
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at
> com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> at
>
[jira] [Assigned] (GEODE-4794) ConfigurePDXCommand Fails When Using Defaults
[
https://issues.apache.org/jira/browse/GEODE-4794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn reassigned GEODE-4794:
-
Assignee: Joey McAllister (was: Juan José Ramos Cassella)
> ConfigurePDXCommand Fails When Using Defaults
> -
>
> Key: GEODE-4794
> URL: https://issues.apache.org/jira/browse/GEODE-4794
> Project: Geode
> Issue Type: Bug
> Components: docs, gfsh
>Reporter: Juan José Ramos Cassella
>Assignee: Joey McAllister
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> While working on a fix for GEODE-4771 I've came across another bug: the
> {{configure pdx}} command fails when no parameters are specified, even when
> we state in the [User
> Guide|http://geode.apache.org/docs/guide/14/tools_modules/gfsh/command-pages/configure.html]
> that no parameters are mandatory.
> The source code doesn't generate a valid XML fragment when none of the
> parameters are set and, as such, the resulting {{XmlEntity}} ends up being
> empty, so a {{NullPointerException}} is thrown when the command tries to
> persist the changes to the cluster configuration service:
> {code:java}
> [error 2018/03/07 11:07:48.242 GMT locator1
> tid=0x55] error updating cluster configuration for group cluster
> java.lang.NullPointerException
> at java.io.StringReader.(StringReader.java:50)
> at
> org.apache.geode.management.internal.configuration.utils.XmlUtils.createNode(XmlUtils.java:242)
> at
> org.apache.geode.management.internal.configuration.utils.XmlUtils.addNewNode(XmlUtils.java:133)
> at
> org.apache.geode.distributed.internal.ClusterConfigurationService.addXmlEntity(ClusterConfigurationService.java:204)
> at
> org.apache.geode.management.internal.cli.commands.ConfigurePDXCommand.lambda$configurePDX$0(ConfigurePDXCommand.java:131)
> at
> org.apache.geode.management.internal.cli.commands.GfshCommand.persistClusterConfiguration(GfshCommand.java:72)
> at
> org.apache.geode.management.internal.cli.commands.ConfigurePDXCommand.configurePDX(ConfigurePDXCommand.java:130)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.springframework.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:216)
> at
> org.apache.geode.management.internal.cli.remote.CommandExecutor.invokeCommand(CommandExecutor.java:97)
> at
> org.apache.geode.management.internal.cli.remote.CommandExecutor.execute(CommandExecutor.java:45)
> at
> org.apache.geode.management.internal.cli.remote.CommandExecutor.execute(CommandExecutor.java:39)
> at
> org.apache.geode.management.internal.cli.remote.OnlineCommandProcessor.executeCommand(OnlineCommandProcessor.java:133)
> at
> org.apache.geode.management.internal.beans.MemberMBeanBridge.processCommand(MemberMBeanBridge.java:1579)
> at
> org.apache.geode.management.internal.beans.MemberMBean.processCommand(MemberMBean.java:412)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
> at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
> at
> com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:193)
> at
> com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:175)
> at
> com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:117)
> at
> com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:54)
> at
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at
>
[jira] [Resolved] (GEODE-4963) ConnectCommandDUnitTest is broken since GfshCommand was made 'public'
[
https://issues.apache.org/jira/browse/GEODE-4963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn resolved GEODE-4963.
---
Resolution: Fixed
> ConnectCommandDUnitTest is broken since GfshCommand was made 'public'
> -
>
> Key: GEODE-4963
> URL: https://issues.apache.org/jira/browse/GEODE-4963
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Jens Deppe
>Priority: Major
> Labels: ci, pull-request-available
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The failure looks like this:
> {noformat}
> org.apache.geode.management.internal.cli.commands.ConnectCommandDUnitTest >
> useCurrentGfshToConnectToOlderLocator FAILED
> java.lang.AssertionError:
> Expecting:
> <"_ __
>/ _/ __/ __/ // /
> / / __/ /___ /_ / _ /
> / /__/ / / _/ / // /
> /__/_/ /__/_//_/1.6.0-SNAPSHOT
>
> Monitor and Manage Apache Geode
> Connecting to Manager at [host=localhost, port=28823] ..
> Could not connect to : [host=localhost, port=28823]. Failed to retrieve
> RMIServer stub: javax.naming.ServiceUnavailableException [Root exception is
> java.rmi.ConnectException: Connection refused to host: localhost; nested
> exception is:
> java.net.ConnectException: Connection refused (Connection refused)]
> ">
> to contain:
> <"Cannot use a">
> at
> org.apache.geode.test.junit.assertions.CommandResultAssert.containsOutput(CommandResultAssert.java:79)
> at
> org.apache.geode.management.internal.cli.commands.ConnectCommandDUnitTest.useCurrentGfshToConnectToOlderLocator(ConnectCommandDUnitTest.java:46)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5070) Support --member option for describe & list jdbc connector commands
[ https://issues.apache.org/jira/browse/GEODE-5070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barbara Pruijn updated GEODE-5070: -- Fix Version/s: 1.7.0 > Support --member option for describe & list jdbc connector commands > --- > > Key: GEODE-5070 > URL: https://issues.apache.org/jira/browse/GEODE-5070 > Project: Geode > Issue Type: New Feature > Components: docs, gfsh >Reporter: Sai Boorlagadda >Assignee: Sai Boorlagadda >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 40m > Remaining Estimate: 0h > > When cluster configuration service is disabled user have to provide --member > option in-order to describe and list connections and mappings. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-5001) Update logj4 dependency to better integrate with Spring
[
https://issues.apache.org/jira/browse/GEODE-5001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn reassigned GEODE-5001:
-
Assignee: Barbara Pruijn
> Update logj4 dependency to better integrate with Spring
> ---
>
> Key: GEODE-5001
> URL: https://issues.apache.org/jira/browse/GEODE-5001
> Project: Geode
> Issue Type: Improvement
> Components: build, logging
>Reporter: Anthony Baker
>Assignee: Barbara Pruijn
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The current geode log4j dependency is v2.8.2. Spring (Boot, Data, etc) use
> log4j v2.11.0. This make integration challenging. We should upgrade our
> dependency to match Spring. This will make it easier for our users to write
> geode applications.
> Checking for other updates using
> {noformat}
> gradle dependencyUpdates
> find . -name report.txt | xargs grep -e "\]$" | grep -v "org.apache.geode" |
> tr -s " " | cut -d' ' -f3- | sort | uniq | less
> {noformat}
> show that we have some other libraries that can be updated as well:
> {noformat}
> com.fasterxml.jackson.core:jackson-annotations [2.9.4 -> 2.9.5]
> com.fasterxml.jackson.core:jackson-core [2.9.4 -> 2.9.5]
> com.fasterxml.jackson.core:jackson-databind [2.9.4 -> 2.9.5]
> com.fasterxml.jackson.module:jackson-module-scala_2.10 [2.9.4 -> 2.9.5]
> com.google.guava:guava [24.0-jre -> 24.1-jre]
> com.google.protobuf:protoc [3.5.1 -> 3.5.1-1]
> com.zaxxer:HikariCP [2.7.6 -> 3.0.0]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5125) Document internal use of "cluster" group
[ https://issues.apache.org/jira/browse/GEODE-5125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barbara Pruijn updated GEODE-5125: -- Component/s: docs > Document internal use of "cluster" group > > > Key: GEODE-5125 > URL: https://issues.apache.org/jira/browse/GEODE-5125 > Project: Geode > Issue Type: Task > Components: docs >Reporter: Patrick Rhomberg >Priority: Major > > Internally, we use the implicit member group "cluster" for any configuration > elements that apply to every member. While it might seem nonsensical for a > user to name a group "cluster" that contains only some and not all of the > cluster, this should discouraged in the documentation, as its use will result > in unexpected behavior. > Primary locations for this note could be: > https://geode.apache.org/docs/guide/15/configuring/cluster_config/using_member_groups.html > and/or the linked pages at the bottom of that page: > https://geode.apache.org/docs/guide/15/topologies_and_comm/p2p_configuration/configuring_peer_member_groups.html > https://geode.apache.org/docs/guide/15/topologies_and_comm/cs_configuration/configure_servers_into_logical_groups.html > As an aside, the linked pages are inconsistent on the capitalization of > "into." -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-5110) Remove use of subSections in CompositeResultData structures
[ https://issues.apache.org/jira/browse/GEODE-5110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barbara Pruijn resolved GEODE-5110. --- Resolution: Fixed > Remove use of subSections in CompositeResultData structures > --- > > Key: GEODE-5110 > URL: https://issues.apache.org/jira/browse/GEODE-5110 > Project: Geode > Issue Type: Sub-task > Components: gfsh >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 40m > Remaining Estimate: 0h > > There doesn't seem to be a need to use subsections anywhere. > Remove addSubsection methods from CompositeResultData -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5110) Remove use of subSections in CompositeResultData structures
[ https://issues.apache.org/jira/browse/GEODE-5110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barbara Pruijn updated GEODE-5110: -- Fix Version/s: 1.7.0 > Remove use of subSections in CompositeResultData structures > --- > > Key: GEODE-5110 > URL: https://issues.apache.org/jira/browse/GEODE-5110 > Project: Geode > Issue Type: Sub-task > Components: gfsh >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 40m > Remaining Estimate: 0h > > There doesn't seem to be a need to use subsections anywhere. > Remove addSubsection methods from CompositeResultData -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-5095) Fix output for create gateway-receiver (port number)
[
https://issues.apache.org/jira/browse/GEODE-5095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn resolved GEODE-5095.
---
Resolution: Fixed
> Fix output for create gateway-receiver (port number)
>
>
> Key: GEODE-5095
> URL: https://issues.apache.org/jira/browse/GEODE-5095
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Barbara Pruijn
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The gfsh command "create gateway-receiver" has the following output:
> {code:java}
> gfsh>create gateway-receiver
> Member | Status
> -- |
> --
> s1 | GatewayReceiver created on member "s1" and will listen on the port
> "5,383"
> {code}
>
> The port number should not have comma in it.
> {code:java}
> GatewayReceiver created on member "s1" and will listen on the port
> "5383"{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5095) Fix output for create gateway-receiver (port number)
[
https://issues.apache.org/jira/browse/GEODE-5095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn updated GEODE-5095:
--
Fix Version/s: 1.7.0
> Fix output for create gateway-receiver (port number)
>
>
> Key: GEODE-5095
> URL: https://issues.apache.org/jira/browse/GEODE-5095
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Barbara Pruijn
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The gfsh command "create gateway-receiver" has the following output:
> {code:java}
> gfsh>create gateway-receiver
> Member | Status
> -- |
> --
> s1 | GatewayReceiver created on member "s1" and will listen on the port
> "5,383"
> {code}
>
> The port number should not have comma in it.
> {code:java}
> GatewayReceiver created on member "s1" and will listen on the port
> "5383"{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-4954) Improve spotless -- remove trivial javadoc stubs
[
https://issues.apache.org/jira/browse/GEODE-4954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn updated GEODE-4954:
--
Fix Version/s: 1.7.0
> Improve spotless -- remove trivial javadoc stubs
>
>
> Key: GEODE-4954
> URL: https://issues.apache.org/jira/browse/GEODE-4954
> Project: Geode
> Issue Type: Sub-task
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 4h 10m
> Remaining Estimate: 0h
>
> For instance, the block
> {noformat}
> @param myparam
> @param secondParam
> @throws Exception
> {noformat}
> is entirely implicit by the method's signature, which is included in the
> javadoc itself. Javadoc stubs that do not include description of a given
> term is trivial, redundant, and should be removed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-4955) Improve spotless -- Remove empty javadocs and block comments
[ https://issues.apache.org/jira/browse/GEODE-4955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barbara Pruijn updated GEODE-4955: -- Fix Version/s: 1.7.0 > Improve spotless -- Remove empty javadocs and block comments > > > Key: GEODE-4955 > URL: https://issues.apache.org/jira/browse/GEODE-4955 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Rhomberg >Assignee: Patrick Rhomberg >Priority: Major > Fix For: 1.7.0 > > > This should be executed after GEODE-4654, since the removal of javadoc stubs > may yield a now-empty javadoc. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-5069) Reduce direct exposure of GfJsonObject from CommandResult
[ https://issues.apache.org/jira/browse/GEODE-5069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barbara Pruijn resolved GEODE-5069. --- Resolution: Fixed > Reduce direct exposure of GfJsonObject from CommandResult > - > > Key: GEODE-5069 > URL: https://issues.apache.org/jira/browse/GEODE-5069 > Project: Geode > Issue Type: Sub-task > Components: gfsh >Reporter: Jens Deppe >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5069) Reduce direct exposure of GfJsonObject from CommandResult
[ https://issues.apache.org/jira/browse/GEODE-5069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barbara Pruijn updated GEODE-5069: -- Fix Version/s: 1.7.0 > Reduce direct exposure of GfJsonObject from CommandResult > - > > Key: GEODE-5069 > URL: https://issues.apache.org/jira/browse/GEODE-5069 > Project: Geode > Issue Type: Sub-task > Components: gfsh >Reporter: Jens Deppe >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5100) CI Failure: WanCommandListDUnitTest fails intermittently with null pointer
[
https://issues.apache.org/jira/browse/GEODE-5100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn updated GEODE-5100:
--
Labels: ci (was: )
> CI Failure: WanCommandListDUnitTest fails intermittently with null pointer
> --
>
> Key: GEODE-5100
> URL: https://issues.apache.org/jira/browse/GEODE-5100
> Project: Geode
> Issue Type: New Feature
> Components: gfsh
>Reporter: Sai Boorlagadda
>Priority: Major
> Labels: ci
>
> {noformat}
> java.lang.AssertionError: Suspicious strings were written to the log during
> this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 2783
> [error 2018/04/18 00:26:03.706 UTC
> tid=92] Could not execute "list gateways".
> java.lang.NullPointerException
> at java.util.Arrays.stream(Arrays.java:5004)
> at
> org.apache.geode.management.internal.cli.commands.ListGatewayCommand.accumulateListGatewayResult(ListGatewayCommand.java:153)
> at
> org.apache.geode.management.internal.cli.commands.ListGatewayCommand.listGateway(ListGatewayCommand.java:112)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.springframework.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:216)
> at
> org.apache.geode.management.internal.cli.remote.CommandExecutor.invokeCommand(CommandExecutor.java:97)
> at
> org.apache.geode.management.internal.cli.remote.CommandExecutor.execute(CommandExecutor.java:45)
> at
> org.apache.geode.management.internal.cli.remote.CommandExecutor.execute(CommandExecutor.java:39)
> at
> org.apache.geode.management.internal.cli.remote.OnlineCommandProcessor.executeCommand(OnlineCommandProcessor.java:127)
> at
> org.apache.geode.management.internal.beans.MemberMBeanBridge.processCommand(MemberMBeanBridge.java:1514)
> at
> org.apache.geode.management.internal.beans.MemberMBean.processCommand(MemberMBean.java:417)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
> at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
> at
> com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:193)
> at
> com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:175)
> at
> com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:117)
> at
> com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:54)
> at
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at
> com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> at
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1468)
> at
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:76)
> at
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1309)
> at
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1401)
> at
> javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:829)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:361)
> at
[jira] [Commented] (GEODE-5070) Support --member option for describe & list jdbc connector commands
[ https://issues.apache.org/jira/browse/GEODE-5070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16442900#comment-16442900 ] Barbara Pruijn commented on GEODE-5070: --- Reopening the ticket. Because of refactoring work, the original code has been remove (implementation of jdbc-connection commands without --member option). Therefore, we cannot roll back. We need to leave the ticket open to program code to get the command back to the original state (pick configuration from random server) after the refactoring code. > Support --member option for describe & list jdbc connector commands > --- > > Key: GEODE-5070 > URL: https://issues.apache.org/jira/browse/GEODE-5070 > Project: Geode > Issue Type: New Feature > Components: gfsh >Reporter: Sai Boorlagadda >Assignee: Sai Boorlagadda >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > When cluster configuration service is disabled user have to provide --member > option in-order to describe and list connections and mappings. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (GEODE-5070) Support --member option for describe & list jdbc connector commands
[ https://issues.apache.org/jira/browse/GEODE-5070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barbara Pruijn reopened GEODE-5070: --- Assignee: Sai Boorlagadda > Support --member option for describe & list jdbc connector commands > --- > > Key: GEODE-5070 > URL: https://issues.apache.org/jira/browse/GEODE-5070 > Project: Geode > Issue Type: New Feature > Components: gfsh >Reporter: Sai Boorlagadda >Assignee: Sai Boorlagadda >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > When cluster configuration service is disabled user have to provide --member > option in-order to describe and list connections and mappings. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-5070) Support --member option for describe & list jdbc connector commands
[ https://issues.apache.org/jira/browse/GEODE-5070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barbara Pruijn resolved GEODE-5070. --- Resolution: Won't Do > Support --member option for describe & list jdbc connector commands > --- > > Key: GEODE-5070 > URL: https://issues.apache.org/jira/browse/GEODE-5070 > Project: Geode > Issue Type: New Feature > Components: gfsh >Reporter: Sai Boorlagadda >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > When cluster configuration service is disabled user have to provide --member > option in-order to describe and list connections and mappings. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5070) Support --member option for describe & list jdbc connector commands
[ https://issues.apache.org/jira/browse/GEODE-5070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16442887#comment-16442887 ] Barbara Pruijn commented on GEODE-5070: --- Background info on this ticket: Spring data users may have cluster config turned off. The current implementation of the describe jdbc-connection and list jdbc-connections takes the jdbc info from a random server in the cluster and returns that info. This reason this ticket was created is that there is no way to get the jdbc info from a specific server. But, currently, there is no advised way to have different jdbc-connections on different servers in the cluster and there is no user need for doing this up to this point. Since we therefore assume that the jdbc-connections will be the same on all servers in a cluster, we will not be adding the --member param for now. Therefore, closing this ticket as "will not do". > Support --member option for describe & list jdbc connector commands > --- > > Key: GEODE-5070 > URL: https://issues.apache.org/jira/browse/GEODE-5070 > Project: Geode > Issue Type: New Feature > Components: gfsh >Reporter: Sai Boorlagadda >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > When cluster configuration service is disabled user have to provide --member > option in-order to describe and list connections and mappings. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (GEODE-4959) Attempt to create multiple gw receivers results an error on gfsh console.
[
https://issues.apache.org/jira/browse/GEODE-4959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16441320#comment-16441320
]
Barbara Pruijn edited comment on GEODE-4959 at 4/17/18 8:49 PM:
When calling command
{code:java}
create gateway-receiver{code}
on a cluster but one member in the cluster already has a gateway receiver, the
command will create a gateway receiver on the other members in the cluster, but
will not persist the gateway receivers in the cluster. In this case we need to
display a warning that the gateway receivers will not be persisted in cluster
config.
{code:java}
gfsh>create gateway-receiver --member=s1
This change is not persisted in the cluster configuration, either because the
cluster configuration service is not running or the command is operating on
targeted members.
Member | Status
-- |
--
s1 | GatewayReceiver created on member "s1" and will listen on the port
"5,071"
gfsh>create gateway-receiver
Member | Status
-- |
-
s1 | ERROR: java.lang.IllegalStateException: A Gateway Receiver already
exists on this member.
s2 | GatewayReceiver created on member "s2" and will listen on the port
"5,138"
This change is not persisted in the cluster configuration, because an error
occurred during execution.
{code}
was (Author: bpruijn):
When calling command
{code:java}
create gateway-receiver{code}
on a cluster but one member in the cluster already has a gateway receiver, the
command will create a gateway receiver on the other members in the cluster, but
will not persist the gateway receivers in the cluster. In this case we need to
display a warning that the gateway receivers will not be persisted in cluster
config.
{code:java}
gfsh>create gateway-receiver --member=s1
This change is not persisted in the cluster configuration, either because the
cluster configuration service is not running or the command is operating on
targeted members.
Member | Status
-- |
--
s1 | GatewayReceiver created on member "s1" and will listen on the port
"5,071"
gfsh>create gateway-receiver
This change is not persisted in the cluster configuration, because a gateway
receiver already existed on a member before running this command.
Member | Status
-- |
-
s1 | ERROR: java.lang.IllegalStateException: A Gateway Receiver already
exists on this member.
s2 | GatewayReceiver created on member "s2" and will listen on the port
"5,138"
{code}
> Attempt to create multiple gw receivers results an error on gfsh console.
> -
>
> Key: GEODE-4959
> URL: https://issues.apache.org/jira/browse/GEODE-4959
> Project: Geode
> Issue Type: Bug
> Components: docs, gfsh
>Reporter: Sai Boorlagadda
>Assignee: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> {{There are several issues with create gateway-receiver command.}}
> 1) Starting 1.4.0, with GEODE-3987 there is an enforcement of one gwr per
> node in the xsd. So when user attempts to create multiple gwr show a better
> error message then showing "*ERROR: java.lang.IllegalStateException*".
> {noformat}
> gfsh>start server --locators=localhost[10334]
> Starting a Geode Server in
> /Users/sboorlagadda/workspace/debug/geode/apache-geode-1.4.0/bin/walk-proud-feet...
> ...
> Server in
> /Users/sboorlagadda/workspace/debug/geode/apache-geode-1.4.0/bin/walk-proud-feet
> on sais-mbp-2.netgear.com[40404] as walk-proud-feet is currently online.
> Process ID: 35197
> Uptime: 4 seconds
> Geode Version: 1.4.0
> Java Version: 1.8.0_151
> Log File:
> /Users/sboorlagadda/workspace/debug/geode/apache-geode-1.4.0/bin/walk-proud-feet/walk-proud-feet.log
> JVM Arguments: -Dgemfire.locators=localhost[10334]
> -Dgemfire.start-dev-rest-api=false -Dgemfire.use-cluster-configuration=true
> -XX:OnOutOfMemoryError=kill -KILL %p
> -Dgemfire.launcher.registerSignalHandlers=true -Djava.awt.headless=true
> -Dsun.rmi.dgc.server.gcInterval=9223372036854775806
> Class-Path:
> /Users/sboorlagadda/workspace/debug/geode/apache-geode-1.4.0/lib/geode-core-1.4.0.jar:/Users/sboorlagadda/workspace/debug/geode/apache-geode-1.4.0/lib/geode-dependencies.jar
> gfsh>create gateway-receiver
> Member | Status
> --- |
> ---
> walk-proud-feet | GatewayReceiver created on member "walk-proud-feet" and
>
[jira] [Updated] (GEODE-5095) Fix output for create gateway-receiver (port number)
[
https://issues.apache.org/jira/browse/GEODE-5095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn updated GEODE-5095:
--
Description:
The gfsh command "create gateway-receiver" has the following output:
{code:java}
gfsh>create gateway-receiver
Member | Status
-- |
--
s1 | GatewayReceiver created on member "s1" and will listen on the port
"5,383"
{code}
The port number should not have comma in it.
{code:java}
GatewayReceiver created on member "s1" and will listen on the port "5383"{code}
was:
The gfsh command "create gateway-receiver" has the following output:
{code:java}
gfsh>create gateway-receiver
Member | Status
-- |
--
s1 | GatewayReceiver created on member "s1" and will listen on the port
"5,383"
{code}
The port number should not have comma in it.
> Fix output for create gateway-receiver (port number)
>
>
> Key: GEODE-5095
> URL: https://issues.apache.org/jira/browse/GEODE-5095
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Barbara Pruijn
>Priority: Major
>
> The gfsh command "create gateway-receiver" has the following output:
> {code:java}
> gfsh>create gateway-receiver
> Member | Status
> -- |
> --
> s1 | GatewayReceiver created on member "s1" and will listen on the port
> "5,383"
> {code}
>
> The port number should not have comma in it.
> {code:java}
> GatewayReceiver created on member "s1" and will listen on the port
> "5383"{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-5095) Fix output for create gateway-receiver (port number)
Barbara Pruijn created GEODE-5095:
-
Summary: Fix output for create gateway-receiver (port number)
Key: GEODE-5095
URL: https://issues.apache.org/jira/browse/GEODE-5095
Project: Geode
Issue Type: Bug
Components: gfsh
Reporter: Barbara Pruijn
The gfsh command "create gateway-receiver" has the following output:
{code:java}
gfsh>create gateway-receiver
Member | Status
-- |
--
s1 | GatewayReceiver created on member "s1" and will listen on the port
"5,383"
{code}
The port number should not have comma in it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-4959) Attempt to create multiple gw receivers results an error on gfsh console.
[
https://issues.apache.org/jira/browse/GEODE-4959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16441320#comment-16441320
]
Barbara Pruijn commented on GEODE-4959:
---
When calling command
{code:java}
create gateway-receiver{code}
on a cluster but one member in the cluster already has a gateway receiver, the
command will create a gateway receiver on the other members in the cluster, but
will not persist the gateway receivers in the cluster. In this case we need to
display a warning that the gateway receivers will not be persisted in cluster
config.
{code:java}
gfsh>create gateway-receiver --member=s1
This change is not persisted in the cluster configuration, either because the
cluster configuration service is not running or the command is operating on
targeted members.
Member | Status
-- |
--
s1 | GatewayReceiver created on member "s1" and will listen on the port
"5,071"
gfsh>create gateway-receiver
This change is not persisted in the cluster configuration, because a gateway
receiver already existed on a member before running this command.
Member | Status
-- |
-
s1 | ERROR: java.lang.IllegalStateException: A Gateway Receiver already
exists on this member.
s2 | GatewayReceiver created on member "s2" and will listen on the port
"5,138"
{code}
> Attempt to create multiple gw receivers results an error on gfsh console.
> -
>
> Key: GEODE-4959
> URL: https://issues.apache.org/jira/browse/GEODE-4959
> Project: Geode
> Issue Type: Bug
> Components: docs, gfsh
>Reporter: Sai Boorlagadda
>Assignee: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> {{There are several issues with create gateway-receiver command.}}
> 1) Starting 1.4.0, with GEODE-3987 there is an enforcement of one gwr per
> node in the xsd. So when user attempts to create multiple gwr show a better
> error message then showing "*ERROR: java.lang.IllegalStateException*".
> {noformat}
> gfsh>start server --locators=localhost[10334]
> Starting a Geode Server in
> /Users/sboorlagadda/workspace/debug/geode/apache-geode-1.4.0/bin/walk-proud-feet...
> ...
> Server in
> /Users/sboorlagadda/workspace/debug/geode/apache-geode-1.4.0/bin/walk-proud-feet
> on sais-mbp-2.netgear.com[40404] as walk-proud-feet is currently online.
> Process ID: 35197
> Uptime: 4 seconds
> Geode Version: 1.4.0
> Java Version: 1.8.0_151
> Log File:
> /Users/sboorlagadda/workspace/debug/geode/apache-geode-1.4.0/bin/walk-proud-feet/walk-proud-feet.log
> JVM Arguments: -Dgemfire.locators=localhost[10334]
> -Dgemfire.start-dev-rest-api=false -Dgemfire.use-cluster-configuration=true
> -XX:OnOutOfMemoryError=kill -KILL %p
> -Dgemfire.launcher.registerSignalHandlers=true -Djava.awt.headless=true
> -Dsun.rmi.dgc.server.gcInterval=9223372036854775806
> Class-Path:
> /Users/sboorlagadda/workspace/debug/geode/apache-geode-1.4.0/lib/geode-core-1.4.0.jar:/Users/sboorlagadda/workspace/debug/geode/apache-geode-1.4.0/lib/geode-dependencies.jar
> gfsh>create gateway-receiver
> Member | Status
> --- |
> ---
> walk-proud-feet | GatewayReceiver created on member "walk-proud-feet" and
> will listen on the port "5,221"
> gfsh>create gateway-receiver
> Member | Status
> --- |
> -
> walk-proud-feet | ERROR: java.lang.IllegalStateException: A Gateway Receiver
> already exists on this member.{noformat}
> 2) create gwr command should enforce only one gwr can be created as with
> GEODE-3987, xsd supports only one.
> 3) create gwr command is storing the gwr in cluster config when created with
> --member option.
> As there is no enforcement until 1.3 and with above stated issues with gfsh,
> it could happen that some one could end up a cluster with multiple gwr
> created in cluster configuration and could prevent them to upgrade to 1.4.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5048) Availability Indicator for "list jndi-bindings", "list jdbc-connections" and "list jdbc-mappings" are wrong
[ https://issues.apache.org/jira/browse/GEODE-5048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barbara Pruijn resolved GEODE-5048. --- Resolution: Fixed > Availability Indicator for "list jndi-bindings", "list jdbc-connections" and > "list jdbc-mappings" are wrong > --- > > Key: GEODE-5048 > URL: https://issues.apache.org/jira/browse/GEODE-5048 > Project: Geode > Issue Type: Bug > Components: gfsh >Affects Versions: 1.4.0 >Reporter: Jinmei Liao >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > those commands, when not connected to a locator, should be listed as "not > available" in gfsh help, but they are listed as "available". -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-5000) When initializing a client cache, we don't need to request/apply cluster configuration
[
https://issues.apache.org/jira/browse/GEODE-5000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn resolved GEODE-5000.
---
Resolution: Fixed
> When initializing a client cache, we don't need to request/apply cluster
> configuration
> --
>
> Key: GEODE-5000
> URL: https://issues.apache.org/jira/browse/GEODE-5000
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Affects Versions: 1.4.0
>Reporter: Jinmei Liao
>Assignee: Jinmei Liao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The user running a gemfire client doesn't have write access to the local dirs
> in the customer environment, and they get an stack trace in their logs. This
> is caused by a client cache trying to request/apply cluster configuration.
> {noformat}
> [error 2018/02/12 17:52:13.899 EST tid=0x12] Error
> when attempting to deploy JAR files on load.
> java.io.IOException: Unable to write to deploy directory
> at
> org.apache.geode.internal.JarDeployer.verifyWritableDeployDirectory(JarDeployer.java:626)
> at
> org.apache.geode.internal.JarDeployer.loadPreviouslyDeployedJars(JarDeployer.java:74)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1242)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:794)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.createClient(GemFireCacheImpl.java:767)
> at
> org.apache.geode.cache.client.ClientCacheFactory.basicCreate(ClientCacheFactory.java:257)
> at
> org.apache.geode.cache.client.ClientCacheFactory.create(ClientCacheFactory.java:207){noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-4990) Race Condition When Using Cluster Configuration Service
[
https://issues.apache.org/jira/browse/GEODE-4990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn updated GEODE-4990:
--
Fix Version/s: (was: 1.6.0)
1.7.0
> Race Condition When Using Cluster Configuration Service
> ---
>
> Key: GEODE-4990
> URL: https://issues.apache.org/jira/browse/GEODE-4990
> Project: Geode
> Issue Type: Bug
> Components: configuration, locator
>Affects Versions: 1.4.0
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> There's a small window of time on which the locator
> ({{enable-cluster-configuration=true}}) is receiving TCP requests from
> starting up servers ({{use-cluster-configuration=true}}) but the cluster
> configuration service is not yet fully loaded, because of this the servers
> fail to startup and throw the following exception:
> {noformat}
> Exception in thread "main" org.apache.geode.cache.execute.FunctionException:
> java.lang.NullPointerException
> at
> org.apache.geode.internal.cache.execute.FunctionStreamingResultCollector.getResult(FunctionStreamingResultCollector.java:232)
> at
> org.apache.geode.internal.cache.ClusterConfigurationLoader.requestConfigurationFromLocators(ClusterConfigurationLoader.java:285)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:1036)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.(GemFireCacheImpl.java:835)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:775)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:764)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:175)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:222)
> at
> org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52)
> at
> org.apache.geode.distributed.ServerLauncher.createCache(ServerLauncher.java:844)
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:762)
> at
> org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:692)
> at
> org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:226)
> Caused by: java.lang.NullPointerException
> at
> org.apache.geode.management.internal.configuration.functions.GetClusterConfigurationFunction.execute(GetClusterConfigurationFunction.java:55)
> at
> org.apache.geode.internal.cache.MemberFunctionStreamingMessage.process(MemberFunctionStreamingMessage.java:186)
> at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:382)
> at
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:448)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.geode.distributed.internal.DistributionManager.runUntilShutdown(DistributionManager.java:1099)
> at
> org.apache.geode.distributed.internal.DistributionManager.access$000(DistributionManager.java:108)
> at
> org.apache.geode.distributed.internal.DistributionManager$9$1.run(DistributionManager.java:970)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> The logs from the locator, when using {{log-level=fine}} show the following:
> {noformat}
> [fine 2018/04/03 15:24:40.501 IST locator1
> tid=0x51] Exception occurred on remote member while executing Function:
> org.apache.geode.management.internal.configuration.functions.GetClusterConfigurationFunction
> java.lang.NullPointerException
> at
> org.apache.geode.management.internal.configuration.functions.GetClusterConfigurationFunction.execute(GetClusterConfigurationFunction.java:55)
> at
> org.apache.geode.internal.cache.MemberFunctionStreamingMessage.process(MemberFunctionStreamingMessage.java:186)
> at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:382)
> at
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:448)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.geode.distributed.internal.DistributionManager.runUntilShutdown(DistributionManager.java:1099)
> at
>
[jira] [Resolved] (GEODE-4897) Availability is wrong on some commands.
[
https://issues.apache.org/jira/browse/GEODE-4897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn resolved GEODE-4897.
---
Resolution: Duplicate
https://issues.apache.org/jira/browse/GEODE-5048
> Availability is wrong on some commands.
> ---
>
> Key: GEODE-4897
> URL: https://issues.apache.org/jira/browse/GEODE-4897
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Sai Boorlagadda
>Priority: Major
>
> For example, look at any JDBC connector commands or ListJndiBindingCommand
> and could be more. When you launch gfsh (and not connected) then you can see
> these commands are available.
> {noformat}
> create jdbc-connection (Available)
> (Experimental) Create a connection for communicating with a database through
> jdbc.
> create jdbc-mapping (Available)
> (Experimental) Create a mapping for a region for use with a JDBC database
> connection.{noformat}
> {{There is a test to test the availability marker but the test itself has a
> bug due to which the command authors are not warned about the marker. Look
> into CommandAvailabilityIndicatorTest}}
> {noformat}
> if (cliMetaData != null && !cliMetaData.shellOnly()) -> here cliMetaData
> could be null if the command author forget to annotate the command.{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5048) Availability Indicator for "list jndi-bindings", "list jdbc-connections" and "list jdbc-mappings" are wrong
[ https://issues.apache.org/jira/browse/GEODE-5048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barbara Pruijn updated GEODE-5048: -- Fix Version/s: 1.7.0 > Availability Indicator for "list jndi-bindings", "list jdbc-connections" and > "list jdbc-mappings" are wrong > --- > > Key: GEODE-5048 > URL: https://issues.apache.org/jira/browse/GEODE-5048 > Project: Geode > Issue Type: Bug > Components: gfsh >Affects Versions: 1.4.0 >Reporter: Jinmei Liao >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 10m > Remaining Estimate: 0h > > those commands, when not connected to a locator, should be listed as "not > available" in gfsh help, but they are listed as "available". -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4897) Availability is wrong on some commands.
[
https://issues.apache.org/jira/browse/GEODE-4897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn updated GEODE-4897:
--
Fix Version/s: 1.7.0
> Availability is wrong on some commands.
> ---
>
> Key: GEODE-4897
> URL: https://issues.apache.org/jira/browse/GEODE-4897
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Sai Boorlagadda
>Priority: Major
> Fix For: 1.7.0
>
>
> For example, look at any JDBC connector commands or ListJndiBindingCommand
> and could be more. When you launch gfsh (and not connected) then you can see
> these commands are available.
> {noformat}
> create jdbc-connection (Available)
> (Experimental) Create a connection for communicating with a database through
> jdbc.
> create jdbc-mapping (Available)
> (Experimental) Create a mapping for a region for use with a JDBC database
> connection.{noformat}
> {{There is a test to test the availability marker but the test itself has a
> bug due to which the command authors are not warned about the marker. Look
> into CommandAvailabilityIndicatorTest}}
> {noformat}
> if (cliMetaData != null && !cliMetaData.shellOnly()) -> here cliMetaData
> could be null if the command author forget to annotate the command.{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5080) CI Failure: ClusterConfigLocatorRestartDUnitTest.serverRestartsAfterLocatorReconnects
[
https://issues.apache.org/jira/browse/GEODE-5080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn updated GEODE-5080:
--
Labels: ci (was: )
> CI Failure:
> ClusterConfigLocatorRestartDUnitTest.serverRestartsAfterLocatorReconnects
> -
>
> Key: GEODE-5080
> URL: https://issues.apache.org/jira/browse/GEODE-5080
> Project: Geode
> Issue Type: Bug
> Components: gfsh, management
>Reporter: Jens Deppe
>Priority: Major
> Labels: ci
>
> This test intermittently fails with with following:
> {noformat}
> org.apache.geode.management.internal.configuration.ClusterConfigLocatorRestartDUnitTest
> > serverRestartsAfterLocatorReconnects FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.rules.ClusterStartupRule$$Lambda$41/761947362.call
> in VM 3 running on Host b669312074c0 with 5 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:436)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:405)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:371)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.startServerVM(ClusterStartupRule.java:203)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.startServerVM(ClusterStartupRule.java:196)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.startServerVM(ClusterStartupRule.java:182)
> at
> org.apache.geode.management.internal.configuration.ClusterConfigLocatorRestartDUnitTest.serverRestartsAfterLocatorReconnects(ClusterConfigLocatorRestartDUnitTest.java:65)
> Caused by:
> org.apache.geode.GemFireConfigException: Unable to join the
> distributed system. Operation either timed out, was stopped or Locator does
> not exist.
> {noformat}
> The detailed test failure shows the following cause:
> {noformat}
> Caused by: org.apache.geode.GemFireConfigException: Unable to join the
> distributed system. Operation either timed out, was stopped or Locator does
> not exist.
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.join(GMSMembershipManager.java:661)
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.joinDistributedSystem(GMSMembershipManager.java:747)
> at
> org.apache.geode.distributed.internal.membership.gms.Services.start(Services.java:191)
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMemberFactory.newMembershipManager(GMSMemberFactory.java:106)
> at
> org.apache.geode.distributed.internal.membership.MemberFactory.newMembershipManager(MemberFactory.java:90)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:1027)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:1061)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:554)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:763)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:355)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:343)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:335)
> at
> org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:211)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:219)
> at
> org.apache.geode.test.junit.rules.ServerStarterRule.startServer(ServerStarterRule.java:172)
> at
> org.apache.geode.test.junit.rules.ServerStarterRule.before(ServerStarterRule.java:78)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.lambda$startServerVM$a2926408$1(ClusterStartupRule.java:212)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at hydra.MethExecutor.executeObject(MethExecutor.java:244)
> at
> org.apache.geode.test.dunit.standalone.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:70)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
>
[jira] [Updated] (GEODE-4874) Inconsistency in gfsh help for create jndi-binding
[ https://issues.apache.org/jira/browse/GEODE-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barbara Pruijn updated GEODE-4874: -- Fix Version/s: (was: 1.6.0) 1.7.0 > Inconsistency in gfsh help for create jndi-binding > --- > > Key: GEODE-4874 > URL: https://issues.apache.org/jira/browse/GEODE-4874 > Project: Geode > Issue Type: Bug > Components: gfsh >Affects Versions: 1.5.0 >Reporter: Karen Smoler Miller >Priority: Minor > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 40m > Remaining Estimate: 0h > > I see an error and an inconsistency when trying to use the gfsh help > functionality for create jndi-binding. > Tab completion of > create jndi-binding > outputs > gfsh>create jndi-binding – > create jndi-binding --connection-url > create jndi-binding --jdbc-driver-class > create jndi-binding --name > create jndi-binding --type > This is inconsistent with the output of other tab completions, which just > give the options, and do not repeat the "create jndi-binding" portion of the > command. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4962) Fix typo and output format from 'list gateways' gfsh command
[
https://issues.apache.org/jira/browse/GEODE-4962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn updated GEODE-4962:
--
Fix Version/s: (was: 1.6.0)
1.7.0
> Fix typo and output format from 'list gateways' gfsh command
>
>
> Key: GEODE-4962
> URL: https://issues.apache.org/jira/browse/GEODE-4962
> Project: Geode
> Issue Type: Bug
> Components: gfsh, wan
>Reporter: Diane Hardman
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The output printed from `list gateways` command needs some TLC:
> Sample output:
> {noformat}
> Cluster-2 gfsh>list gateways
> Gateways
> GatewaySender
> GatewaySender Id | Member | Remote Cluster
> Id | Type | Status | Queued Events | Receiver Location
> | |
> - | | --- | - | -
> ny | 10.118.19.46(server-ln-1:31527):1026 | 1
> | Parallel | Running | 0 | 10.118.19.46:5248
> ny | 10.118.19.46(server-ln-2:31545):1027 | 1
> | Parallel | Running | 0 | 10.118.19.46:5269
> GatewayReceiver
> Member | Port | Sender Count | Sender's
> Connected
> | | |
>
> 10.118.19.46(server-ln-1:31527):1026 | 5407 | 7 |
> [Ljava.lang.String;@7deec2d6
> 10.118.19.46(server-ln-2:31545):1027 | 5071 | 7 |
> [Ljava.lang.String;@6baa580f
> {noformat}
> Note: 'Sender's Connected' should instead be 'Senders Connected'
> Also, need to pretty-print the String[] for Senders Connected.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-4962) Fix typo and output format from 'list gateways' gfsh command
[
https://issues.apache.org/jira/browse/GEODE-4962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn resolved GEODE-4962.
---
Resolution: Fixed
> Fix typo and output format from 'list gateways' gfsh command
>
>
> Key: GEODE-4962
> URL: https://issues.apache.org/jira/browse/GEODE-4962
> Project: Geode
> Issue Type: Bug
> Components: gfsh, wan
>Reporter: Diane Hardman
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.6.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The output printed from `list gateways` command needs some TLC:
> Sample output:
> {noformat}
> Cluster-2 gfsh>list gateways
> Gateways
> GatewaySender
> GatewaySender Id | Member | Remote Cluster
> Id | Type | Status | Queued Events | Receiver Location
> | |
> - | | --- | - | -
> ny | 10.118.19.46(server-ln-1:31527):1026 | 1
> | Parallel | Running | 0 | 10.118.19.46:5248
> ny | 10.118.19.46(server-ln-2:31545):1027 | 1
> | Parallel | Running | 0 | 10.118.19.46:5269
> GatewayReceiver
> Member | Port | Sender Count | Sender's
> Connected
> | | |
>
> 10.118.19.46(server-ln-1:31527):1026 | 5407 | 7 |
> [Ljava.lang.String;@7deec2d6
> 10.118.19.46(server-ln-2:31545):1027 | 5071 | 7 |
> [Ljava.lang.String;@6baa580f
> {noformat}
> Note: 'Sender's Connected' should instead be 'Senders Connected'
> Also, need to pretty-print the String[] for Senders Connected.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-4874) Inconsistency in gfsh help for create jndi-binding
[ https://issues.apache.org/jira/browse/GEODE-4874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barbara Pruijn resolved GEODE-4874. --- Resolution: Fixed > Inconsistency in gfsh help for create jndi-binding > --- > > Key: GEODE-4874 > URL: https://issues.apache.org/jira/browse/GEODE-4874 > Project: Geode > Issue Type: Bug > Components: gfsh >Affects Versions: 1.5.0 >Reporter: Karen Smoler Miller >Priority: Minor > Labels: pull-request-available > Fix For: 1.6.0 > > Time Spent: 40m > Remaining Estimate: 0h > > I see an error and an inconsistency when trying to use the gfsh help > functionality for create jndi-binding. > Tab completion of > create jndi-binding > outputs > gfsh>create jndi-binding – > create jndi-binding --connection-url > create jndi-binding --jdbc-driver-class > create jndi-binding --name > create jndi-binding --type > This is inconsistent with the output of other tab completions, which just > give the options, and do not repeat the "create jndi-binding" portion of the > command. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-5051) Improve gfsh destroy jndi-binding help prose
[ https://issues.apache.org/jira/browse/GEODE-5051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barbara Pruijn resolved GEODE-5051. --- Resolution: Fixed > Improve gfsh destroy jndi-binding help prose > > > Key: GEODE-5051 > URL: https://issues.apache.org/jira/browse/GEODE-5051 > Project: Geode > Issue Type: Improvement > Components: gfsh >Reporter: Karen Smoler Miller >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The current help text output for gfsh destroy jndi-binding contains some > errors: > gfsh>help destroy jndi-binding > NAME > destroy jndi-binding > IS AVAILABLE > false > SYNOPSIS > Destroy a jndi binding that holds the configuration for the XA datasource. > SYNTAX > destroy jndi-binding --name=value [--if-exists(=value)?] > PARAMETERS > name > Name of the binding to be destroyed. > Required: true > if-exists > Skip the destroy operation when a jndi binding with the same name does > not exists. Without specifying this option, this command execution > results into an error. > Required: false > Default (if the parameter is specified without value): true > Default (if the parameter is not specified): false > We can improve this text by changing the underlined prose to: > gfsh>help destroy jndi-binding > NAME > destroy jndi-binding > IS AVAILABLE > false > SYNOPSIS > Destroy a +JNDI+ binding that holds the configuration for +an+ XA > datasource. > SYNTAX > destroy jndi-binding --name=value [--if-exists(=value)?] > PARAMETERS > name > Name of the binding to be destroyed. > Required: true > if-exists > +Skip the destroy operation when the specified JNDI binding does+ > +not exist. Without this option, an error results from the > specification+ > +of a JNDI binding that does not exist.+ > Required: false > Default (if the parameter is specified without value): true > Default (if the parameter is not specified): false > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4863) refactor jdbc commands to use this public api
[ https://issues.apache.org/jira/browse/GEODE-4863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barbara Pruijn updated GEODE-4863: -- Fix Version/s: 1.7.0 > refactor jdbc commands to use this public api > - > > Key: GEODE-4863 > URL: https://issues.apache.org/jira/browse/GEODE-4863 > Project: Geode > Issue Type: Sub-task > Components: configuration >Reporter: Jinmei Liao >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 20m > Remaining Estimate: 0h > > they will need to create a custom config object based on their own xsd. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5071) Update the gfsh limitations documentation
[ https://issues.apache.org/jira/browse/GEODE-5071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barbara Pruijn updated GEODE-5071: -- Description: The list of gfsh limitations should be updated on this page: https://geode.apache.org/docs/guide/14/configuring/cluster_config/gfsh_persist.html#concept_r22_hyw_bl__section_bn3_23p_y4 Under the line: "You cannot directly modify the attributes of the following objects:" Please remove: cache-listener cache-loader cache-writer custom-expiry declarable Further down, please remove: Adding JNDI bindings was: The list of gfsh limitations should be updated on this page: Under the line: "You cannot directly modify the attributes of the following objects:" Please remove: cache-listener cache-loader cache-writer custom-expiry declarable Further down, please remove: Adding JNDI bindings > Update the gfsh limitations documentation > - > > Key: GEODE-5071 > URL: https://issues.apache.org/jira/browse/GEODE-5071 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Barbara Pruijn >Priority: Major > > The list of gfsh limitations should be updated on this page: > https://geode.apache.org/docs/guide/14/configuring/cluster_config/gfsh_persist.html#concept_r22_hyw_bl__section_bn3_23p_y4 > Under the line: "You cannot directly modify the attributes of the following > objects:" > Please remove: > cache-listener > cache-loader > cache-writer > custom-expiry > declarable > Further down, please remove: > Adding JNDI bindings > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5071) Update the gfsh limitations documentation
[ https://issues.apache.org/jira/browse/GEODE-5071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barbara Pruijn updated GEODE-5071: -- Description: The list of gfsh limitations should be updated on this page: Under the line: "You cannot directly modify the attributes of the following objects:" Please remove: cache-listener cache-loader cache-writer custom-expiry declarable Further down, please remove: Adding JNDI bindings was: The list of gfsh limitations should be updated on this page:[https://gemfire.docs.pivotal.io/geode/configuring/cluster_config/gfsh_persist.html] Under the line: "You cannot directly modify the attributes of the following objects:" Please remove: cache-listener cache-loader cache-writer custom-expiry declarable Further down, please remove: Adding JNDI bindings > Update the gfsh limitations documentation > - > > Key: GEODE-5071 > URL: https://issues.apache.org/jira/browse/GEODE-5071 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Barbara Pruijn >Priority: Major > > The list of gfsh limitations should be updated on this page: > Under the line: "You cannot directly modify the attributes of the following > objects:" > Please remove: > cache-listener > cache-loader > cache-writer > custom-expiry > declarable > Further down, please remove: > Adding JNDI bindings > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-5071) Update the gfsh limitations documentation
Barbara Pruijn created GEODE-5071: - Summary: Update the gfsh limitations documentation Key: GEODE-5071 URL: https://issues.apache.org/jira/browse/GEODE-5071 Project: Geode Issue Type: Improvement Components: docs Reporter: Barbara Pruijn The list of gfsh limitations should be updated on this page:[https://gemfire.docs.pivotal.io/geode/configuring/cluster_config/gfsh_persist.html] Under the line: "You cannot directly modify the attributes of the following objects:" Please remove: cache-listener cache-loader cache-writer custom-expiry declarable Further down, please remove: Adding JNDI bindings -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5053) Import and export should be supported with full cluster running
[ https://issues.apache.org/jira/browse/GEODE-5053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16436329#comment-16436329 ] Barbara Pruijn commented on GEODE-5053: --- The precondition of the use of this -force option is that you have exported your configuration and data (the configuration matches the data that you have exported). And then when you do a force import, the configuration and data that you import are in synch. This is an advanced option, not meant for the beginner. Maybe we should add a reaffirming question: "Are you sure? Your configuration needs to be consistent with the data that you will import. Y/n". When this option is run in a script, you should know what you are doing. > Import and export should be supported with full cluster running > --- > > Key: GEODE-5053 > URL: https://issues.apache.org/jira/browse/GEODE-5053 > Project: Geode > Issue Type: Improvement > Components: docs, gfsh, management >Affects Versions: 1.4.0, 1.5.0 >Reporter: Pulkit Chandra >Priority: Major > > We want to provide support to export /import config and data. We dont have > the ability to just run locators and not servers as we use BOSH to manage > Geode, which is required for `import` today > **Why** : As a operator if data contained in Geode is important, I would like > to ensure I can back it up. Use cases range from ensuring your data doesnt > get lost to migrating your data to another cluster. > **How**: `Import` and `export` command should be the way to go > **Limitations**: Cant have locators running and servers not running. Full > cluster would be running before import is called. We can do rolling restart, > if that is needed. > > its related to the issue https://issues.apache.org/jira/browse/GEODE-4893 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (GEODE-5053) Import and export should be supported with full cluster running
[
https://issues.apache.org/jira/browse/GEODE-5053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16436297#comment-16436297
]
Barbara Pruijn edited comment on GEODE-5053 at 4/12/18 9:09 PM:
Since there is a use case where specific configuration gets added to the
cluster before
{code:java}
import cluster-configuration{code}
is called, we need to have the option to wipe out any existing configuration
when importing a preferred configuration.
The proposal is to add the option -force:
{code:java}
import cluster-configuration --force{code}
The behavior of the -force is that any existing configuration on the cluster
will be replaced with the configuration provided in the import command.
--force is not provided by default (and is false) and the default value if
provided is true.
was (Author: bpruijn):
Since there is a use case where specific configuration gets added to the
cluster before
{code:java}
import cluster-configuration{code}
is called, we need to have the option to wipe out any existing configuration
when importing a preferred configuration.
The proposal is to add the option -force:
{code:java}
import cluster-configuration --force{code}
The behavior of the -force is that any existing configuration on the cluster
will be replaced with the configuration provided in the import command.
--force is not provided by default and the default value if provided is false.
> Import and export should be supported with full cluster running
> ---
>
> Key: GEODE-5053
> URL: https://issues.apache.org/jira/browse/GEODE-5053
> Project: Geode
> Issue Type: Improvement
> Components: docs, gfsh, management
>Affects Versions: 1.4.0, 1.5.0
>Reporter: Pulkit Chandra
>Priority: Major
>
> We want to provide support to export /import config and data. We dont have
> the ability to just run locators and not servers as we use BOSH to manage
> Geode, which is required for `import` today
> **Why** : As a operator if data contained in Geode is important, I would like
> to ensure I can back it up. Use cases range from ensuring your data doesnt
> get lost to migrating your data to another cluster.
> **How**: `Import` and `export` command should be the way to go
> **Limitations**: Cant have locators running and servers not running. Full
> cluster would be running before import is called. We can do rolling restart,
> if that is needed.
>
> its related to the issue https://issues.apache.org/jira/browse/GEODE-4893
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (GEODE-5053) Import and export should be supported with full cluster running
[
https://issues.apache.org/jira/browse/GEODE-5053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16436297#comment-16436297
]
Barbara Pruijn edited comment on GEODE-5053 at 4/12/18 9:07 PM:
Since there is a use case where specific configuration gets added to the
cluster before
{code:java}
import cluster-configuration{code}
is called, we need to have the option to wipe out any existing configuration
when importing a preferred configuration.
The proposal is to add the option -force:
{code:java}
import cluster-configuration --force{code}
The behavior of the -force is that any existing configuration on the cluster
will be replaced with the configuration provided in the import command.
--force is not provided by default and the default value if provided is false.
was (Author: bpruijn):
Since there is a use case where specific configuration gets added to the
cluster before
{code:java}
import cluster-configuration{code}
is called, we need to have the option to wipe out any existing configuration
when importing a preferred configuration.
The proposal is to add the option -force:
{code:java}
import cluster-configuration --force{code}
The behavior of the -force is that any existing configuration on the cluster
will be replaced with the configuration provided in the import command.
> Import and export should be supported with full cluster running
> ---
>
> Key: GEODE-5053
> URL: https://issues.apache.org/jira/browse/GEODE-5053
> Project: Geode
> Issue Type: Improvement
> Components: docs, gfsh, management
>Affects Versions: 1.4.0, 1.5.0
>Reporter: Pulkit Chandra
>Priority: Major
>
> We want to provide support to export /import config and data. We dont have
> the ability to just run locators and not servers as we use BOSH to manage
> Geode, which is required for `import` today
> **Why** : As a operator if data contained in Geode is important, I would like
> to ensure I can back it up. Use cases range from ensuring your data doesnt
> get lost to migrating your data to another cluster.
> **How**: `Import` and `export` command should be the way to go
> **Limitations**: Cant have locators running and servers not running. Full
> cluster would be running before import is called. We can do rolling restart,
> if that is needed.
>
> its related to the issue https://issues.apache.org/jira/browse/GEODE-4893
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5053) Import and export should be supported with full cluster running
[
https://issues.apache.org/jira/browse/GEODE-5053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16436297#comment-16436297
]
Barbara Pruijn commented on GEODE-5053:
---
Since there is a use case where specific configuration gets added to the
cluster before
{code:java}
import cluster-configuration{code}
is called, we need to have the option to wipe out any existing configuration
when importing a preferred configuration.
The proposal is to add the option -force:
{code:java}
import cluster-configuration --force{code}
The behavior of the -force is that any existing configuration on the cluster
will be replaced with the configuration provided in the import command.
> Import and export should be supported with full cluster running
> ---
>
> Key: GEODE-5053
> URL: https://issues.apache.org/jira/browse/GEODE-5053
> Project: Geode
> Issue Type: Improvement
> Components: gfsh, management
>Affects Versions: 1.4.0, 1.5.0
>Reporter: Pulkit Chandra
>Priority: Major
>
> We want to provide support to export /import config and data. We dont have
> the ability to just run locators and not servers as we use BOSH to manage
> Geode, which is required for `import` today
> **Why** : As a operator if data contained in Geode is important, I would like
> to ensure I can back it up. Use cases range from ensuring your data doesnt
> get lost to migrating your data to another cluster.
> **How**: `Import` and `export` command should be the way to go
> **Limitations**: Cant have locators running and servers not running. Full
> cluster would be running before import is called. We can do rolling restart,
> if that is needed.
>
> its related to the issue https://issues.apache.org/jira/browse/GEODE-4893
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-4787) Re-instate Management REST API endpoints for 'create index' and 'create region'
[
https://issues.apache.org/jira/browse/GEODE-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn updated GEODE-4787:
--
Fix Version/s: 1.5.0
> Re-instate Management REST API endpoints for 'create index' and 'create
> region'
> ---
>
> Key: GEODE-4787
> URL: https://issues.apache.org/jira/browse/GEODE-4787
> Project: Geode
> Issue Type: Bug
> Components: management
>Affects Versions: 1.3.0, 1.4.0
>Reporter: John Blum
>Priority: Blocker
> Labels: pull-request-available
> Fix For: 1.5.0
>
> Attachments: ClusterConfigurationExampleIntegrationTests.java,
> Customer.java, CustomerRepository.java
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> As of _Apache Geode_ *1.3*, Apache Geode no longer supports proper
> (REST-like) Web service endpoints for the Geode's Management functionality.
> This primarily concerns the Management (REST-like) Web service API in
> {{org.apache.geode.management.internal.web.controllers}}, which in Apache
> Geode 1.2.1 and earlier, consisted of the following [Spring Web MVC
> Cntrollers|https://github.com/apache/geode/tree/rel/v1.2.1/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers].
> However, as Apache Geode 1.3 and later (i.e. 1.4 and beyond), the Apache
> Geode community refactored and [reduced the
> Controllers|https://github.com/apache/geode/tree/rel/v1.3.0/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers],
> and by extension, the Web service endpoints to, mostly, a [single Web
> service
> endpoint|https://github.com/apache/geode/blob/rel/v1.3.0/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/ShellCommandsController.java#L72-L79],
> which essentially just accepts a _Gfsh_ command string, such as `{{create
> region --name=Example --type=PARTITION}}`.
> This is an significant *anti-pattern* to be sure nor is it consistent with
> good/proper Web service/general API design, much less REST-ful design.
> While this Management REST-like API was not a "complete" REST API design, as
> measured against [Richardson Maturity
> Model|https://martinfowler.com/articles/richardsonMaturityModel.html], it did
> consist of elements in both Levels 1 and 2.
> For instance, it used proper URLs and URIs to identify and access resources
> (e.g. Regions, Indexes, etc). Additionally, it also used property Verbs to
> affect (e.g. CRUD) the resources.
> Essentially, it only needed proper Resource abstractions representing the
> different resources (e.g. Regions, Indexes, etc) along with Hypermedia
> Controls to move beyond being a specific interface for _Gfsh_.
> The intent was never to make the Management REST API a specific extension for
> _Gfsh_. The initial purpose was to enable _Gfsh_ to connect to the Manager
> via HTTP in order to transcend firewalls when a devops team wanted to manage
> a remote cluster deployed in a cloud environment, such as AWS or GCP. By
> using HTTP over JMX/RMI, a user would not need to punch additional holes in
> the firewall to expose the JMX/RMI port (1099) for instance.
> Still, the "intent" was never to stop at supporting just _Gfsh_, but to
> become a true REST API that can be consumed by any client (not just _Gfsh_):
> application, framework, tool, etc, regardless of language (e.g. Java, C++/C#,
> Ruby, Python, etc).
> However, the team that modified this API failed to recognize the benefit of
> this design and actually took a step backwards. The HTTP Verbs are not
> properly used. The Web service API endpoints are not resourceful, and
> imposing the _Gfsh_ DSL on clients is foolish and too restrictive.
> While, it might be argued that this was an "internal" API, technically,
> speaking, guarding classes by putting them in an "internal" package is no
> safe-guard or guarantee that could have been properly enforced using Java
> access modifiers (e.g. {{private}}, {{package-protected}}, etc) and then only
> exposing an SPI for consumption.
> The fact remains that this API was changed in an incompatible way before an
> "alternative" solution was properly introduced.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-4787) Re-instate Management REST API endpoints for 'create index' and 'create region'
[
https://issues.apache.org/jira/browse/GEODE-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn resolved GEODE-4787.
---
Resolution: Fixed
> Re-instate Management REST API endpoints for 'create index' and 'create
> region'
> ---
>
> Key: GEODE-4787
> URL: https://issues.apache.org/jira/browse/GEODE-4787
> Project: Geode
> Issue Type: Bug
> Components: management
>Affects Versions: 1.3.0, 1.4.0
>Reporter: John Blum
>Priority: Blocker
> Labels: pull-request-available
> Fix For: 1.5.0
>
> Attachments: ClusterConfigurationExampleIntegrationTests.java,
> Customer.java, CustomerRepository.java
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> As of _Apache Geode_ *1.3*, Apache Geode no longer supports proper
> (REST-like) Web service endpoints for the Geode's Management functionality.
> This primarily concerns the Management (REST-like) Web service API in
> {{org.apache.geode.management.internal.web.controllers}}, which in Apache
> Geode 1.2.1 and earlier, consisted of the following [Spring Web MVC
> Cntrollers|https://github.com/apache/geode/tree/rel/v1.2.1/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers].
> However, as Apache Geode 1.3 and later (i.e. 1.4 and beyond), the Apache
> Geode community refactored and [reduced the
> Controllers|https://github.com/apache/geode/tree/rel/v1.3.0/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers],
> and by extension, the Web service endpoints to, mostly, a [single Web
> service
> endpoint|https://github.com/apache/geode/blob/rel/v1.3.0/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/ShellCommandsController.java#L72-L79],
> which essentially just accepts a _Gfsh_ command string, such as `{{create
> region --name=Example --type=PARTITION}}`.
> This is an significant *anti-pattern* to be sure nor is it consistent with
> good/proper Web service/general API design, much less REST-ful design.
> While this Management REST-like API was not a "complete" REST API design, as
> measured against [Richardson Maturity
> Model|https://martinfowler.com/articles/richardsonMaturityModel.html], it did
> consist of elements in both Levels 1 and 2.
> For instance, it used proper URLs and URIs to identify and access resources
> (e.g. Regions, Indexes, etc). Additionally, it also used property Verbs to
> affect (e.g. CRUD) the resources.
> Essentially, it only needed proper Resource abstractions representing the
> different resources (e.g. Regions, Indexes, etc) along with Hypermedia
> Controls to move beyond being a specific interface for _Gfsh_.
> The intent was never to make the Management REST API a specific extension for
> _Gfsh_. The initial purpose was to enable _Gfsh_ to connect to the Manager
> via HTTP in order to transcend firewalls when a devops team wanted to manage
> a remote cluster deployed in a cloud environment, such as AWS or GCP. By
> using HTTP over JMX/RMI, a user would not need to punch additional holes in
> the firewall to expose the JMX/RMI port (1099) for instance.
> Still, the "intent" was never to stop at supporting just _Gfsh_, but to
> become a true REST API that can be consumed by any client (not just _Gfsh_):
> application, framework, tool, etc, regardless of language (e.g. Java, C++/C#,
> Ruby, Python, etc).
> However, the team that modified this API failed to recognize the benefit of
> this design and actually took a step backwards. The HTTP Verbs are not
> properly used. The Web service API endpoints are not resourceful, and
> imposing the _Gfsh_ DSL on clients is foolish and too restrictive.
> While, it might be argued that this was an "internal" API, technically,
> speaking, guarding classes by putting them in an "internal" package is no
> safe-guard or guarantee that could have been properly enforced using Java
> access modifiers (e.g. {{private}}, {{package-protected}}, etc) and then only
> exposing an SPI for consumption.
> The fact remains that this API was changed in an incompatible way before an
> "alternative" solution was properly introduced.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5053) Import and export should be supported with full cluster running
[ https://issues.apache.org/jira/browse/GEODE-5053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16436040#comment-16436040 ] Barbara Pruijn commented on GEODE-5053: --- [~pchandra] Here is the flow: if you start a cluster with brand new locators and servers (with no configuration on them), you can import the cluster configuration when the full cluster is up and running (locators and servers are running). If the locators already have configuration and/or the servers have configuration, the import command will fail. Once you have imported the configuration on the running cluster, then you can import the data. If the data that you import does not match the configuration, this command will fail. (e.g. load data in a region that is not defined in the configuration). In the above scenario, you can import cluster config on running servers. But if there is any configuration on any server or locator, you cannot import the configuration. https://issues.apache.org/jira/browse/GEODE-4893 fixed a bug related to this and should be released in geode 1.6.0. > Import and export should be supported with full cluster running > --- > > Key: GEODE-5053 > URL: https://issues.apache.org/jira/browse/GEODE-5053 > Project: Geode > Issue Type: Improvement > Components: gfsh, management >Affects Versions: 1.4.0, 1.5.0 >Reporter: Pulkit Chandra >Priority: Major > > We want to provide support to export /import config and data. We dont have > the ability to just run locators and not servers as we use BOSH to manage > Geode, which is required for `import` today > **Why** : As a operator if data contained in Geode is important, I would like > to ensure I can back it up. Use cases range from ensuring your data doesnt > get lost to migrating your data to another cluster. > **How**: `Import` and `export` command should be the way to go > **Limitations**: Cant have locators running and servers not running. Full > cluster would be running before import is called. We can do rolling restart, > if that is needed. > > its related to the issue https://issues.apache.org/jira/browse/GEODE-4893 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-3237) Loading cluster configuration from a dir that does not have complete CC will throw NPE
[
https://issues.apache.org/jira/browse/GEODE-3237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn resolved GEODE-3237.
---
Resolution: Fixed
> Loading cluster configuration from a dir that does not have complete CC will
> throw NPE
> --
>
> Key: GEODE-3237
> URL: https://issues.apache.org/jira/browse/GEODE-3237
> Project: Geode
> Issue Type: Bug
> Components: configuration, gfsh
>Reporter: Jinmei Liao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.6.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> We should handle the error more gracefully and informatively. Currently if
> user did the following:
> gfsh> start locator --name=locator
> gfsh> shutdown --include-lcoator=true
> gfsh> start locator --name=locator --load-cluster-configuration-from-dir=true
> the console message says "Cluster configuration service has been started, but
> its not running yet",
> and there is an NPE in the log:
> [error 2017/07/18 10:22:38.357 PDT locator
> tid=0x41] null
> java.lang.NullPointerException
> at
> org.apache.geode.distributed.internal.ClusterConfigurationService.loadSharedConfigurationFromDisk(ClusterConfigurationService.java:618)
> at
> org.apache.geode.distributed.internal.ClusterConfigurationService.initSharedConfiguration(ClusterConfigurationService.java:441)
> at
> org.apache.geode.distributed.internal.InternalLocator$SharedConfigurationRunnable.run(InternalLocator.java:613)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at
> org.apache.geode.distributed.internal.DistributionManager.runUntilShutdown(DistributionManager.java:665)
> at
> org.apache.geode.distributed.internal.DistributionManager$4$1.run(DistributionManager.java:922)
> at java.lang.Thread.run(Thread.java:745)
> The error message if no directory is specified, should be saying:
> {code:java}
> The option load-cluster-configuration-from-dir=true is specified but the
> option -cluster-config-dir needs to be set with a directory to the cluster
> config file.{code}
> The error message if the directory is specified but cluster config file is
> not found in that directory:
> {code:java}
> No cluster configuration is found in {code}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-4218) load-cluster-configuration-from-dir is no longer required when setting --cluster-config-dir
[ https://issues.apache.org/jira/browse/GEODE-4218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barbara Pruijn reassigned GEODE-4218: - Assignee: Joey McAllister > load-cluster-configuration-from-dir is no longer required when setting > --cluster-config-dir > --- > > Key: GEODE-4218 > URL: https://issues.apache.org/jira/browse/GEODE-4218 > Project: Geode > Issue Type: Improvement > Components: configuration, docs, management >Reporter: Jinmei Liao >Assignee: Joey McAllister >Priority: Major > Fix For: 1.6.0 > > > Currently if you start a locator with: > load-cluster-configuration-from-dir=true > you would usually need to specify a "cluster-configuration-dir" to go with > it, if you don't, it will default to the locator's working dir which is > usually empty, and when this happens, it will override the entire cluster's > configuration to be empty. > We have deprecated this option. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-3237) Loading cluster configuration from a dir that does not have complete CC will throw NPE
[
https://issues.apache.org/jira/browse/GEODE-3237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn reassigned GEODE-3237:
-
Assignee: (was: Joey McAllister)
> Loading cluster configuration from a dir that does not have complete CC will
> throw NPE
> --
>
> Key: GEODE-3237
> URL: https://issues.apache.org/jira/browse/GEODE-3237
> Project: Geode
> Issue Type: Bug
> Components: configuration, gfsh
>Reporter: Jinmei Liao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.6.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> We should handle the error more gracefully and informatively. Currently if
> user did the following:
> gfsh> start locator --name=locator
> gfsh> shutdown --include-lcoator=true
> gfsh> start locator --name=locator --load-cluster-configuration-from-dir=true
> the console message says "Cluster configuration service has been started, but
> its not running yet",
> and there is an NPE in the log:
> [error 2017/07/18 10:22:38.357 PDT locator
> tid=0x41] null
> java.lang.NullPointerException
> at
> org.apache.geode.distributed.internal.ClusterConfigurationService.loadSharedConfigurationFromDisk(ClusterConfigurationService.java:618)
> at
> org.apache.geode.distributed.internal.ClusterConfigurationService.initSharedConfiguration(ClusterConfigurationService.java:441)
> at
> org.apache.geode.distributed.internal.InternalLocator$SharedConfigurationRunnable.run(InternalLocator.java:613)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at
> org.apache.geode.distributed.internal.DistributionManager.runUntilShutdown(DistributionManager.java:665)
> at
> org.apache.geode.distributed.internal.DistributionManager$4$1.run(DistributionManager.java:922)
> at java.lang.Thread.run(Thread.java:745)
> The error message if no directory is specified, should be saying:
> {code:java}
> The option load-cluster-configuration-from-dir=true is specified but the
> option -cluster-config-dir needs to be set with a directory to the cluster
> config file.{code}
> The error message if the directory is specified but cluster config file is
> not found in that directory:
> {code:java}
> No cluster configuration is found in {code}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-3237) Loading cluster configuration from a dir that does not have complete CC will throw NPE
[
https://issues.apache.org/jira/browse/GEODE-3237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn reassigned GEODE-3237:
-
Assignee: Joey McAllister
> Loading cluster configuration from a dir that does not have complete CC will
> throw NPE
> --
>
> Key: GEODE-3237
> URL: https://issues.apache.org/jira/browse/GEODE-3237
> Project: Geode
> Issue Type: Bug
> Components: configuration, gfsh
>Reporter: Jinmei Liao
>Assignee: Joey McAllister
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.6.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> We should handle the error more gracefully and informatively. Currently if
> user did the following:
> gfsh> start locator --name=locator
> gfsh> shutdown --include-lcoator=true
> gfsh> start locator --name=locator --load-cluster-configuration-from-dir=true
> the console message says "Cluster configuration service has been started, but
> its not running yet",
> and there is an NPE in the log:
> [error 2017/07/18 10:22:38.357 PDT locator
> tid=0x41] null
> java.lang.NullPointerException
> at
> org.apache.geode.distributed.internal.ClusterConfigurationService.loadSharedConfigurationFromDisk(ClusterConfigurationService.java:618)
> at
> org.apache.geode.distributed.internal.ClusterConfigurationService.initSharedConfiguration(ClusterConfigurationService.java:441)
> at
> org.apache.geode.distributed.internal.InternalLocator$SharedConfigurationRunnable.run(InternalLocator.java:613)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at
> org.apache.geode.distributed.internal.DistributionManager.runUntilShutdown(DistributionManager.java:665)
> at
> org.apache.geode.distributed.internal.DistributionManager$4$1.run(DistributionManager.java:922)
> at java.lang.Thread.run(Thread.java:745)
> The error message if no directory is specified, should be saying:
> {code:java}
> The option load-cluster-configuration-from-dir=true is specified but the
> option -cluster-config-dir needs to be set with a directory to the cluster
> config file.{code}
> The error message if the directory is specified but cluster config file is
> not found in that directory:
> {code:java}
> No cluster configuration is found in {code}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-4218) load-cluster-configuration-from-dir is no longer required when setting --cluster-config-dir
[ https://issues.apache.org/jira/browse/GEODE-4218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barbara Pruijn updated GEODE-4218: -- Fix Version/s: 1.6.0 > load-cluster-configuration-from-dir is no longer required when setting > --cluster-config-dir > --- > > Key: GEODE-4218 > URL: https://issues.apache.org/jira/browse/GEODE-4218 > Project: Geode > Issue Type: Improvement > Components: configuration, docs, management >Reporter: Jinmei Liao >Priority: Major > Fix For: 1.6.0 > > > Currently if you start a locator with: > load-cluster-configuration-from-dir=true > you would usually need to specify a "cluster-configuration-dir" to go with > it, if you don't, it will default to the locator's working dir which is > usually empty, and when this happens, it will override the entire cluster's > configuration to be empty. > We have deprecated this option. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-3237) Loading cluster configuration from a dir that does not have complete CC will throw NPE
[
https://issues.apache.org/jira/browse/GEODE-3237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn updated GEODE-3237:
--
Fix Version/s: 1.6.0
> Loading cluster configuration from a dir that does not have complete CC will
> throw NPE
> --
>
> Key: GEODE-3237
> URL: https://issues.apache.org/jira/browse/GEODE-3237
> Project: Geode
> Issue Type: Bug
> Components: configuration, gfsh
>Reporter: Jinmei Liao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.6.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> We should handle the error more gracefully and informatively. Currently if
> user did the following:
> gfsh> start locator --name=locator
> gfsh> shutdown --include-lcoator=true
> gfsh> start locator --name=locator --load-cluster-configuration-from-dir=true
> the console message says "Cluster configuration service has been started, but
> its not running yet",
> and there is an NPE in the log:
> [error 2017/07/18 10:22:38.357 PDT locator
> tid=0x41] null
> java.lang.NullPointerException
> at
> org.apache.geode.distributed.internal.ClusterConfigurationService.loadSharedConfigurationFromDisk(ClusterConfigurationService.java:618)
> at
> org.apache.geode.distributed.internal.ClusterConfigurationService.initSharedConfiguration(ClusterConfigurationService.java:441)
> at
> org.apache.geode.distributed.internal.InternalLocator$SharedConfigurationRunnable.run(InternalLocator.java:613)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at
> org.apache.geode.distributed.internal.DistributionManager.runUntilShutdown(DistributionManager.java:665)
> at
> org.apache.geode.distributed.internal.DistributionManager$4$1.run(DistributionManager.java:922)
> at java.lang.Thread.run(Thread.java:745)
> The error message if no directory is specified, should be saying:
> {code:java}
> The option load-cluster-configuration-from-dir=true is specified but the
> option -cluster-config-dir needs to be set with a directory to the cluster
> config file.{code}
> The error message if the directory is specified but cluster config file is
> not found in that directory:
> {code:java}
> No cluster configuration is found in {code}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-4218) load-cluster-configuration-from-dir is no longer required when setting --cluster-config-dir
[ https://issues.apache.org/jira/browse/GEODE-4218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barbara Pruijn updated GEODE-4218: -- Description: Currently if you start a locator with: load-cluster-configuration-from-dir=true you would usually need to specify a "cluster-configuration-dir" to go with it, if you don't, it will default to the locator's working dir which is usually empty, and when this happens, it will override the entire cluster's configuration to be empty. We have deprecated this option. was: Currently if you start a locator with: load-cluster-configuration-from-dir=true you would usually need to specify a "cluster-configuration-dir" to go with it, if you don't, it will default to the locator's working dir which is usually empty, and when this happens, it will override the entire cluster's configuration to be empty. Since we cannot remove the option -load-cluster-configuration-from-dir since this will break backward compatibility for existing customers who are using this, we can make this option optional (not required) when you specify -cluster-config-dir=. Also, we need to return an error if you specify load-cluster-configuration-from-dir=true but don't provide --cluster-config-dir=. See GEODE-3237. > load-cluster-configuration-from-dir is no longer required when setting > --cluster-config-dir > --- > > Key: GEODE-4218 > URL: https://issues.apache.org/jira/browse/GEODE-4218 > Project: Geode > Issue Type: Improvement > Components: configuration, docs, management >Reporter: Jinmei Liao >Priority: Major > Fix For: 1.6.0 > > > Currently if you start a locator with: > load-cluster-configuration-from-dir=true > you would usually need to specify a "cluster-configuration-dir" to go with > it, if you don't, it will default to the locator's working dir which is > usually empty, and when this happens, it will override the entire cluster's > configuration to be empty. > We have deprecated this option. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5001) Update logj4 dependency to better integrate with Spring
[
https://issues.apache.org/jira/browse/GEODE-5001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434603#comment-16434603
]
Barbara Pruijn commented on GEODE-5001:
---
Log4j issues: https://issues.apache.org/jira/browse/LOG4J2-2152
> Update logj4 dependency to better integrate with Spring
> ---
>
> Key: GEODE-5001
> URL: https://issues.apache.org/jira/browse/GEODE-5001
> Project: Geode
> Issue Type: Improvement
> Components: build, logging
>Reporter: Anthony Baker
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The current geode log4j dependency is v2.8.2. Spring (Boot, Data, etc) use
> log4j v2.11.0. This make integration challenging. We should upgrade our
> dependency to match Spring. This will make it easier for our users to write
> geode applications.
> Checking for other updates using
> {noformat}
> gradle dependencyUpdates
> find . -name report.txt | xargs grep -e "\]$" | grep -v "org.apache.geode" |
> tr -s " " | cut -d' ' -f3- | sort | uniq | less
> {noformat}
> show that we have some other libraries that can be updated as well:
> {noformat}
> com.fasterxml.jackson.core:jackson-annotations [2.9.4 -> 2.9.5]
> com.fasterxml.jackson.core:jackson-core [2.9.4 -> 2.9.5]
> com.fasterxml.jackson.core:jackson-databind [2.9.4 -> 2.9.5]
> com.fasterxml.jackson.module:jackson-module-scala_2.10 [2.9.4 -> 2.9.5]
> com.google.guava:guava [24.0-jre -> 24.1-jre]
> com.google.protobuf:protoc [3.5.1 -> 3.5.1-1]
> com.zaxxer:HikariCP [2.7.6 -> 3.0.0]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5000) When initializing a client cache, we don't need to request/apply cluster configuration
[
https://issues.apache.org/jira/browse/GEODE-5000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn updated GEODE-5000:
--
Fix Version/s: 1.6.0
> When initializing a client cache, we don't need to request/apply cluster
> configuration
> --
>
> Key: GEODE-5000
> URL: https://issues.apache.org/jira/browse/GEODE-5000
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Affects Versions: 1.4.0
>Reporter: Jinmei Liao
>Assignee: Jinmei Liao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.6.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The user running a gemfire client doesn't have write access to the local dirs
> in the customer environment, and they get an stack trace in their logs. This
> is caused by a client cache trying to request/apply cluster configuration.
> {noformat}
> [error 2018/02/12 17:52:13.899 EST tid=0x12] Error
> when attempting to deploy JAR files on load.
> java.io.IOException: Unable to write to deploy directory
> at
> org.apache.geode.internal.JarDeployer.verifyWritableDeployDirectory(JarDeployer.java:626)
> at
> org.apache.geode.internal.JarDeployer.loadPreviouslyDeployedJars(JarDeployer.java:74)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1242)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:794)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.createClient(GemFireCacheImpl.java:767)
> at
> org.apache.geode.cache.client.ClientCacheFactory.basicCreate(ClientCacheFactory.java:257)
> at
> org.apache.geode.cache.client.ClientCacheFactory.create(ClientCacheFactory.java:207){noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-4902) Log markers filter some messages pathologically
[
https://issues.apache.org/jira/browse/GEODE-4902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn updated GEODE-4902:
--
Fix Version/s: 1.6.0
> Log markers filter some messages pathologically
> ---
>
> Key: GEODE-4902
> URL: https://issues.apache.org/jira/browse/GEODE-4902
> Project: Geode
> Issue Type: Bug
> Components: docs, logging
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.6.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Many logging calls across all log levels are marked with
> {{o.a.g.internal.logging.log4j.LogMarker}} markers for selective enabling and
> debugging. All these markers have a parent marker {{GEODE_VERBOSE}}.
> However, per the default given in
> {{geode-core/src/main/resources/log4j2.xml}}, this parent marker is set to
> filter log messages.
> Many of these log messages are invoked at the {{info}} level, suggesting an
> expectation that the message would be seen.
> These markers should be refactored to (a) include by default markers that
> commonly or exclusively appear in coarse-grained logging levels, and (b) to
> reorganize the markers' parent/child relationships so that they are not
> blanket-disabled by default. Only those markers attacked to more verbose
> logging should be disabled by default.
> ---
> Additionally, the log classes {{FastLogger}} and {{LogWriterLogger}} are
> themselves slightly pathological. Notably, the former overrides some
> {{isEnabled}} aliases but leaves exposed default many of the root method
> signatures. The latter pathologically includes a reference to itself as a
> field unto itself in the lines:
> {noformat}
> private final ExtendedLoggerWrapper logWrapper;
> // ...
> private LogWriterLogger(final Logger logger, final String connectionName,
> final boolean isSecure) {
> super((AbstractLogger) logger, logger.getName(),
> logger.getMessageFactory());
> this.logWrapper = this;
> // ...
> }
> {noformat}
> These classes could use refactoring in their own right, perhaps as a separate
> child ticket.
> -
> Docs: While only the top-level marker (formerly {{GEMFIRE_VERBOSE}}, now
> {{GEODE_VERBOSE}}) is documented, it may be worth a release note that the
> Log4J2 markers have changed, and anyone be using a custom log4j2.xml after
> discovering these markers will have to update that XML to the new markers.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Reopened] (GEODE-4830) Modify list jndi-binding gfsh command
[
https://issues.apache.org/jira/browse/GEODE-4830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn reopened GEODE-4830:
---
Assignee: Joey McAllister
> Modify list jndi-binding gfsh command
> --
>
> Key: GEODE-4830
> URL: https://issues.apache.org/jira/browse/GEODE-4830
> Project: Geode
> Issue Type: Sub-task
> Components: docs, gfsh
>Reporter: Barbara Pruijn
>Assignee: Joey McAllister
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.6.0
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> The list jndi-binding command currently displays jndi-bindings that are
> active.
> We need to modify the output of this command to list all jndi-bindings that
> are listed in the cluster config and indicate in the output of this command
> whether the binding is active or configured.
> We should update the help text to reflect this change. A suggested help text
> is:
> {code:java}
> List all jndi bindings, active and configured. An active binding is one that
> is bound to the server's jndi context (and also listed in the cluster
> config). A configured binding is one that is listed in the cluster config,
> but is not active.{code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-4830) Modify list jndi-binding gfsh command
[
https://issues.apache.org/jira/browse/GEODE-4830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn resolved GEODE-4830.
---
Resolution: Fixed
> Modify list jndi-binding gfsh command
> --
>
> Key: GEODE-4830
> URL: https://issues.apache.org/jira/browse/GEODE-4830
> Project: Geode
> Issue Type: Sub-task
> Components: docs, gfsh
>Reporter: Barbara Pruijn
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.6.0
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> The list jndi-binding command currently displays jndi-bindings that are
> active.
> We need to modify the output of this command to list all jndi-bindings that
> are listed in the cluster config and indicate in the output of this command
> whether the binding is active or configured.
> We should update the help text to reflect this change. A suggested help text
> is:
> {code:java}
> List all jndi bindings, active and configured. An active binding is one that
> is bound to the server's jndi context (and also listed in the cluster
> config). A configured binding is one that is listed in the cluster config,
> but is not active.{code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-4971) Allow GfshRule to launch a cluster with a different Geode version
[
https://issues.apache.org/jira/browse/GEODE-4971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn resolved GEODE-4971.
---
Resolution: Fixed
> Allow GfshRule to launch a cluster with a different Geode version
> -
>
> Key: GEODE-4971
> URL: https://issues.apache.org/jira/browse/GEODE-4971
> Project: Geode
> Issue Type: Task
> Components: gfsh
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.6.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We should be able to use {{VersionManager}} to start a cluster with an older
> Geode version.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-4950) Improve spotless -- upgrade version
[ https://issues.apache.org/jira/browse/GEODE-4950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barbara Pruijn updated GEODE-4950: -- Fix Version/s: 1.6.0 > Improve spotless -- upgrade version > --- > > Key: GEODE-4950 > URL: https://issues.apache.org/jira/browse/GEODE-4950 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Rhomberg >Assignee: Patrick Rhomberg >Priority: Major > Fix For: 1.6.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-4950) Improve spotless -- upgrade version
[ https://issues.apache.org/jira/browse/GEODE-4950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barbara Pruijn resolved GEODE-4950. --- Resolution: Fixed > Improve spotless -- upgrade version > --- > > Key: GEODE-4950 > URL: https://issues.apache.org/jira/browse/GEODE-4950 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Rhomberg >Assignee: Patrick Rhomberg >Priority: Major > Fix For: 1.6.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4971) Allow GfshRule to launch a cluster with a different Geode version
[
https://issues.apache.org/jira/browse/GEODE-4971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn updated GEODE-4971:
--
Fix Version/s: 1.6.0
> Allow GfshRule to launch a cluster with a different Geode version
> -
>
> Key: GEODE-4971
> URL: https://issues.apache.org/jira/browse/GEODE-4971
> Project: Geode
> Issue Type: Task
> Components: gfsh
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.6.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We should be able to use {{VersionManager}} to start a cluster with an older
> Geode version.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-4951) Improve spotless -- Improve runtime with bump method
[ https://issues.apache.org/jira/browse/GEODE-4951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barbara Pruijn resolved GEODE-4951. --- Resolution: Fixed > Improve spotless -- Improve runtime with bump method > > > Key: GEODE-4951 > URL: https://issues.apache.org/jira/browse/GEODE-4951 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Rhomberg >Assignee: Patrick Rhomberg >Priority: Major > Labels: pull-request-available > Fix For: 1.6.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4951) Improve spotless -- Improve runtime with bump method
[ https://issues.apache.org/jira/browse/GEODE-4951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barbara Pruijn updated GEODE-4951: -- Fix Version/s: 1.6.0 > Improve spotless -- Improve runtime with bump method > > > Key: GEODE-4951 > URL: https://issues.apache.org/jira/browse/GEODE-4951 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Rhomberg >Assignee: Patrick Rhomberg >Priority: Major > Labels: pull-request-available > Fix For: 1.6.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4972) Move VersionManager into geode-old-versions module
[ https://issues.apache.org/jira/browse/GEODE-4972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barbara Pruijn updated GEODE-4972: -- Fix Version/s: 1.6.0 > Move VersionManager into geode-old-versions module > -- > > Key: GEODE-4972 > URL: https://issues.apache.org/jira/browse/GEODE-4972 > Project: Geode > Issue Type: Task > Components: tests >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > Fix For: 1.6.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > This is a precursor to GEODE-4971 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-4972) Move VersionManager into geode-old-versions module
[ https://issues.apache.org/jira/browse/GEODE-4972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barbara Pruijn resolved GEODE-4972. --- Resolution: Fixed > Move VersionManager into geode-old-versions module > -- > > Key: GEODE-4972 > URL: https://issues.apache.org/jira/browse/GEODE-4972 > Project: Geode > Issue Type: Task > Components: tests >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > Fix For: 1.6.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > This is a precursor to GEODE-4971 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-5005) Add unit tests for InfoResultData
[ https://issues.apache.org/jira/browse/GEODE-5005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barbara Pruijn resolved GEODE-5005. --- Resolution: Fixed > Add unit tests for InfoResultData > - > > Key: GEODE-5005 > URL: https://issues.apache.org/jira/browse/GEODE-5005 > Project: Geode > Issue Type: Sub-task > Components: gfsh >Reporter: Jens Deppe >Priority: Major > Labels: pull-request-available > Fix For: 1.6.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5005) Add unit tests for InfoResultData
[ https://issues.apache.org/jira/browse/GEODE-5005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barbara Pruijn updated GEODE-5005: -- Fix Version/s: 1.6.0 > Add unit tests for InfoResultData > - > > Key: GEODE-5005 > URL: https://issues.apache.org/jira/browse/GEODE-5005 > Project: Geode > Issue Type: Sub-task > Components: gfsh >Reporter: Jens Deppe >Priority: Major > Labels: pull-request-available > Fix For: 1.6.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5004) Add unit tests for ErrorResultData
[ https://issues.apache.org/jira/browse/GEODE-5004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barbara Pruijn updated GEODE-5004: -- Fix Version/s: 1.6.0 > Add unit tests for ErrorResultData > -- > > Key: GEODE-5004 > URL: https://issues.apache.org/jira/browse/GEODE-5004 > Project: Geode > Issue Type: Sub-task > Components: gfsh >Reporter: Jens Deppe >Priority: Major > Labels: pull-request-available > Fix For: 1.6.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
