[jira] [Updated] (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 ] ASF GitHub Bot updated GEODE-5051: -- Labels: pull-request-available (was: ) > 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 > > 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] [Resolved] (GEODE-5049) Add Geode Image To https://www.apache.org/img/
[ https://issues.apache.org/jira/browse/GEODE-5049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joey McAllister resolved GEODE-5049. Resolution: Fixed > Add Geode Image To https://www.apache.org/img/ > -- > > Key: GEODE-5049 > URL: https://issues.apache.org/jira/browse/GEODE-5049 > Project: Geode > Issue Type: Task > Components: website >Reporter: Mark Bretl >Assignee: Joey McAllister >Priority: Major > Attachments: geode.jpg > > > As part of the Apache Website check > ([https://whimsy.apache.org/site/check/),] the Geode image is missing from > [https://www.apache.org/img/] and causing the image check to be 'red'. > Task is to add a Geode image to [https://www.apache.org/img/], with the name > geode.jpg. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5049) Add Geode Image To https://www.apache.org/img/
[ https://issues.apache.org/jira/browse/GEODE-5049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434771#comment-16434771 ] Joey McAllister commented on GEODE-5049: [~amb] pointed me to [http://www.apache.org/dev/infra-site.html]. The Geode logo should appear at apache.org/img/ the next time staging pushes to production. > Add Geode Image To https://www.apache.org/img/ > -- > > Key: GEODE-5049 > URL: https://issues.apache.org/jira/browse/GEODE-5049 > Project: Geode > Issue Type: Task > Components: website >Reporter: Mark Bretl >Assignee: Joey McAllister >Priority: Major > Attachments: geode.jpg > > > As part of the Apache Website check > ([https://whimsy.apache.org/site/check/),] the Geode image is missing from > [https://www.apache.org/img/] and causing the image check to be 'red'. > Task is to add a Geode image to [https://www.apache.org/img/], with the name > geode.jpg. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-5049) Add Geode Image To https://www.apache.org/img/
[ https://issues.apache.org/jira/browse/GEODE-5049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joey McAllister reassigned GEODE-5049: -- Assignee: Joey McAllister > Add Geode Image To https://www.apache.org/img/ > -- > > Key: GEODE-5049 > URL: https://issues.apache.org/jira/browse/GEODE-5049 > Project: Geode > Issue Type: Task > Components: website >Reporter: Mark Bretl >Assignee: Joey McAllister >Priority: Major > Attachments: geode.jpg > > > As part of the Apache Website check > ([https://whimsy.apache.org/site/check/),] the Geode image is missing from > [https://www.apache.org/img/] and causing the image check to be 'red'. > Task is to add a Geode image to [https://www.apache.org/img/], with the name > geode.jpg. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5049) Add Geode Image To https://www.apache.org/img/
[ https://issues.apache.org/jira/browse/GEODE-5049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434731#comment-16434731 ] Joey McAllister commented on GEODE-5049: [~mbretl]: Do you know how to upload this to apache.org/img/? Is that a task for Infra? > Add Geode Image To https://www.apache.org/img/ > -- > > Key: GEODE-5049 > URL: https://issues.apache.org/jira/browse/GEODE-5049 > Project: Geode > Issue Type: Task > Components: website >Reporter: Mark Bretl >Priority: Major > Attachments: geode.jpg > > > As part of the Apache Website check > ([https://whimsy.apache.org/site/check/),] the Geode image is missing from > [https://www.apache.org/img/] and causing the image check to be 'red'. > Task is to add a Geode image to [https://www.apache.org/img/], with the name > geode.jpg. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5049) Add Geode Image To https://www.apache.org/img/
[ https://issues.apache.org/jira/browse/GEODE-5049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joey McAllister updated GEODE-5049: --- Attachment: geode.jpg > Add Geode Image To https://www.apache.org/img/ > -- > > Key: GEODE-5049 > URL: https://issues.apache.org/jira/browse/GEODE-5049 > Project: Geode > Issue Type: Task > Components: website >Reporter: Mark Bretl >Priority: Major > Attachments: geode.jpg > > > As part of the Apache Website check > ([https://whimsy.apache.org/site/check/),] the Geode image is missing from > [https://www.apache.org/img/] and causing the image check to be 'red'. > Task is to add a Geode image to [https://www.apache.org/img/], with the name > geode.jpg. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5049) Add Geode Image To https://www.apache.org/img/
[ https://issues.apache.org/jira/browse/GEODE-5049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434708#comment-16434708 ] Joey McAllister commented on GEODE-5049: Here's a 212x212 jpg that should work. !geode.jpg! > Add Geode Image To https://www.apache.org/img/ > -- > > Key: GEODE-5049 > URL: https://issues.apache.org/jira/browse/GEODE-5049 > Project: Geode > Issue Type: Task > Components: website >Reporter: Mark Bretl >Priority: Major > Attachments: geode.jpg > > > As part of the Apache Website check > ([https://whimsy.apache.org/site/check/),] the Geode image is missing from > [https://www.apache.org/img/] and causing the image check to be 'red'. > Task is to add a Geode image to [https://www.apache.org/img/], with the name > geode.jpg. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (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 ] Karen Smoler Miller updated GEODE-5051: --- Description: 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 was: 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 > 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 > > 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+ >
[jira] [Created] (GEODE-5051) Improve gfsh destroy jndi-binding help prose
Karen Smoler Miller created GEODE-5051: -- Summary: 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 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] [Commented] (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:comment-tabpanel=16434702#comment-16434702 ] Sai Boorlagadda commented on GEODE-5048: Is this duplicate of GEODE-4897? > 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 > > 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-5050) distribute() of RemoteDestroyMessage, RemoteInvalidateMessage and RemotePutMessage does not handle the local region destroy
[ https://issues.apache.org/jira/browse/GEODE-5050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-5050: - Affects Version/s: 1.6.0 > distribute() of RemoteDestroyMessage, RemoteInvalidateMessage and > RemotePutMessage does not handle the local region destroy > --- > > Key: GEODE-5050 > URL: https://issues.apache.org/jira/browse/GEODE-5050 > Project: Geode > Issue Type: Bug > Components: regions >Affects Versions: 1.6.0 >Reporter: Anilkumar Gingade >Priority: Major > > distribute() of RemoteDestroyMessage, RemoteInvalidateMessage and > RemotePutMessage does not handle the local region destroy. > When local region is destroyed, they keep sending the message to other > recipients in the loop instead of handling local region destroy. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-5050) distribute() of RemoteDestroyMessage, RemoteInvalidateMessage and RemotePutMessage does not handle the local region destroy
Anilkumar Gingade created GEODE-5050: Summary: distribute() of RemoteDestroyMessage, RemoteInvalidateMessage and RemotePutMessage does not handle the local region destroy Key: GEODE-5050 URL: https://issues.apache.org/jira/browse/GEODE-5050 Project: Geode Issue Type: Bug Components: regions Reporter: Anilkumar Gingade distribute() of RemoteDestroyMessage, RemoteInvalidateMessage and RemotePutMessage does not handle the local region destroy. When local region is destroyed, they keep sending the message to other recipients in the loop instead of handling local region destroy. -- 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] [Created] (GEODE-5049) Add Geode Image To https://www.apache.org/img/
Mark Bretl created GEODE-5049: - Summary: Add Geode Image To https://www.apache.org/img/ Key: GEODE-5049 URL: https://issues.apache.org/jira/browse/GEODE-5049 Project: Geode Issue Type: Task Components: website Reporter: Mark Bretl As part of the Apache Website check ([https://whimsy.apache.org/site/check/),] the Geode image is missing from [https://www.apache.org/img/] and causing the image check to be 'red'. Task is to add a Geode image to [https://www.apache.org/img/], with the name geode.jpg. -- 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] [Commented] (GEODE-5045) Boost Fails to Build on Windows with Multiple Visual Studio Versions Installed
[ https://issues.apache.org/jira/browse/GEODE-5045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434597#comment-16434597 ] ASF subversion and git services commented on GEODE-5045: Commit 3b274ff333d4e90897600e45784ec9da01fb41a7 in geode-native's branch refs/heads/develop from [~mmartell] [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=3b274ff ] GEODE-5045: Add toolset flag to Boost build on Windows (#269) > Boost Fails to Build on Windows with Multiple Visual Studio Versions Installed > -- > > Key: GEODE-5045 > URL: https://issues.apache.org/jira/browse/GEODE-5045 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Michael Martell >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > If you try to build native client on Windows with multiple versions of Visual > Studio installed, you may fail to build the Boost library. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4637) Geode Native uses GEODE rather than GEODE_HOME
[
https://issues.apache.org/jira/browse/GEODE-4637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434596#comment-16434596
]
ASF subversion and git services commented on GEODE-4637:
Commit c030242c198f16bb2aee9781240a603ec55fbef2 in geode-native's branch
refs/heads/develop from [~mmartell]
[ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=c030242 ]
GEODE-4637: Allow only GEODE_HOME, remove GEODE (#268)
* Updated build instructions and find module to allow GEODE_HOME as env var and
GEODE_ROOT cmake var
> Geode Native uses GEODE rather than GEODE_HOME
> --
>
> Key: GEODE-4637
> URL: https://issues.apache.org/jira/browse/GEODE-4637
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Addison
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> The java side of things uses {{GEODE_HOME}} environment variable to point to
> the Geode install directory containing the /bin.
> [https://github.com/apache/geode-examples/blob/5b413a34e30790a6631332cfa1f4b485a487abcb/build.gradle]
> Geode Native uses the environment variable GEODE.
> [https://github.com/apache/geode-native/blob/develop/BUILDING.md]
> This is confusing. It would be best if we standardize on {{GEODE_HOME}}.
>
> This does not mean changing the FindGeode.cmake module's {{GEODE_ROOT}}
> configuration variable. The only change should be in which environment
> variable is used to search for Geode if the {{GEODE_ROOT}} is not explicitly
> set.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5039) EvictionAttributesMutator.setMaximum does not work
[ https://issues.apache.org/jira/browse/GEODE-5039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fred Krone updated GEODE-5039: -- Description: EvictionAttributesMutator.setMaximum does not change the lru count. Given I am configuring eviction When setting EvictionAttributesMutator.setMaximum Then the lru count should update accordingly was:EvictionAttributesMutator.setMaximum does not change the lru count. > EvictionAttributesMutator.setMaximum does not work > -- > > Key: GEODE-5039 > URL: https://issues.apache.org/jira/browse/GEODE-5039 > Project: Geode > Issue Type: Bug > Components: eviction >Affects Versions: 1.5.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > EvictionAttributesMutator.setMaximum does not change the lru count. > > Given I am configuring eviction > When setting EvictionAttributesMutator.setMaximum > Then the lru count should update accordingly -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (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:comment-tabpanel=16434489#comment-16434489
]
ASF subversion and git services commented on GEODE-3237:
Commit 8ca39e93f2d4ef6503e3b52a68fb193bc5c3e6ac in geode's branch
refs/heads/develop from [~sai.boorlaga...@gmail.com]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=8ca39e9 ]
GEODE-3237: Loading cluster configuration from a dir that does not ha… (#1746)
command option --load-cluster-config-from-dir is deprecated and a warning
is added to the gfsh command output in case if its used.
> 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
> 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-5046) RemotePutMessage.distribute should handle RegionDestoryedException
[ https://issues.apache.org/jira/browse/GEODE-5046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-5046: -- Labels: pull-request-available (was: ) > RemotePutMessage.distribute should handle RegionDestoryedException > -- > > Key: GEODE-5046 > URL: https://issues.apache.org/jira/browse/GEODE-5046 > Project: Geode > Issue Type: Bug > Components: regions >Affects Versions: 1.5.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: pull-request-available > > RemotePutMessage.distribute() tries to get a version tag from a remote member > in a loop. It tries another member if one member failed. > It is possible that a region is destroyed on a member, and the method should > handle it and retry to another member instead of failing the operation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5046) RemotePutMessage.distribute should handle RegionDestoryedException
[ https://issues.apache.org/jira/browse/GEODE-5046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434432#comment-16434432 ] ASF subversion and git services commented on GEODE-5046: Commit c971fec127ae5d116766c6e6214f568d2b55fb13 in geode's branch refs/heads/feature/GEODE-5046 from [~eshu] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=c971fec ] GEODE-5046: Handle RegionDestroyedException in RemotePutMessage to retry another member. > RemotePutMessage.distribute should handle RegionDestoryedException > -- > > Key: GEODE-5046 > URL: https://issues.apache.org/jira/browse/GEODE-5046 > Project: Geode > Issue Type: Bug > Components: regions >Affects Versions: 1.5.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > > RemotePutMessage.distribute() tries to get a version tag from a remote member > in a loop. It tries another member if one member failed. > It is possible that a region is destroyed on a member, and the method should > handle it and retry to another member instead of failing the operation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-3993) Re-evaluate the Cache.createDataInput/Output API
[ https://issues.apache.org/jira/browse/GEODE-3993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Oleske resolved GEODE-3993. --- Resolution: Fixed > Re-evaluate the Cache.createDataInput/Output API > > > Key: GEODE-3993 > URL: https://issues.apache.org/jira/browse/GEODE-3993 > Project: Geode > Issue Type: Task > Components: native client >Reporter: Jacob S. Barrett >Assignee: Blake Bender >Priority: Major > > Having the factory on Cache is convenient for end users but produces > DataInput/Output objects that are not usable for internal use because it > relies on access to the Pool. If a User's use of the DataInput/Output also > needs Pool then it will be broken. Internally we turn around and call an > internal API to add the Pool to the DataInput/Output. This all seems really > dirty, can we do better? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4908) Environment variable $GFCPP is still used
[ https://issues.apache.org/jira/browse/GEODE-4908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-4908: -- Labels: pull-request-available (was: ) > Environment variable $GFCPP is still used > - > > Key: GEODE-4908 > URL: https://issues.apache.org/jira/browse/GEODE-4908 > Project: Geode > Issue Type: Task > Components: docs, native client >Reporter: Ryan McMahon >Assignee: Michael Oleske >Priority: Major > Labels: pull-request-available > > We need to change $GFCPP to $GEODE_NATIVE or something without reference to > GemFire (GF) since it is now part of Apache Geode Native. This will also > include changing references in the doc from $GFCPP to $GEODE_NATIVE. > **Specifically "Installing the Native Client" section and possibly others > (search GFCPP). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4245) Support for Tombstone GC setting at region level
[ https://issues.apache.org/jira/browse/GEODE-4245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fred Krone updated GEODE-4245: -- Component/s: docs > Support for Tombstone GC setting at region level > > > Key: GEODE-4245 > URL: https://issues.apache.org/jira/browse/GEODE-4245 > Project: Geode > Issue Type: Improvement > Components: docs, regions >Reporter: Fred Krone >Priority: Major > > The Tombstone GC setting is at cache level. Which is applied across all the > regions in the cache. > Having these at region gives a better control on managing Tombstone in the > system. They can be configured based on their usage and consistency > requirement. > Also, Tombstone GC settings are time based (default 10minutes). Adding > Tombstone GC configuration based on number of tombstones will also help > managing tombstones and its impact on memory. > The proposal is to: > # Have Tombstone GC setting at region level. > # Add count based Tombstone GC setting. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-4708) Users need the ability to tune tombstone GC on a per region basis
[ https://issues.apache.org/jira/browse/GEODE-4708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fred Krone resolved GEODE-4708. --- Resolution: Duplicate Same as https://issues.apache.org/jira/browse/GEODE-4245 > Users need the ability to tune tombstone GC on a per region basis > - > > Key: GEODE-4708 > URL: https://issues.apache.org/jira/browse/GEODE-4708 > Project: Geode > Issue Type: Improvement > Components: docs, regions >Reporter: Fred Krone >Priority: Major > > We need to reduce memory requirements for a Lucene index. > > Most of the extra memory is consumed by tombstones created by Apache Lucene > generating many temporary 'files' (up to 10 per entry). > > We need a way to provide accelerated GC for these tombstones. It has been > suggested that, rather than doing something specific for Lucene, a more > general solution is to add the ability to tune GC on a per region basis. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4245) Support for Tombstone GC setting at region level
[ https://issues.apache.org/jira/browse/GEODE-4245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fred Krone updated GEODE-4245: -- Labels: (was: geode-150) > Support for Tombstone GC setting at region level > > > Key: GEODE-4245 > URL: https://issues.apache.org/jira/browse/GEODE-4245 > Project: Geode > Issue Type: Improvement > Components: docs, regions >Reporter: Fred Krone >Priority: Major > > The Tombstone GC setting is at cache level. Which is applied across all the > regions in the cache. > Having these at region gives a better control on managing Tombstone in the > system. They can be configured based on their usage and consistency > requirement. > Also, Tombstone GC settings are time based (default 10minutes). Adding > Tombstone GC configuration based on number of tombstones will also help > managing tombstones and its impact on memory. > The proposal is to: > # Have Tombstone GC setting at region level. > # Add count based Tombstone GC setting. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-5048) Availability Indicator for "list jndi-bindings", "list jdbc-connections" and "list jdbc-mappings" are wrong
Jinmei Liao created GEODE-5048: -- Summary: 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 Reporter: Jinmei Liao 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-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 ] Jinmei Liao updated GEODE-5048: --- Affects Version/s: 1.4.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 > > 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] [Commented] (GEODE-4909) Add dunit test coverage for lucene reindex with security
[ https://issues.apache.org/jira/browse/GEODE-4909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434111#comment-16434111 ] ASF subversion and git services commented on GEODE-4909: Commit a9c4a0a0115e0f1462276c4cbe509b6b51cc8e41 in geode's branch refs/heads/develop from [~lhughesgodfrey] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=a9c4a0a ] GEODE-4909: Additional lucene reindex tests with security * Extended existing tests with and without gfsh to create region prior to creating lucene index. > Add dunit test coverage for lucene reindex with security > > > Key: GEODE-4909 > URL: https://issues.apache.org/jira/browse/GEODE-4909 > Project: Geode > Issue Type: Test > Components: lucene >Affects Versions: 1.6.0 >Reporter: Shelley Lynn Hughes-Godfrey >Assignee: Shelley Lynn Hughes-Godfrey >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > Add new dunit tests: > - LuceneClientSecurityWithRegionCreatedBeforeReindexDUnitTest > - LuceneCommandSecurityWithRegionCreatedBeforeReindexDUnitTest -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4858) refactor internal commands to use the public ClusterConfigService
[ https://issues.apache.org/jira/browse/GEODE-4858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434051#comment-16434051 ] ASF subversion and git services commented on GEODE-4858: Commit 634cd853356c5b367cb9357b169441a549d3358d in geode's branch refs/heads/develop from [~jinmeiliao] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=634cd85 ] GEODE-4858: pulling JaxbService out of InternalClusterConfigurationSe… (#1754) * GEODE-4858: pulling JaxbService out of InternalClusterConfigurationService * add capability for JaxService to validate with another xsd * cache element use the default namespace "" * add capability for modules to register schema location * use package-info to do namespace mapping > refactor internal commands to use the public ClusterConfigService > - > > Key: GEODE-4858 > URL: https://issues.apache.org/jira/browse/GEODE-4858 > Project: Geode > Issue Type: Sub-task > Components: configuration >Reporter: Jinmei Liao >Priority: Major > Labels: pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > > # except the ones that would need to access the internal cluster > configuration regions, like importClusterConfigCommand, > exportClusterConfigCommand or deploy > # use the configuration object as much as possible to pass parameters to the > functions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4858) refactor internal commands to use the public ClusterConfigService
[ https://issues.apache.org/jira/browse/GEODE-4858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434050#comment-16434050 ] ASF subversion and git services commented on GEODE-4858: Commit 634cd853356c5b367cb9357b169441a549d3358d in geode's branch refs/heads/develop from [~jinmeiliao] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=634cd85 ] GEODE-4858: pulling JaxbService out of InternalClusterConfigurationSe… (#1754) * GEODE-4858: pulling JaxbService out of InternalClusterConfigurationService * add capability for JaxService to validate with another xsd * cache element use the default namespace "" * add capability for modules to register schema location * use package-info to do namespace mapping > refactor internal commands to use the public ClusterConfigService > - > > Key: GEODE-4858 > URL: https://issues.apache.org/jira/browse/GEODE-4858 > Project: Geode > Issue Type: Sub-task > Components: configuration >Reporter: Jinmei Liao >Priority: Major > Labels: pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > > # except the ones that would need to access the internal cluster > configuration regions, like importClusterConfigCommand, > exportClusterConfigCommand or deploy > # use the configuration object as much as possible to pass parameters to the > functions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4828) Gfsh fails to determine status of members not started using ServerLauncher/LocatorLauncher
[ https://issues.apache.org/jira/browse/GEODE-4828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434032#comment-16434032 ] Anthony Baker commented on GEODE-4828: -- I removed the FixVersion for now. Typically we don't set FixVersion unless a) the fix has been committed or b) we want to hold up the next release for an issue. > Gfsh fails to determine status of members not started using > ServerLauncher/LocatorLauncher > -- > > Key: GEODE-4828 > URL: https://issues.apache.org/jira/browse/GEODE-4828 > Project: Geode > Issue Type: Improvement > Components: gfsh >Reporter: Dharam Thacker >Priority: Major > > Geode servers launched with SpringDataGeode / SpringBoot don't support some > management commands (eg status). > > +*Detailed Description:*+ > [http://mail-archives.apache.org/mod_mbox/geode-user/201709.mbox/%3ccaf3uat372ewvco-a8zpj7jsimvoqd4uladt_udryx5soeky...@mail.gmail.com%3E] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4828) Gfsh fails to determine status of members not started using ServerLauncher/LocatorLauncher
[ https://issues.apache.org/jira/browse/GEODE-4828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-4828: - Issue Type: Improvement (was: Bug) > Gfsh fails to determine status of members not started using > ServerLauncher/LocatorLauncher > -- > > Key: GEODE-4828 > URL: https://issues.apache.org/jira/browse/GEODE-4828 > Project: Geode > Issue Type: Improvement > Components: gfsh >Reporter: Dharam Thacker >Priority: Major > > +*Detailed Description:*+ > [http://mail-archives.apache.org/mod_mbox/geode-user/201709.mbox/%3ccaf3uat372ewvco-a8zpj7jsimvoqd4uladt_udryx5soeky...@mail.gmail.com%3E] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4828) Gfsh fails to determine status of members not started using ServerLauncher/LocatorLauncher
[ https://issues.apache.org/jira/browse/GEODE-4828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-4828: - Fix Version/s: (was: 1.6.0) > Gfsh fails to determine status of members not started using > ServerLauncher/LocatorLauncher > -- > > Key: GEODE-4828 > URL: https://issues.apache.org/jira/browse/GEODE-4828 > Project: Geode > Issue Type: Improvement > Components: gfsh >Reporter: Dharam Thacker >Priority: Major > > +*Detailed Description:*+ > [http://mail-archives.apache.org/mod_mbox/geode-user/201709.mbox/%3ccaf3uat372ewvco-a8zpj7jsimvoqd4uladt_udryx5soeky...@mail.gmail.com%3E] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4647) Add a new stat for AyncEventQueue/GatewaySender to track secondaryEventsQueueSize
[ https://issues.apache.org/jira/browse/GEODE-4647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433481#comment-16433481 ] ASF subversion and git services commented on GEODE-4647: Commit 059cb7088fe390323570c6461a61bceec70bb670 in geode's branch refs/heads/feature/GEODE-4647 from zhouxh [ https://gitbox.apache.org/repos/asf?p=geode.git;h=059cb70 ] GEODE-4647: add a stats eventSecondaryQueueSizeId to track events in secondary gateway sender queue > Add a new stat for AyncEventQueue/GatewaySender to track > secondaryEventsQueueSize > - > > Key: GEODE-4647 > URL: https://issues.apache.org/jira/browse/GEODE-4647 > Project: Geode > Issue Type: Bug > Components: docs, wan >Reporter: Jason Huynh >Assignee: xiaojian zhou >Priority: Major > Labels: pull-request-available > Time Spent: 4h 20m > Remaining Estimate: 0h > > Currently we have eventsQueueSize which tells us how big the queue is based > on how many primary events are in the queue. > It would be nice to have the same type of stat for how many secondary events > are in the queue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
