[jira] [Commented] (GEODE-4709) Sample output missing in gfsh docs for 'list gateways'
[ https://issues.apache.org/jira/browse/GEODE-4709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16370786#comment-16370786 ] Diane Hardman commented on GEODE-4709: -- An example output of 'list gateways' can be found at the bottom of the following page: https://geode.apache.org/docs/guide/12/topologies_and_comm/multi_site_configuration/setting_up_a_multisite_system.html > Sample output missing in gfsh docs for 'list gateways' > -- > > Key: GEODE-4709 > URL: https://issues.apache.org/jira/browse/GEODE-4709 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Diane Hardman >Priority: Major > > It looks like all other 'list' commands have both Example commands and Sample > Output except for 'list gateways'. Please add. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-4709) Sample output missing in gfsh docs for 'list gateways'
Diane Hardman created GEODE-4709: Summary: Sample output missing in gfsh docs for 'list gateways' Key: GEODE-4709 URL: https://issues.apache.org/jira/browse/GEODE-4709 Project: Geode Issue Type: Bug Components: docs Reporter: Diane Hardman It looks like all other 'list' commands have both Example commands and Sample Output except for 'list gateways'. Please add. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-4708) Users need the ability to tune GC on a per region basis.
Fred Krone created GEODE-4708: - Summary: Users need the ability to tune GC on a per region basis. Key: GEODE-4708 URL: https://issues.apache.org/jira/browse/GEODE-4708 Project: Geode Issue Type: Improvement Components: regions Reporter: Fred Krone 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] [Resolved] (GEODE-4678) Refactor or eliminate ServerHandshakeProcessor
[ https://issues.apache.org/jira/browse/GEODE-4678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Rowe resolved GEODE-4678. --- Resolution: Fixed Fix Version/s: 1.5.0 > Refactor or eliminate ServerHandshakeProcessor > -- > > Key: GEODE-4678 > URL: https://issues.apache.org/jira/browse/GEODE-4678 > Project: Geode > Issue Type: Task > Components: client/server >Reporter: Brian Rowe >Priority: Major > Labels: pull-request-available > Fix For: 1.5.0 > > Time Spent: 3h 40m > Remaining Estimate: 0h > > Currently the server side handshake code is lumped in > ServerHandshakeProcessor and consists of a bunch of static methods that make > intrusive changes into ServerConnection and Handshake objects. This should > be refactored to the appropriate classes and the object boundary between > these classes should become more distinct. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-3948) Improve CQ performance under flaky network conditions
[ https://issues.apache.org/jira/browse/GEODE-3948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Galen O'Sullivan updated GEODE-3948: Fix Version/s: 1.5.0 > Improve CQ performance under flaky network conditions > - > > Key: GEODE-3948 > URL: https://issues.apache.org/jira/browse/GEODE-3948 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Galen O'Sullivan >Assignee: Joey McAllister >Priority: Minor > Labels: pull-request-available > Fix For: 1.5.0 > > Time Spent: 2h > Remaining Estimate: 0h > > Client CQ connections occasionally stop receiving messages and become blocked > indefinitely. > This can be caused by a server that hangs or dies without sending a close > message, or by some firewalls. > The client already gets ping messages from the server, but currently ignores > them. Let's use those messages to detect a failed connection and close it. > Probably the client should follow the same logic and send ping messages if it > has sent no acks for a while, so that the server can also detect and close a > broken connection. > The timeout could be specified as a number and time interval, the ping > interval and the number of missed pings after which to fail. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4691) Gfsh command Start Locator shows inconsistent behavior with auto-connecting with a Security Manager
[
https://issues.apache.org/jira/browse/GEODE-4691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn updated GEODE-4691:
--
Description:
When starting a locator in gfsh like this
{code:java}
start locator --name=locator1{code}
the default behavior is to auto-connect gfsh to the locator.
>From the gfsh start locator help:
{code:java}
connect
When connect is set to false , Gfsh does not automatically connect to the
locator which is started
using this command.
Required: false
Default (if the parameter is specified without value): true
Default (if the parameter is not specified): true{code}
When starting the locator with a Security Manager like this
{code:java}
start locator --name=locator1
--J=-Dgemfire.security-manager=org.apache.geode.examples.SimpleSecurityManager{code}
The result is that gfsh does not auto connect to the locator. However this is
not listed in the help command and is inconsistent in the user expectation.
Solution and accceptance criteria:
Update the output of
{code:java}
start locator
--J=-Dgemfire.security-manager=org.apache.geode.examples.SimpleSecurityManager{code}
to indicate that it is not auto-connected. New output:
{code:java}
Security Manager is enabled - unable to auto-connect. Please use connect with
--user and --password to connect to locator.{code}
Update gfsh help to correctly list the behavior when the Security Manager is
set via the --J parameter
gfsh should display correct connect help message for
{code:java}
help start locator{code}
when using Security Manager.
{code:java}
connect
When connect is set to false or when locator is started with a security manager
using --J=-Dgemfire.security-manager option, Gfsh does not automatically
connect to the locator which is started using this command.
Required: false
Default (if the parameter is specified without value): true
Default (if the parameter is not specified): true{code}
was:
When starting a locator in gfsh like this
{code:java}
start locator --name=locator1{code}
the default behavior is to auto-connect gfsh to the locator.
>From the gfsh start locator help:
{code:java}
connect
When connect is set to false , Gfsh does not automatically connect to the
locator which is started
using this command.
Required: false
Default (if the parameter is specified without value): true
Default (if the parameter is not specified): true{code}
When starting the locator with a Security Manager like this
{code:java}
start locator --name=locator1
--J=-Dgemfire.security-manager=org.apache.geode.examples.SimpleSecurityManager{code}
The result is that gfsh does not auto connect to the locator. However this is
not listed in the help command and is inconsistent in the user expectation.
Solution:
Update the output of
{code:java}
start locator
--J=-Dgemfire.security-manager=org.apache.geode.examples.SimpleSecurityManager{code}
to indicate that it is not auto-connected. New output:
{code:java}
Security Manager is enabled - unable to auto-connect. Please use connect with
--user and --password to connect to locator.{code}
Update gfsh help to correctly list the behavior when the Security Manager is
set via the --J parameter
Acceptance criteria:
gfsh should display correct connect help message for
{code:java}
help start locator{code}
when using Security Manager.
{code:java}
connect
When connect is set to false or when locator is started with a security manager
using --J=-Dgemfire.security-manager option, Gfsh does not automatically
connect to the locator which is started using this command.
Required: false
Default (if the parameter is specified without value): true
Default (if the parameter is not specified): true{code}
> Gfsh command Start Locator shows inconsistent behavior with auto-connecting
> with a Security Manager
> ---
>
> Key: GEODE-4691
> URL: https://issues.apache.org/jira/browse/GEODE-4691
> Project: Geode
> Issue Type: Bug
> Components: docs, gfsh, security
>Reporter: Barbara Pruijn
>Priority: Major
> Labels: pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> When starting a locator in gfsh like this
> {code:java}
> start locator --name=locator1{code}
> the default behavior is to auto-connect gfsh to the locator.
> From the gfsh start locator help:
> {code:java}
> connect
> When connect is set to false , Gfsh does not automatically connect to the
> locator which is started
> using this command.
> Required: false
> Default (if the parameter is specified without value): true
> Default (if the parameter is not specified): true{code}
> When starting the locator with a Security Manager like this
> {code:java}
> start locator --name=locator1
>
[jira] [Updated] (GEODE-4691) Gfsh command Start Locator shows inconsistent behavior with auto-connecting with a Security Manager
[
https://issues.apache.org/jira/browse/GEODE-4691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn updated GEODE-4691:
--
Description:
When starting a locator in gfsh like this
{code:java}
start locator --name=locator1{code}
the default behavior is to auto-connect gfsh to the locator.
>From the gfsh start locator help:
{code:java}
connect
When connect is set to false , Gfsh does not automatically connect to the
locator which is started
using this command.
Required: false
Default (if the parameter is specified without value): true
Default (if the parameter is not specified): true{code}
When starting the locator with a Security Manager like this
{code:java}
start locator --name=locator1
--J=-Dgemfire.security-manager=org.apache.geode.examples.SimpleSecurityManager{code}
The result is that gfsh does not auto connect to the locator. However this is
not listed in the help command and is inconsistent in the user expectation.
Solution:
Update the output of
{code:java}
start locator
--J=-Dgemfire.security-manager=org.apache.geode.examples.SimpleSecurityManager{code}
to indicate that it is not auto-connected. New output:
{code:java}
Security Manager is enabled - unable to auto-connect. Please use connect with
--user and --password to connect to locator.{code}
Update gfsh help to correctly list the behavior when the Security Manager is
set via the --J parameter
Acceptance criteria:
gfsh should display correct connect help message for
{code:java}
help start locator{code}
when using Security Manager.
{code:java}
connect
When connect is set to false or when locator is started with a security manager
using --J=-Dgemfire.security-manager option, Gfsh does not automatically
connect to the locator which is started using this command.
Required: false
Default (if the parameter is specified without value): true
Default (if the parameter is not specified): true{code}
was:
When starting a locator in gfsh like this
{code:java}
start locator --name=locator1{code}
the default behavior is to auto-connect gfsh to the locator.
>From the gfsh start locator help:
{code:java}
connect
When connect is set to false , Gfsh does not automatically connect to the
locator which is started
using this command.
Required: false
Default (if the parameter is specified without value): true
Default (if the parameter is not specified): true{code}
When starting the locator with a Security Manager like this
{code:java}
start locator --name=locator1
--J=-Dgemfire.security-manager=org.apache.geode.examples.SimpleSecurityManager{code}
The result is that gfsh does not auto connect to the locator. However this is
not listed in the help command and is inconsistent in the user expectation.
Solution:
Update the output of
{code:java}
start locator
--J=-Dgemfire.security-manager=org.apache.geode.examples.SimpleSecurityManager{code}
to indicate that it is not auto-connected. Output:
{code:java}
Security Manager is enabled - unable to auto-connect. Please use connect with
--user and --password to connect to locator.{code}
Update gfsh help to correctly list the behavior when the Security Manager is
set via the --J parameter
Acceptance criteria:
gfsh should display correct connect help message for
{code:java}
help start locator{code}
when using Security Manager.
{code:java}
connect
When connect is set to false or when locator is started with a security manager
using --J=-Dgemfire.security-manager option, Gfsh does not automatically
connect to the locator which is started using this command.
Required: false
Default (if the parameter is specified without value): true
Default (if the parameter is not specified): true{code}
> Gfsh command Start Locator shows inconsistent behavior with auto-connecting
> with a Security Manager
> ---
>
> Key: GEODE-4691
> URL: https://issues.apache.org/jira/browse/GEODE-4691
> Project: Geode
> Issue Type: Bug
> Components: docs, gfsh, security
>Reporter: Barbara Pruijn
>Priority: Major
> Labels: pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> When starting a locator in gfsh like this
> {code:java}
> start locator --name=locator1{code}
> the default behavior is to auto-connect gfsh to the locator.
> From the gfsh start locator help:
> {code:java}
> connect
> When connect is set to false , Gfsh does not automatically connect to the
> locator which is started
> using this command.
> Required: false
> Default (if the parameter is specified without value): true
> Default (if the parameter is not specified): true{code}
> When starting the locator with a Security Manager like this
> {code:java}
> start locator --name=locator1
>
[jira] [Updated] (GEODE-4691) Gfsh command Start Locator shows inconsistent behavior with auto-connecting with a Security Manager
[
https://issues.apache.org/jira/browse/GEODE-4691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn updated GEODE-4691:
--
Description:
When starting a locator in gfsh like this
{code:java}
start locator --name=locator1{code}
the default behavior is to auto-connect gfsh to the locator.
>From the gfsh start locator help:
{code:java}
connect
When connect is set to false , Gfsh does not automatically connect to the
locator which is started
using this command.
Required: false
Default (if the parameter is specified without value): true
Default (if the parameter is not specified): true{code}
When starting the locator with a Security Manager like this
{code:java}
start locator --name=locator1
--J=-Dgemfire.security-manager=org.apache.geode.examples.SimpleSecurityManager{code}
The result is that gfsh does not auto connect to the locator. However this is
not listed in the help command and is inconsistent in the user expectation.
Solution:
Update the output of
{code:java}
start locator
--J=-Dgemfire.security-manager=org.apache.geode.examples.SimpleSecurityManager{code}
to indicate that it is not auto-connected. Output:
{code:java}
Security Manager is enabled - unable to auto-connect. Please use connect with
--user and --password to connect to locator.{code}
Update gfsh help to correctly list the behavior when the Security Manager is
set via the --J parameter
Acceptance criteria:
gfsh should display correct connect help message for
{code:java}
help start locator{code}
when using Security Manager.
{code:java}
connect
When connect is set to false or when locator is started with a security manager
using --J=-Dgemfire.security-manager option, Gfsh does not automatically
connect to the locator which is started using this command.
Required: false
Default (if the parameter is specified without value): true
Default (if the parameter is not specified): true{code}
was:
When starting a locator in gfsh like this
{code:java}
start locator --name=locator1{code}
the default behavior is to auto-connect gfsh to the locator.
>From the gfsh start locator help:
{code:java}
connect
When connect is set to false , Gfsh does not automatically connect to the
locator which is started
using this command.
Required: false
Default (if the parameter is specified without value): true
Default (if the parameter is not specified): true{code}
When starting the locator with a Security Manager like this
{code:java}
start locator --name=locator1
--J=-Dgemfire.security-manager=org.apache.geode.examples.SimpleSecurityManager{code}
The result is that gfsh does not auto connect to the locator. However this is
not listed in the help command and is inconsistent in the user expectation.
Solution:
Update gfsh help to correctly list the behavior when the Security Manager is
set via the --J parameter
Acceptance criteria:
gfsh should display correct connect help message for
{code:java}
help start locator{code}
when using Security Manager.
{code:java}
connect
When connect is set to false or when locator is started with a security manager
using --J=-Dgemfire.security-manager option, Gfsh does not automatically
connect to the locator which is started using this command.
Required: false
Default (if the parameter is specified without value): true
Default (if the parameter is not specified): true{code}
> Gfsh command Start Locator shows inconsistent behavior with auto-connecting
> with a Security Manager
> ---
>
> Key: GEODE-4691
> URL: https://issues.apache.org/jira/browse/GEODE-4691
> Project: Geode
> Issue Type: Bug
> Components: docs, gfsh, security
>Reporter: Barbara Pruijn
>Priority: Major
> Labels: pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> When starting a locator in gfsh like this
> {code:java}
> start locator --name=locator1{code}
> the default behavior is to auto-connect gfsh to the locator.
> From the gfsh start locator help:
> {code:java}
> connect
> When connect is set to false , Gfsh does not automatically connect to the
> locator which is started
> using this command.
> Required: false
> Default (if the parameter is specified without value): true
> Default (if the parameter is not specified): true{code}
> When starting the locator with a Security Manager like this
> {code:java}
> start locator --name=locator1
> --J=-Dgemfire.security-manager=org.apache.geode.examples.SimpleSecurityManager{code}
> The result is that gfsh does not auto connect to the locator. However this is
> not listed in the help command and is inconsistent in the user expectation.
>
> Solution:
> Update the output of
> {code:java}
> start locator
> --J=-Dgemfire.security-manager=org.apache.geode.examples.SimpleSecurityManager{code}
[jira] [Updated] (GEODE-4691) Gfsh command Start Locator shows inconsistent behavior with auto-connecting with a Security Manager
[
https://issues.apache.org/jira/browse/GEODE-4691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn updated GEODE-4691:
--
Description:
When starting a locator in gfsh like this
{code:java}
start locator --name=locator1{code}
the default behavior is to auto-connect gfsh to the locator.
>From the gfsh start locator help:
{code:java}
connect
When connect is set to false , Gfsh does not automatically connect to the
locator which is started
using this command.
Required: false
Default (if the parameter is specified without value): true
Default (if the parameter is not specified): true{code}
When starting the locator with a Security Manager like this
{code:java}
start locator --name=locator1
--J=-Dgemfire.security-manager=org.apache.geode.examples.SimpleSecurityManager{code}
The result is that gfsh does not auto connect to the locator. However this is
not listed in the help command and is inconsistent in the user expectation.
Solution:
Update gfsh help to correctly list the behavior when the Security Manager is
set via the --J parameter
Acceptance criteria:
gfsh should display correct connect help message for
{code:java}
help start locator{code}
when using Security Manager.
{code:java}
connect
When connect is set to false or when locator is started with a security manager
using --J=-Dgemfire.security-manager option, Gfsh does not automatically
connect to the locator which is started using this command.
Required: false
Default (if the parameter is specified without value): true
Default (if the parameter is not specified): true{code}
was:
When starting a locator in gfsh like this
{code:java}
start locator --name=locator1{code}
the default behavior is to auto-connect gfsh to the locator.
>From the gfsh start locator help:
{code:java}
connect
When connect is set to false , Gfsh does not automatically connect to the
locator which is started
using this command.
Required: false
Default (if the parameter is specified without value): true
Default (if the parameter is not specified): true{code}
When starting the locator with a Security Manager like this
{code:java}
start locator --name=locator1
--J=-Dgemfire.security-manager=org.apache.geode.examples.SimpleSecurityManager{code}
The result is that gfsh does not auto connect to the locator. However this is
not listed in the help command and is inconsistent in the user expectation.
Solution:
Update gfsh help to correctly list the behavior when the Security Manager is
set via the --J parameter
Acceptance criteria:
gfsh should display correct connect help message for
{code:java}
help start locator{code}
when using Security Manager.
{code:java}
connect
When connect is set to false , Gfsh does not automatically connect to
the locator which is started using this command.
Required: false
Default (if the parameter is specified without value): true
Default (if the parameter is not specified): true
If the locator is started with a Security Manager in --J parameter, the auto
connect default value is false and the locator will not auto connect.{code}
> Gfsh command Start Locator shows inconsistent behavior with auto-connecting
> with a Security Manager
> ---
>
> Key: GEODE-4691
> URL: https://issues.apache.org/jira/browse/GEODE-4691
> Project: Geode
> Issue Type: Bug
> Components: docs, gfsh, security
>Reporter: Barbara Pruijn
>Priority: Major
> Labels: pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> When starting a locator in gfsh like this
> {code:java}
> start locator --name=locator1{code}
> the default behavior is to auto-connect gfsh to the locator.
> From the gfsh start locator help:
> {code:java}
> connect
> When connect is set to false , Gfsh does not automatically connect to the
> locator which is started
> using this command.
> Required: false
> Default (if the parameter is specified without value): true
> Default (if the parameter is not specified): true{code}
> When starting the locator with a Security Manager like this
> {code:java}
> start locator --name=locator1
> --J=-Dgemfire.security-manager=org.apache.geode.examples.SimpleSecurityManager{code}
> The result is that gfsh does not auto connect to the locator. However this is
> not listed in the help command and is inconsistent in the user expectation.
>
> Solution:
> Update gfsh help to correctly list the behavior when the Security Manager is
> set via the --J parameter
> Acceptance criteria:
> gfsh should display correct connect help message for
> {code:java}
> help start locator{code}
> when using Security Manager.
> {code:java}
> connect
> When connect is set to false or when locator is started with a security
> manager using --J=-Dgemfire.security-manager option, Gfsh
[jira] [Updated] (GEODE-4691) Gfsh command Start Locator shows inconsistent behavior with auto-connecting with a Security Manager
[
https://issues.apache.org/jira/browse/GEODE-4691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn updated GEODE-4691:
--
Description:
When starting a locator in gfsh like this
{code:java}
start locator --name=locator1{code}
the default behavior is to auto-connect gfsh to the locator.
>From the gfsh start locator help:
{code:java}
connect
When connect is set to false , Gfsh does not automatically connect to the
locator which is started
using this command.
Required: false
Default (if the parameter is specified without value): true
Default (if the parameter is not specified): true{code}
When starting the locator with a Security Manager like this
{code:java}
start locator --name=locator1
--J=-Dgemfire.security-manager=org.apache.geode.examples.SimpleSecurityManager{code}
The result is that gfsh does not auto connect to the locator. However this is
not listed in the help command and is inconsistent in the user expectation.
Solution:
Update gfsh help to correctly list the behavior when the Security Manager is
set via the --J parameter
Acceptance criteria:
gfsh should display correct connect help message for
{code:java}
help start locator{code}
when using Security Manager.
{code:java}
connect
When connect is set to false , Gfsh does not automatically connect to
the locator which is started using this command.
Required: false
Default (if the parameter is specified without value): true
Default (if the parameter is not specified): true
If the locator is started with a Security Manager in --J parameter, the auto
connect default value is false and the locator will not auto connect.{code}
was:
When starting a locator in gfsh like this
{code:java}
start locator --name=locator1{code}
the default behavior is to auto-connect gfsh to the locator.
>From the gfsh start locator help:
{code:java}
connect
When connect is set to false , Gfsh does not automatically connect to the
locator which is started
using this command.
Required: false
Default (if the parameter is specified without value): true
Default (if the parameter is not specified): true{code}
When starting the locator with a Security Manager like this
{code:java}
start locator --name=locator1
--J=-Dgemfire.security-manager=org.apache.geode.examples.SimpleSecurityManager{code}
The result is that gfsh does not auto connect to the locator. However this is
not listed in the help command and is inconsistent in the user expectation.
Possible solutions:
1. Update gfsh help to correctly list the behavior when the Security Manager
is set via the --J parameter
2. Add the options
{code:java}
--user --password{code}
to the start locator command
> Gfsh command Start Locator shows inconsistent behavior with auto-connecting
> with a Security Manager
> ---
>
> Key: GEODE-4691
> URL: https://issues.apache.org/jira/browse/GEODE-4691
> Project: Geode
> Issue Type: Bug
> Components: docs, gfsh, security
>Reporter: Barbara Pruijn
>Priority: Major
> Labels: pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> When starting a locator in gfsh like this
> {code:java}
> start locator --name=locator1{code}
> the default behavior is to auto-connect gfsh to the locator.
> From the gfsh start locator help:
> {code:java}
> connect
> When connect is set to false , Gfsh does not automatically connect to the
> locator which is started
> using this command.
> Required: false
> Default (if the parameter is specified without value): true
> Default (if the parameter is not specified): true{code}
> When starting the locator with a Security Manager like this
> {code:java}
> start locator --name=locator1
> --J=-Dgemfire.security-manager=org.apache.geode.examples.SimpleSecurityManager{code}
> The result is that gfsh does not auto connect to the locator. However this is
> not listed in the help command and is inconsistent in the user expectation.
>
> Solution:
> Update gfsh help to correctly list the behavior when the Security Manager is
> set via the --J parameter
> Acceptance criteria:
> gfsh should display correct connect help message for
> {code:java}
> help start locator{code}
> when using Security Manager.
> {code:java}
> connect
> When connect is set to false , Gfsh does not automatically connect to
> the locator which is started using this command.
> Required: false
> Default (if the parameter is specified without value): true
> Default (if the parameter is not specified): true
> If the locator is started with a Security Manager in --J parameter, the auto
> connect default value is false and the locator will not auto connect.{code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-4691) Gfsh command Start Locator shows inconsistent behavior with auto-connecting with a Security Manager
[
https://issues.apache.org/jira/browse/GEODE-4691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-4691:
--
Labels: pull-request-available (was: )
> Gfsh command Start Locator shows inconsistent behavior with auto-connecting
> with a Security Manager
> ---
>
> Key: GEODE-4691
> URL: https://issues.apache.org/jira/browse/GEODE-4691
> Project: Geode
> Issue Type: Bug
> Components: docs, gfsh, security
>Reporter: Barbara Pruijn
>Priority: Major
> Labels: pull-request-available
>
> When starting a locator in gfsh like this
> {code:java}
> start locator --name=locator1{code}
> the default behavior is to auto-connect gfsh to the locator.
> From the gfsh start locator help:
> {code:java}
> connect
> When connect is set to false , Gfsh does not automatically connect to the
> locator which is started
> using this command.
> Required: false
> Default (if the parameter is specified without value): true
> Default (if the parameter is not specified): true{code}
> When starting the locator with a Security Manager like this
> {code:java}
> start locator --name=locator1
> --J=-Dgemfire.security-manager=org.apache.geode.examples.SimpleSecurityManager{code}
> The result is that gfsh does not auto connect to the locator. However this is
> not listed in the help command and is inconsistent in the user expectation.
>
> Possible solutions:
> 1. Update gfsh help to correctly list the behavior when the Security Manager
> is set via the --J parameter
> 2. Add the options
> {code:java}
> --user --password{code}
> to the start locator command
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-4373) gfsh 'describe region' not showing accessor region description
[
https://issues.apache.org/jira/browse/GEODE-4373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dave Barnes resolved GEODE-4373.
Resolution: Fixed
> gfsh 'describe region' not showing accessor region description
> --
>
> Key: GEODE-4373
> URL: https://issues.apache.org/jira/browse/GEODE-4373
> Project: Geode
> Issue Type: Bug
> Components: docs, gfsh
>Reporter: Sai Boorlagadda
>Assignee: Dave Barnes
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.5.0
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> gfsh not displaying accessor region description.
> on Develop:
> {noformat}
> Command result for :
> ..
> Name : testRegion
> Data Policy : persistent replicate
> Hosting Members : server-5
> server-4
> server-3
> server-2
> Non-Default Attributes Shared By Hosting Members
> Type | Name| Value
> -- | --- |
> Region | data-policy | PERSISTENT_REPLICATE
>| disk-store-name | testDiskStore
>| size| 0
>| scope | distributed-ack{noformat}
>
> But in v1.3.0 it used to display accessor region description as a separate
> table.
> {noformat}
> Command result for :
> ...
> Name: testRegion
> Data Policy : persistent replicate
> Hosting Members : server-3
> server-2
> Non-Default Attributes Shared By Hosting Members
> Type | Name | Value
> -- | --- |
> Region | data-policy | PERSISTENT_REPLICATE
>| disk-store-name | testDiskStore
>| size| 0
>| scope | distributed-ack
> ...
> Name : testRegion
> Data Policy : empty
> Accessor Members : server-1
> Non-Default Attributes Shared By Accessor Members
> Type |Name | Value
> -- | --- | ---
> Region | data-policy | EMPTY
>| size| 0
>| scope | distributed-ack
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-4610) Refactor PDX into geode-pdx module
[ https://issues.apache.org/jira/browse/GEODE-4610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Baynes updated GEODE-4610: Description: As a client developer, I want to be able to create PDX objects without having a cache instantiated. Toward that end, the code for dealing with the PDX serialization format ought to be in its own module, geode-pdx. This will make it clearer where the serialization code lives, improve modularity, and make future refactors easier. was:The code for dealing with the PDX serialization format ought to be in its own module, geode-pdx. > Refactor PDX into geode-pdx module > -- > > Key: GEODE-4610 > URL: https://issues.apache.org/jira/browse/GEODE-4610 > Project: Geode > Issue Type: New Feature > Components: serialization >Reporter: Michael Dodge >Priority: Major > > As a client developer, I want to be able to create PDX objects without having > a cache instantiated. Toward that end, the code for dealing with the PDX > serialization format ought to be in its own module, geode-pdx. > This will make it clearer where the serialization code lives, improve > modularity, and make future refactors easier. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4704) GatewaySender batch conflation can incorrectly conflate events causing out of order processing
[
https://issues.apache.org/jira/browse/GEODE-4704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-4704:
--
Labels: pull-request-available (was: )
> GatewaySender batch conflation can incorrectly conflate events causing out of
> order processing
> --
>
> Key: GEODE-4704
> URL: https://issues.apache.org/jira/browse/GEODE-4704
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Barry Oglesby
>Priority: Major
> Labels: pull-request-available
>
> In the current implementation of \{{AbstractGatewaySenderEventProcessor
> conflate}} can incorrectly conflate two create events on the same key.
> The else clause of the conflate method (meaning the event is not conflatable)
> assumes there isn't already a event with the same region, key and operation
> in the map. It just does a put:
> {noformat}
> ConflationKey key = new ConflationKey(gsEvent.getRegion().getFullPath(),
> gsEvent.getKeyToConflate(), gsEvent.getOperation());
> conflatedEventsMap.put(key, gsEvent);
> {noformat}
> In certain cases, there could already be a create event on the same region,
> key and operation in the batch, so the previous one gets replaced by the
> later once which causes the events to be processed out of order.
> These 4 events:
> {noformat}
> SenderEventImpl[id=EventIDid=57bytes;threadID=0x10018|112;sequenceID=100;bucketId=24];operation=CREATE;region=/dataStoreRegion;key=Object_13964;shadowKey=27709]
> SenderEventImpl[id=EventIDid=57bytes;threadID=0x10018|112;sequenceID=101;bucketId=24];operation=CREATE;region=/dataStoreRegion;key=Object_14024;shadowKey=27822]
> SenderEventImpl[id=EventIDid=57bytes;threadID=0x10018|112;sequenceID=102;bucketId=24];operation=DESTROY;region=/dataStoreRegion;key=Object_13964;shadowKey=27935]
> SenderEventImpl[id=EventIDid=57bytes;threadID=0x10018|112;sequenceID=104;bucketId=24];operation=CREATE;region=/dataStoreRegion;key=Object_14024;shadowKey=28161]
> {noformat}
> Become these 3 events:
> {noformat}
> SenderEventImpl[id=EventIDid=57bytes;threadID=0x10018|112;sequenceID=100;bucketId=24];operation=CREATE;region=/dataStoreRegion;key=Object_13964;shadowKey=27709]
> SenderEventImpl[id=EventIDid=57bytes;threadID=0x10018|112;sequenceID=104;bucketId=24];operation=CREATE;region=/dataStoreRegion;key=Object_14024;shadowKey=28161]
> SenderEventImpl[id=EventIDid=57bytes;threadID=0x10018|112;sequenceID=102;bucketId=24];operation=DESTROY;region=/dataStoreRegion;key=Object_13964;shadowKey=27935]
> {noformat}
> Notice the shadowKeys and sequenceIds are out of order after the conflation.
> The fix will be to include the shadow key in hashCode and equals in the case
> where the event is not conflatable.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-4658) Expose how much time it takes to write to disk and what is the disk store size
[
https://issues.apache.org/jira/browse/GEODE-4658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fred Krone updated GEODE-4658:
--
Description:
*Given* I have a persistent region with a default disk store
*When* I write data on the region
*Then* I can see 2 new metrics {{average write time to disk}} ns time and
{{size of disk store}} in bytes
h3. Documentation
Add this new metric to the docs
This should be a matter of altering the ShowMetricsCommand.java
was:
*Given* I have a persistent region with a default disk store
*When* I write data on the region
*Then* I can see 2 new metrics {{average write time to disk}} ns time and
{{size of disk store}} in bytes
h3. Documentation
Add this new metric to the docs
> Expose how much time it takes to write to disk and what is the disk store size
> --
>
> Key: GEODE-4658
> URL: https://issues.apache.org/jira/browse/GEODE-4658
> Project: Geode
> Issue Type: Improvement
> Components: regions
>Reporter: Fred Krone
>Priority: Major
>
> *Given* I have a persistent region with a default disk store
> *When* I write data on the region
> *Then* I can see 2 new metrics {{average write time to disk}} ns time and
> {{size of disk store}} in bytes
> h3. Documentation
> Add this new metric to the docs
>
> This should be a matter of altering the ShowMetricsCommand.java
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-4706) Please update commons dependencies
[
https://issues.apache.org/jira/browse/GEODE-4706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16370371#comment-16370371
]
Anthony Baker commented on GEODE-4706:
--
We can split this into two things:
- Primary uses in our source code that we can change
- Transitive dependencies that we don't have control over
> Please update commons dependencies
> --
>
> Key: GEODE-4706
> URL: https://issues.apache.org/jira/browse/GEODE-4706
> Project: Geode
> Issue Type: Improvement
>Reporter: Petar Tahchiev
>Priority: Major
>
> Geode still depends on {{commons-lang:commons-lang}}:
> view-source:[http://repo1.maven.org/maven2/org/apache/geode/geode-core/1.4.0/geode-core-1.4.0.pom]
> which is about 8 years old.
> Would you please consider updating it to {{org.apache.commons:commons-lang3}}
> please?
> Same with {{org.apache.commons:commons-io}} and
> {{org.apache.commons:commons-digester3}}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-4626) deprecating create region using --template-region option in gfsh
[ https://issues.apache.org/jira/browse/GEODE-4626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barbara Pruijn resolved GEODE-4626. --- Resolution: Fixed > deprecating create region using --template-region option in gfsh > > > Key: GEODE-4626 > URL: https://issues.apache.org/jira/browse/GEODE-4626 > Project: Geode > Issue Type: Improvement > Components: docs, gfsh >Affects Versions: 1.4.0 >Reporter: Jinmei Liao >Priority: Major > Labels: pull-request-available > Fix For: 1.5.0 > > Time Spent: 40m > Remaining Estimate: 0h > > currently, there are two ways to create a region, either to use a --type > option indicating a region shortcut or a --template-region option specifying > another regionPath where you want to copy the attribute from. > First of all, we are not sure what set of attributes that make sense to copy > to the new region. e.g listeners/loaders/writers, normally these are > connected to a downstream database that user may/may not want the new region > to read/write the same table. And the current implementation would fail to > create a region from a template that has these custom callbacks (including > listeners, loader, writer, compressor, resolvers etc). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4626) deprecating create region using --template-region option in gfsh
[ https://issues.apache.org/jira/browse/GEODE-4626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barbara Pruijn updated GEODE-4626: -- Fix Version/s: 1.5.0 > deprecating create region using --template-region option in gfsh > > > Key: GEODE-4626 > URL: https://issues.apache.org/jira/browse/GEODE-4626 > Project: Geode > Issue Type: Improvement > Components: docs, gfsh >Affects Versions: 1.4.0 >Reporter: Jinmei Liao >Priority: Major > Labels: pull-request-available > Fix For: 1.5.0 > > Time Spent: 40m > Remaining Estimate: 0h > > currently, there are two ways to create a region, either to use a --type > option indicating a region shortcut or a --template-region option specifying > another regionPath where you want to copy the attribute from. > First of all, we are not sure what set of attributes that make sense to copy > to the new region. e.g listeners/loaders/writers, normally these are > connected to a downstream database that user may/may not want the new region > to read/write the same table. And the current implementation would fail to > create a region from a template that has these custom callbacks (including > listeners, loader, writer, compressor, resolvers etc). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-3813) Region registerInterest API usage of type parameters is broken
[
https://issues.apache.org/jira/browse/GEODE-3813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Diane Hardman updated GEODE-3813:
-
Component/s: docs
> Region registerInterest API usage of type parameters is broken
> --
>
> Key: GEODE-3813
> URL: https://issues.apache.org/jira/browse/GEODE-3813
> Project: Geode
> Issue Type: Bug
> Components: client queues, docs
>Reporter: Kirk Lund
>Assignee: Jason Huynh
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.5.0
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> The registerInterest API works for single key registration but is broken for
> all other types of registration if the Region is declared with type
> parameters:
> Single key (works):
> {noformat}
> Region region = clientRegionFactory.create(regionName);
> region.registerInterest(1);
> {noformat}
> ALL_KEYS token is broken (fails to compile):
> {noformat}
> Region region = clientRegionFactory.create(regionName);
> region.registerInterest("ALL_KEYS");
> {noformat}
> List of keys is broken (fails to compile):
> {noformat}
> Region region = clientRegionFactory.create(regionName);
> List listOfKeys = new ArrayList<>();
> listOfKeys.add(1);
> listOfKeys.add(2);
> region.registerInterest(listOfKeys);
> {noformat}
> When this ticket is fixed and the API is updated, we should consider adding
> support for var args:
> {noformat}
> Region region = clientRegionFactory.create(regionName);
> region.registerInterest(1, 2, 3);
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-4597) RemoteRemoveAllMessage and RemotePutAllMessage should not use a partitioned region class
[ https://issues.apache.org/jira/browse/GEODE-4597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fred Krone updated GEODE-4597: -- Labels: (was: refactoring) > RemoteRemoveAllMessage and RemotePutAllMessage should not use a partitioned > region class > > > Key: GEODE-4597 > URL: https://issues.apache.org/jira/browse/GEODE-4597 > Project: Geode > Issue Type: Improvement > Components: transactions >Reporter: Darrel Schneider >Priority: Major > > The RemoteRemoveAllMessage and RemotePutAllMessage implement > removeAll/putAll for transactions on non-partitioned classes. But they call a > static method (getEventForEntry) on RemoveAllPRMessage/PutAllPRMessage which > is a messaged used for partitioned regions. > This code should be refactored so that the common getEventForEntry is not in > a class dedicated to a specific type of region. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4597) RemoteRemoveAllMessage and RemotePutAllMessage should not use a partitioned region class
[ https://issues.apache.org/jira/browse/GEODE-4597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fred Krone updated GEODE-4597: -- Labels: refactoring (was: ) > RemoteRemoveAllMessage and RemotePutAllMessage should not use a partitioned > region class > > > Key: GEODE-4597 > URL: https://issues.apache.org/jira/browse/GEODE-4597 > Project: Geode > Issue Type: Improvement > Components: transactions >Reporter: Darrel Schneider >Priority: Major > > The RemoteRemoveAllMessage and RemotePutAllMessage implement > removeAll/putAll for transactions on non-partitioned classes. But they call a > static method (getEventForEntry) on RemoveAllPRMessage/PutAllPRMessage which > is a messaged used for partitioned regions. > This code should be refactored so that the common getEventForEntry is not in > a class dedicated to a specific type of region. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-4707) Have jdbc connector look for configured jndi binding
Fred Krone created GEODE-4707:
-
Summary: Have jdbc connector look for configured jndi binding
Key: GEODE-4707
URL: https://issues.apache.org/jira/browse/GEODE-4707
Project: Geode
Issue Type: Improvement
Components: extensions, regions
Reporter: Fred Krone
A user should be able to create a datasource using the gfsh command {{create
jndi-binding }}
Then a datasource will be created with the supplied options and the binding
will be created without the user having to restart the existing server(s)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-4394) gfsh put command: change option --skip-if-exists to --if-not-exists
[ https://issues.apache.org/jira/browse/GEODE-4394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barbara Pruijn resolved GEODE-4394. --- Resolution: Fixed > gfsh put command: change option --skip-if-exists to --if-not-exists > --- > > Key: GEODE-4394 > URL: https://issues.apache.org/jira/browse/GEODE-4394 > Project: Geode > Issue Type: Improvement > Components: docs, gfsh >Reporter: Dave Barnes >Priority: Major > Labels: pull-request-available > Fix For: 1.5.0 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Change the gfsh put command `--skip-if-exists` option to `--if-not-exists` > for consistency with other gfsh commands, most notably create region (see > GEODE-4354). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4706) Please update commons dependencies
[
https://issues.apache.org/jira/browse/GEODE-4706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Petar Tahchiev updated GEODE-4706:
--
Description:
Geode still depends on {{commons-lang:commons-lang}}:
view-source:[http://repo1.maven.org/maven2/org/apache/geode/geode-core/1.4.0/geode-core-1.4.0.pom]
which is about 8 years old.
Would you please consider updating it to {{org.apache.commons:commons-lang3}}
please?
Same with {{org.apache.commons:commons-io}} and
{{org.apache.commons:commons-digester3}}
was:
Geode still depends on \{{commons-lang:commons-lang}}:
view-source:[http://repo1.maven.org/maven2/org/apache/geode/geode-core/1.4.0/geode-core-1.4.0.pom]
which is about 8 years old.
Would you please consider updating it to
org.apache.commons:commons-lang3 please?
Same with \{{org.apache.commons:commons-io}} and
org.apache.commons:commons-digester3
> Please update commons dependencies
> --
>
> Key: GEODE-4706
> URL: https://issues.apache.org/jira/browse/GEODE-4706
> Project: Geode
> Issue Type: Improvement
>Reporter: Petar Tahchiev
>Priority: Major
>
> Geode still depends on {{commons-lang:commons-lang}}:
> view-source:[http://repo1.maven.org/maven2/org/apache/geode/geode-core/1.4.0/geode-core-1.4.0.pom]
> which is about 8 years old.
> Would you please consider updating it to {{org.apache.commons:commons-lang3}}
> please?
> Same with {{org.apache.commons:commons-io}} and
> {{org.apache.commons:commons-digester3}}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-4706) Please update commons dependencies
Petar Tahchiev created GEODE-4706:
-
Summary: Please update commons dependencies
Key: GEODE-4706
URL: https://issues.apache.org/jira/browse/GEODE-4706
Project: Geode
Issue Type: Improvement
Reporter: Petar Tahchiev
Geode still depends on \{{commons-lang:commons-lang}}:
view-source:[http://repo1.maven.org/maven2/org/apache/geode/geode-core/1.4.0/geode-core-1.4.0.pom]
which is about 8 years old.
Would you please consider updating it to
org.apache.commons:commons-lang3 please?
Same with \{{org.apache.commons:commons-io}} and
org.apache.commons:commons-digester3
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-3875) gfsh command to create jndi binding
[
https://issues.apache.org/jira/browse/GEODE-3875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-3875:
--
Labels: pull-request-available (was: )
> gfsh command to create jndi binding
> ---
>
> Key: GEODE-3875
> URL: https://issues.apache.org/jira/browse/GEODE-3875
> Project: Geode
> Issue Type: Sub-task
> Components: docs, gfsh
>Reporter: Swapnil Bawaskar
>Priority: Major
> Labels: pull-request-available
>
> In cache.xml user can specify jndi binding like so:
> {code:java}
>
> jdbc-driver-class="org.postgresql.Driver" user-name="gpadmin"
> password="changeme"
> connection-url="jdbc:postgresql://localhost:5432/gemfire_db">
>
>
> {code}
> A user should be able to create a datasource using the gfsh command {{create
> jndi-binding }}
> Then a datasource will be created with the supplied options and the binding
> will be created without the user having to restart the existing server(s)
> Please look at Geode's schema for a list of attributes that can be set:
> [https://github.com/apache/geode-site/blob/master/website/content/schema/cache/cache-1.0.xsd#L1331]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
