[jira] [Commented] (GEODE-1831) Function gets executed twice on server with gateways if groups are configured
[ https://issues.apache.org/jira/browse/GEODE-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15729327#comment-15729327 ] ASF subversion and git services commented on GEODE-1831: Commit ef96dba9a02d3f0ffab030e9e30c27caea3b4a89 in geode's branch refs/heads/develop from [~barry.oglesby] [ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=ef96dba ] GEODE-1831: Function no longer gets executed twice on gateway receivers with groups > Function gets executed twice on server with gateways if groups are configured > - > > Key: GEODE-1831 > URL: https://issues.apache.org/jira/browse/GEODE-1831 > Project: Geode > Issue Type: Bug > Components: functions >Reporter: Barry Oglesby >Assignee: Barry Oglesby > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Nightly geode build artifacts
Does the nightly build produce some sort of binary that users could download and use? I'm thinking about a specific user that hits a problematic bug in 1.0.0 but it's fixed on develop for 1.1.0. If the nightly build produces a downloadable binary then they could try that out without having to clone the repo and build from sources. Thanks, Kirk
[jira] [Resolved] (GEODE-1986) The Cluster Configuration Service must absolutely not be required to run Geode.
[
https://issues.apache.org/jira/browse/GEODE-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao resolved GEODE-1986.
Resolution: Fixed (was: Workaround)
> The Cluster Configuration Service must absolutely not be required to run
> Geode.
> ---
>
> Key: GEODE-1986
> URL: https://issues.apache.org/jira/browse/GEODE-1986
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Affects Versions: 1.0.0-incubating
>Reporter: John Blum
>Assignee: Jinmei Liao
>Priority: Critical
> Labels: ClusterConfig, ClusterConfigurationService
> Fix For: 1.1.0
>
> Attachments: App.java
>
>
> A bug was introduced in Geode when the logic to fetch the Cluster
> Configuration meta-data from the Locator in the cluster by a joining member
> was refactored into it's own
> [class|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java]
> causing the following issues...
> 1. First, and foremost, the _Cluster Configuration_ service is now, seemingly
> no longer *optional* (hence, _required_), which is both short sighted and too
> restrictive, and will break existing [embedded Geode application]
> deployments, particularly in situations where GemFire config, and especially,
> _Gfsh_ were not used to configure the cluster, which will be true when users
> upgrade existing clusters based on an earlier versions of Apache Geode
> (namely GemFire < v7.0, once GemFire 9 is based on Apache Geode) and as well
> as _Spring_ applications.
> This change is apparent from the removal of the [conditional check on the
> Geode System property
> (1)|https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating.M3/geode-core/src/main/java/com/gemstone/gemfire/internal/cache/GemFireCacheImpl.java#L956-L958],
> which is no longer present [here
> (2)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java#L184-L233]
> or possibly [here
> (3)|https://github.com/apache/incubator-geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L976-L981].
> 2. This does not work in the embedded Locator case. If a user configures a
> peer Cache using the following in his/her application...
> {code:java}
> ... = new CacheFactory()
> .set("name", "Example")
> .set("start-locator", "localhost[10334]")
> ...
> .create();
> {code}
> And another members joins, the logic in (2) above, will fail with...
> {code:java}
> Caused by: org.apache.geode.GemFireConfigException: cluster configuration
> service not available
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:1009)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1135)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:771)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:758)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:181)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:231)
> ... 42 more
> Caused by:
> org.apache.geode.internal.process.ClusterConfigurationNotAvailableException:
> Unable to retrieve cluster configuration from the locator.
> at
> org.apache.geode.internal.cache.ClusterConfigurationLoader.requestConfigurationFromLocators(ClusterConfigurationLoader.java:229)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:981)
> ... 47 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-2182) Possible race condition when estimating index size and an entry is destroyed
[ https://issues.apache.org/jira/browse/GEODE-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15729383#comment-15729383 ] ASF subversion and git services commented on GEODE-2182: Commit c2b1c8b1c172073824a8e5c48c45a4285f15e6b1 in geode's branch refs/heads/develop from [~huynhja] [ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=c2b1c8b ] GEODE-2182: try-catch around size estimation for index look ups * Fix possible race condition where entry is destroyed > Possible race condition when estimating index size and an entry is destroyed > > > Key: GEODE-2182 > URL: https://issues.apache.org/jira/browse/GEODE-2182 > Project: Geode > Issue Type: Bug >Reporter: Jason Huynh >Assignee: Jason Huynh > > There is a possible race condition when estimating size of an index and an > entry is destroyed. This doesnt get caught and instead percolates to the top > as an EntryDestroyedException. > A quick work around would be to catch the exception and return 0, this may > lead to an inefficient lookup but the results would be correct. > The better alternative would be to continue iterating if possible. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Nightly geode build artifacts
On Wed, Dec 7, 2016 at 9:34 AM, Kirk Lund wrote: > Does the nightly build produce some sort of binary that users could > download and use? I'm thinking about a specific user that hits a > problematic bug in 1.0.0 but it's fixed on develop for 1.1.0. If the > nightly build produces a downloadable binary then they could try that out > without having to clone the repo and build from sources. Is this what you're looking for: https://repository.apache.org/content/groups/snapshots/org/apache/geode/ ? Thanks, Roman.
[jira] [Commented] (GEODE-2185) Index not used with parameterized query
[ https://issues.apache.org/jira/browse/GEODE-2185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15729422#comment-15729422 ] ASF subversion and git services commented on GEODE-2185: Commit 7fb0e68b130317ac3cce0fa1ca8f39fb0006720f in geode's branch refs/heads/develop from [~huynhja] [ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=7fb0e68 ] GEODE-2185: Index not used with parameterized query > Index not used with parameterized query > --- > > Key: GEODE-2185 > URL: https://issues.apache.org/jira/browse/GEODE-2185 > Project: Geode > Issue Type: Bug > Components: querying >Reporter: Jason Huynh > Fix For: 1.1.0 > > > When a query has parameterized values, indexes that should be used are > currently not used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-2119) gfsh user and password visible in clear text
[
https://issues.apache.org/jira/browse/GEODE-2119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15729433#comment-15729433
]
Kevin Duling commented on GEODE-2119:
-
I've tested the scenarios listed above and found:
# History is redacted.
{code}
/ _/ __/ __/ // /
/ / __/ /___ /_ / _ /
/ /__/ / / _/ / // /
/__/_/ /__/_//_/1.1.0-SNAPSHOT
Monitor and Manage Apache Geode (incubating)
gfsh>history
1 0: start locator --name=loc-sec --classpath=/Users/kduling/foo
--properties-file=./gemfire.properties
2 1: quit
3 2: start locator --name=loc-sec --classpath=/Users/kduling/foo
--security-properties-file=./security.properties
4 3: connect connect --locator=pdx2-office-dhcp9.eng.vmware.com[10334]
5 4: quit
6 5: start server --name=srv-sec
--locators=pdx2-office-dhcp9.eng.vmware.com[10334] --user=admin
--password=* --classpath=/Users/kduling/foo
7 6: quit
8 7: start server --name=srv-sec2
--locators=pdx2-office-dhcp9.eng.vmware.com[10334] --user=admin
--password=* --classpath=/Users/kduling/foo
9 8: start server --name=srv-sec2
--locators=pdx2-office-dhcp9.eng.vmware.com[10334] --user=admin
--password=* --classpath=/Users/kduling/foo --port=40405
10 9: quit
11 10: history
{code}
# Default gfsh_history file and a new one written with --file also is redacted.
# We can't prevent users from using the --password parameter as a command-line
option, but we can recommend against it. Other systems such as postgres,
mysql, oracle, all suffer from this.
Made changes to suppress the password in the log file.
> gfsh user and password visible in clear text
>
>
> Key: GEODE-2119
> URL: https://issues.apache.org/jira/browse/GEODE-2119
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Karen Smoler Miller
>Assignee: Kevin Duling
>
> Both gfsh connect and gfsh start server allow the specification on the
> command line of a user name and a password for use as credentials in
> authentication. Clear text versions of the user name and password are then
> visible
> 1. if the user runs gfsh history
> 2. in historyfile, if the user runs gfsh history --file=historyfile
> 3. in the output of ps
> It would be worth a check to see if clear text versions of the user or
> password end up in any locator or server logs. I don't believe it does for
> gfsh connect, but it might for the start server case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (GEODE-2187) Docs: bad subnav link in REST Apps > Troubleshooting
[ https://issues.apache.org/jira/browse/GEODE-2187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Barnes reassigned GEODE-2187: -- Assignee: Dave Barnes (was: Mark Bretl) > Docs: bad subnav link in REST Apps > Troubleshooting > > > Key: GEODE-2187 > URL: https://issues.apache.org/jira/browse/GEODE-2187 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Minor > > The subnav link for Developing REST apps > Troubleshooting > Key Types and > JSON Support does not connect. Needs to be repaired or removed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (GEODE-2187) Docs: bad subnav link in REST Apps > Troubleshooting
[ https://issues.apache.org/jira/browse/GEODE-2187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Barnes updated GEODE-2187: --- Priority: Minor (was: Major) > Docs: bad subnav link in REST Apps > Troubleshooting > > > Key: GEODE-2187 > URL: https://issues.apache.org/jira/browse/GEODE-2187 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Dave Barnes >Assignee: Mark Bretl >Priority: Minor > > The subnav link for Developing REST apps > Troubleshooting > Key Types and > JSON Support does not connect. Needs to be repaired or removed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (GEODE-2187) Docs: bad subnav link in REST Apps > Troubleshooting
Dave Barnes created GEODE-2187: -- Summary: Docs: bad subnav link in REST Apps > Troubleshooting Key: GEODE-2187 URL: https://issues.apache.org/jira/browse/GEODE-2187 Project: Geode Issue Type: Bug Components: docs Reporter: Dave Barnes Assignee: Mark Bretl The subnav link for Developing REST apps > Troubleshooting > Key Types and JSON Support does not connect. Needs to be repaired or removed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-2187) Docs: bad subnav link in REST Apps > Troubleshooting
[ https://issues.apache.org/jira/browse/GEODE-2187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15729455#comment-15729455 ] ASF subversion and git services commented on GEODE-2187: Commit f58a11d943bbde29a237968a67392e75690698ee in geode's branch refs/heads/develop from [~dbarnes97] [ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=f58a11d ] GEODE-2187: Docs: bad subnav link in REST Apps > Troubleshooting > Docs: bad subnav link in REST Apps > Troubleshooting > > > Key: GEODE-2187 > URL: https://issues.apache.org/jira/browse/GEODE-2187 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Minor > > The subnav link for Developing REST apps > Troubleshooting > Key Types and > JSON Support does not connect. Needs to be repaired or removed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (GEODE-2187) Docs: bad subnav link in REST Apps > Troubleshooting
[ https://issues.apache.org/jira/browse/GEODE-2187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Barnes resolved GEODE-2187. Resolution: Fixed Fix Version/s: 1.1.0 Choice was repair or remove. Target file was short and the subnav link was a singleton, so best solution was to simply remove it. The topic is still easy for the reader to find. > Docs: bad subnav link in REST Apps > Troubleshooting > > > Key: GEODE-2187 > URL: https://issues.apache.org/jira/browse/GEODE-2187 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Minor > Fix For: 1.1.0 > > > The subnav link for Developing REST apps > Troubleshooting > Key Types and > JSON Support does not connect. Needs to be repaired or removed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Nightly geode build artifacts
Close but not quite. The user would need the product tree that would be under geode-assembly/build/install/apache-geode. They would then use geode-assembly/build/install/apache-geode/bin/gfsh to start and stop locators and servers. Thanks, Kirk On Wed, Dec 7, 2016 at 9:59 AM, Roman Shaposhnik wrote: > On Wed, Dec 7, 2016 at 9:34 AM, Kirk Lund wrote: > > Does the nightly build produce some sort of binary that users could > > download and use? I'm thinking about a specific user that hits a > > problematic bug in 1.0.0 but it's fixed on develop for 1.1.0. If the > > nightly build produces a downloadable binary then they could try that out > > without having to clone the repo and build from sources. > > Is this what you're looking for: > https://repository.apache.org/content/groups/snapshots/org/ > apache/geode/ > ? > > Thanks, > Roman. >
Re: Nightly geode build artifacts
On Wed, Dec 7, 2016 at 10:23 AM, Kirk Lund wrote: > Close but not quite. The user would need the product tree that would be > under geode-assembly/build/install/apache-geode. They would then use > geode-assembly/build/install/apache-geode/bin/gfsh to start and stop > locators and servers. Then just make sure the assembly gets deployed to Maven as a regular zip artifact. Pretty easy to do with Gradle. Thanks, Roman.
Re: Nightly geode build artifacts
Yep, that should work well. Thanks! Thanks, Kirk On Wed, Dec 7, 2016 at 10:27 AM, Roman Shaposhnik wrote: > On Wed, Dec 7, 2016 at 10:23 AM, Kirk Lund wrote: > > Close but not quite. The user would need the product tree that would be > > under geode-assembly/build/install/apache-geode. They would then use > > geode-assembly/build/install/apache-geode/bin/gfsh to start and stop > > locators and servers. > > Then just make sure the assembly gets deployed to Maven as a regular > zip artifact. Pretty easy to do with Gradle. > > Thanks, > Roman. >
Re: Nightly geode build artifacts
The nightly build job on jenkins produces both maven SNAPSHOT artifacts as well as distribution archives. We typically don’t advertise those because they are not official releases. However, for testing or integration purposes they can be found at: https://builds.apache.org/job/Geode-nightly/lastSuccessfulBuild/artifact/geode-assembly/build/distributions/ Anthony > On Dec 7, 2016, at 10:33 AM, Kirk Lund wrote: > > Yep, that should work well. Thanks! > > Thanks, > Kirk > > > On Wed, Dec 7, 2016 at 10:27 AM, Roman Shaposhnik > wrote: > >> On Wed, Dec 7, 2016 at 10:23 AM, Kirk Lund wrote: >>> Close but not quite. The user would need the product tree that would be >>> under geode-assembly/build/install/apache-geode. They would then use >>> geode-assembly/build/install/apache-geode/bin/gfsh to start and stop >>> locators and servers. >> >> Then just make sure the assembly gets deployed to Maven as a regular >> zip artifact. Pretty easy to do with Gradle. >> >> Thanks, >> Roman. >>
[jira] [Resolved] (GEODE-2174) Provide more detailed reason when unregistering clients
[
https://issues.apache.org/jira/browse/GEODE-2174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barry Oglesby resolved GEODE-2174.
--
Resolution: Fixed
Fix Version/s: 1.1.0
> Provide more detailed reason when unregistering clients
> ---
>
> Key: GEODE-2174
> URL: https://issues.apache.org/jira/browse/GEODE-2174
> Project: Geode
> Issue Type: Improvement
> Components: client/server
>Reporter: Barry Oglesby
>Assignee: Barry Oglesby
> Fix For: 1.1.0
>
>
> This is the same as GEM-778.
> When a client is unregistered for an abnormal reason, log the reason.
> In previous versions, when a client was unregistered from the server, a
> message like this was logged:
> {noformat}
> [info 2015/01/07 16:19:55.992 JST cache1 Thread 3> tid=0x44] ClientHealthMonitor: Unregistering client with member id
> identity(,connection=1
> {noformat}
> Then, that message was eliminated altogether since it was logged when a
> client left normally as well as abnormally. Now, the request is to add it
> back in for clients who unregister abnormally.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (GEODE-2188) ExampleSecurityManager references SampleSecurityManager in javadoc
Kevin Duling created GEODE-2188:
---
Summary: ExampleSecurityManager references SampleSecurityManager
in javadoc
Key: GEODE-2188
URL: https://issues.apache.org/jira/browse/GEODE-2188
Project: Geode
Issue Type: Bug
Components: core
Reporter: Kevin Duling
Assignee: Mark Bretl
Fix For: 1.1.0
Example code was moved in GEODE-2092, but some strings need to be updated.
Javadoc references an incorrect path.
{{@code security-manager =
org.apache.geode.security.examples.SampleSecurityManager}}
and several strings refer to SampleSecurityManager.
E.g.,
{code}
if (!initializeFromJsonResource(jsonPropertyValue)) {
throw new AuthenticationFailedException(
"SampleSecurityManager: unable to find json resource \"" +
jsonPropertyValue
+ "\" as specified by [" + SECURITY_JSON + "].");
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (GEODE-2188) ExampleSecurityManager references SampleSecurityManager in javadoc
[
https://issues.apache.org/jira/browse/GEODE-2188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Duling updated GEODE-2188:
Priority: Minor (was: Major)
> ExampleSecurityManager references SampleSecurityManager in javadoc
> --
>
> Key: GEODE-2188
> URL: https://issues.apache.org/jira/browse/GEODE-2188
> Project: Geode
> Issue Type: Bug
> Components: core, docs
>Reporter: Kevin Duling
>Assignee: Mark Bretl
>Priority: Minor
> Fix For: 1.1.0
>
>
> Example code was moved in GEODE-2092, but some strings need to be updated.
> Javadoc references an incorrect path.
> {{@code security-manager =
> org.apache.geode.security.examples.SampleSecurityManager}}
> and several strings refer to SampleSecurityManager.
> E.g.,
> {code}
> if (!initializeFromJsonResource(jsonPropertyValue)) {
> throw new AuthenticationFailedException(
> "SampleSecurityManager: unable to find json resource \"" +
> jsonPropertyValue
> + "\" as specified by [" + SECURITY_JSON + "].");
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (GEODE-2188) ExampleSecurityManager references SampleSecurityManager in javadoc
[
https://issues.apache.org/jira/browse/GEODE-2188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Duling reassigned GEODE-2188:
---
Assignee: Kevin Duling (was: Mark Bretl)
> ExampleSecurityManager references SampleSecurityManager in javadoc
> --
>
> Key: GEODE-2188
> URL: https://issues.apache.org/jira/browse/GEODE-2188
> Project: Geode
> Issue Type: Bug
> Components: core, docs
>Reporter: Kevin Duling
>Assignee: Kevin Duling
>Priority: Minor
> Fix For: 1.1.0
>
>
> Example code was moved in GEODE-2092, but some strings need to be updated.
> Javadoc references an incorrect path.
> {{@code security-manager =
> org.apache.geode.security.examples.SampleSecurityManager}}
> and several strings refer to SampleSecurityManager.
> E.g.,
> {code}
> if (!initializeFromJsonResource(jsonPropertyValue)) {
> throw new AuthenticationFailedException(
> "SampleSecurityManager: unable to find json resource \"" +
> jsonPropertyValue
> + "\" as specified by [" + SECURITY_JSON + "].");
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (GEODE-2188) ExampleSecurityManager references SampleSecurityManager in javadoc
[
https://issues.apache.org/jira/browse/GEODE-2188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Duling updated GEODE-2188:
Component/s: docs
> ExampleSecurityManager references SampleSecurityManager in javadoc
> --
>
> Key: GEODE-2188
> URL: https://issues.apache.org/jira/browse/GEODE-2188
> Project: Geode
> Issue Type: Bug
> Components: core, docs
>Reporter: Kevin Duling
>Assignee: Kevin Duling
>Priority: Minor
> Fix For: 1.1.0
>
>
> Example code was moved in GEODE-2092, but some strings need to be updated.
> Javadoc references an incorrect path.
> {{@code security-manager =
> org.apache.geode.security.examples.SampleSecurityManager}}
> and several strings refer to SampleSecurityManager.
> E.g.,
> {code}
> if (!initializeFromJsonResource(jsonPropertyValue)) {
> throw new AuthenticationFailedException(
> "SampleSecurityManager: unable to find json resource \"" +
> jsonPropertyValue
> + "\" as specified by [" + SECURITY_JSON + "].");
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: Matching Unix Committer List And Website Committer List
I have added the rest of the committers from the original list which I could, it shows up correctly in Whimsy but not in the Phonebook yet. There are people on the website list which do not have Apache IDs, so there is still some difference between the two lists. If we don't want to manage two lists, I would suggest since the Apache list is the official list anyone who wants to be listed as a member of the Geode community, have an Apache ID and be added to the Committers list, even if they do not commit 'code'. Thoughts? --Mark On Tue, Dec 6, 2016 at 1:53 PM, Mark Bretl wrote: > Note: Moved to Dev list... > > Hey Dave, > > I am working on adding committers back to the official unix group, which > Whimsy is using. The website will always be a secondary source, however, we > could link to the phonebook instead of listing directly on the website. > Since Whimsy requires credentials, I don't think that would be good choice > > I am working on re-adding committers which are missing from the TLP > transition. > > --Mark > > [1] http://people.apache.org/phonebook.html?unix=geode > > On Tue, Dec 6, 2016 at 1:33 PM, Dave Barnes wrote: > >> The whimsy committers roster differs from the Geode website's Community >> list of committers. Is the website list obsolete, or would there be value >> in updating it to match the whimsy list? (Adopting a 2-list policy incurs >> some overhead going forward..) >> > >
[jira] [Commented] (GEODE-2004) Create/update/delete query through rest api should require DATA:READ instead of DATA:WRITE
[ https://issues.apache.org/jira/browse/GEODE-2004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15729823#comment-15729823 ] Dave Barnes commented on GEODE-2004: Docs updated. > Create/update/delete query through rest api should require DATA:READ instead > of DATA:WRITE > -- > > Key: GEODE-2004 > URL: https://issues.apache.org/jira/browse/GEODE-2004 > Project: Geode > Issue Type: Bug > Components: docs, management, security >Affects Versions: 1.0.0-incubating >Reporter: Jinmei Liao >Assignee: Kevin Duling > Fix For: 1.0.0-incubating > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Matching Unix Committer List And Website Committer List
Not sure how important it is to list committers on the Geode website. I suppose it helps create and sustain the concept of community. The lead-in to the list suggests that the reader may want to join the community, and will be rewarded by seeing their name on the list. I checked out a few other Apache big data project websites (Ambari, Helix and Phoenix). Each has a "Team" link with a list of committers and PMC members. On Wed, Dec 7, 2016 at 12:05 PM, Mark Bretl wrote: > I have added the rest of the committers from the original list which I > could, it shows up correctly in Whimsy but not in the Phonebook yet. There > are people on the website list which do not have Apache IDs, so there is > still some difference between the two lists. > > If we don't want to manage two lists, I would suggest since the Apache list > is the official list anyone who wants to be listed as a member of the Geode > community, have an Apache ID and be added to the Committers list, even if > they do not commit 'code'. > > Thoughts? > > --Mark > > > > On Tue, Dec 6, 2016 at 1:53 PM, Mark Bretl wrote: > > > Note: Moved to Dev list... > > > > Hey Dave, > > > > I am working on adding committers back to the official unix group, which > > Whimsy is using. The website will always be a secondary source, however, > we > > could link to the phonebook instead of listing directly on the website. > > Since Whimsy requires credentials, I don't think that would be good > choice > > > > I am working on re-adding committers which are missing from the TLP > > transition. > > > > --Mark > > > > [1] http://people.apache.org/phonebook.html?unix=geode > > > > On Tue, Dec 6, 2016 at 1:33 PM, Dave Barnes wrote: > > > >> The whimsy committers roster differs from the Geode website's Community > >> list of committers. Is the website list obsolete, or would there be > value > >> in updating it to match the whimsy list? (Adopting a 2-list policy > incurs > >> some overhead going forward..) > >> > > > > >
[jira] [Commented] (GEODE-2004) Create/update/delete query through rest api should require DATA:READ instead of DATA:WRITE
[ https://issues.apache.org/jira/browse/GEODE-2004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15729867#comment-15729867 ] ASF subversion and git services commented on GEODE-2004: Commit 860d7efabc72b3d67406315f5f6baaadc3ff9fd4 in geode's branch refs/heads/develop from [~dbarnes97] [ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=860d7ef ] GEODE-2004: [doc update] Create/update/delete query through rest api should require DATA:READ instead of DATA:WRITE > Create/update/delete query through rest api should require DATA:READ instead > of DATA:WRITE > -- > > Key: GEODE-2004 > URL: https://issues.apache.org/jira/browse/GEODE-2004 > Project: Geode > Issue Type: Bug > Components: docs, management, security >Affects Versions: 1.0.0-incubating >Reporter: Jinmei Liao >Assignee: Kevin Duling > Fix For: 1.0.0-incubating > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Review Request 54499: GEODE-2092 Update docs with security examples location
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/54499/ --- Review request for geode, Dave Barnes, Jinmei Liao, Joey McAllister, and Kevin Duling. Repository: geode Description --- GEODE-2092 Update docs with security examples location Diffs - geode-docs/managing/security/authentication_examples.html.md.erb b7634c851121e60c20b7a138aba32bd2bc002c2e geode-docs/managing/security/authorization_example.html.md.erb 2e725a107986f76a621a85bcdd8711e8b56b63a5 Diff: https://reviews.apache.org/r/54499/diff/ Testing --- Thanks, Karen Miller
[jira] [Resolved] (GEODE-1831) Function gets executed twice on server with gateways if groups are configured
[ https://issues.apache.org/jira/browse/GEODE-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barry Oglesby resolved GEODE-1831. -- Resolution: Fixed Fix Version/s: 1.1.0 > Function gets executed twice on server with gateways if groups are configured > - > > Key: GEODE-1831 > URL: https://issues.apache.org/jira/browse/GEODE-1831 > Project: Geode > Issue Type: Bug > Components: functions >Reporter: Barry Oglesby >Assignee: Barry Oglesby > Fix For: 1.1.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Review Request 54499: GEODE-2092 Update docs with security examples location
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/54499/#review158396 --- Ship it! Ship It! - Joey McAllister On Dec. 7, 2016, 8:59 p.m., Karen Miller wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/54499/ > --- > > (Updated Dec. 7, 2016, 8:59 p.m.) > > > Review request for geode, Dave Barnes, Jinmei Liao, Joey McAllister, and > Kevin Duling. > > > Repository: geode > > > Description > --- > > GEODE-2092 Update docs with security examples location > > > Diffs > - > > geode-docs/managing/security/authentication_examples.html.md.erb > b7634c851121e60c20b7a138aba32bd2bc002c2e > geode-docs/managing/security/authorization_example.html.md.erb > 2e725a107986f76a621a85bcdd8711e8b56b63a5 > > Diff: https://reviews.apache.org/r/54499/diff/ > > > Testing > --- > > > Thanks, > > Karen Miller > >
[GitHub] geode pull request #303: GEODE-1984: Fix Issue Make GatewaySender destroy a ...
Github user jhuynh1 commented on a diff in the pull request: https://github.com/apache/geode/pull/303#discussion_r91360319 --- Diff: geode-wan/src/test/java/org/apache/geode/internal/cache/wan/wancommand/WANCommandTestBase.java --- @@ -448,6 +452,37 @@ public void verifyReceiverCreationWithAttributes(boolean isRunning, int startPor } } + // Added for gateway destroy command + // Copied from WANTestBase.java --- End diff -- Not sure if we need to know this? Perhaps remove the comment --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] geode pull request #303: GEODE-1984: Fix Issue Make GatewaySender destroy a ...
Github user jhuynh1 commented on a diff in the pull request: https://github.com/apache/geode/pull/303#discussion_r91348684 --- Diff: geode-core/src/main/java/org/apache/geode/cache/wan/GatewaySender.java --- @@ -400,4 +400,19 @@ public int getMaxParallelismForReplicatedRegion(); + + /** + * Destroys the GatewaySender. Before destroying the sender, caller needs to to ensure that the --- End diff -- minor grammar: change the "to to" -> "to" --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] geode pull request #303: GEODE-1984: Fix Issue Make GatewaySender destroy a ...
Github user jhuynh1 commented on a diff in the pull request:
https://github.com/apache/geode/pull/303#discussion_r91391868
--- Diff:
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/GatewaySenderDestroyFunction.java
---
@@ -0,0 +1,90 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
contributor license
+ * agreements. See the NOTICE file distributed with this work for
additional information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF
ANY KIND, either express
+ * or implied. See the License for the specific language governing
permissions and limitations under
+ * the License.
+ */
+package org.apache.geode.management.internal.cli.functions;
+
+import org.apache.geode.cache.Cache;
+import org.apache.geode.cache.CacheFactory;
+import org.apache.geode.cache.execute.FunctionAdapter;
+import org.apache.geode.cache.execute.FunctionContext;
+import org.apache.geode.cache.execute.ResultSender;
+import org.apache.geode.cache.wan.GatewaySender;
+import org.apache.geode.internal.InternalEntity;
+import org.apache.geode.internal.cache.wan.GatewaySenderException;
+import org.apache.geode.internal.logging.LogService;
+import org.apache.geode.management.internal.cli.CliUtil;
+import org.apache.geode.management.internal.cli.i18n.CliStrings;
+import org.apache.logging.log4j.Logger;
+
+public class GatewaySenderDestroyFunction extends FunctionAdapter
implements InternalEntity {
+ private static final long serialVersionUID = 1459761440357690134L;
+
+ private static final Logger logger = LogService.getLogger();
+ private static final String ID =
GatewaySenderDestroyFunction.class.getName();
+ public static GatewaySenderDestroyFunction INSTANCE = new
GatewaySenderDestroyFunction();
+
+ @Override
+ public void execute(FunctionContext context) {
+ResultSender resultSender = context.getResultSender();
+
+Cache cache = CacheFactory.getAnyInstance();
+String memberNameOrId =
+
CliUtil.getMemberNameOrId(cache.getDistributedSystem().getDistributedMember());
+
+GatewaySenderDestroyFunctionArgs gatewaySenderDestroyFunctionArgs =
+(GatewaySenderDestroyFunctionArgs) context.getArguments();
+
+try {
+ GatewaySender gatewaySender =
+ cache.getGatewaySender(gatewaySenderDestroyFunctionArgs.getId());
+ if (gatewaySender != null) {
+gatewaySender.stop();
--- End diff --
Is there a way to check to make sure the gateway is actually stopped
first(). I don't think the stop() method is a blocking call and the sender
itself could technically still be running. stop() probably should be changed
to actually stop the sender before returning but I don't think it's the case
today.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] geode pull request #303: GEODE-1984: Fix Issue Make GatewaySender destroy a ...
Github user jhuynh1 commented on a diff in the pull request:
https://github.com/apache/geode/pull/303#discussion_r91390603
--- Diff:
geode-wan/src/test/java/org/apache/geode/internal/cache/wan/wancommand/WanCommandCreateDestroyGatewaySenderDUnitTest.java
---
@@ -55,7 +55,7 @@ private CommandResult
executeCommandWithIgnoredExceptions(String command) {
* GatewaySender with all default attributes
--- End diff --
Would it make sense to create different tests for destroy and keep them
separate from testing create? That way when a test fails we know exactly what
is failing (create vs destroy).
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[jira] [Commented] (GEODE-1984) Make GatewaySender destroy a public API
[
https://issues.apache.org/jira/browse/GEODE-1984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15729983#comment-15729983
]
ASF GitHub Bot commented on GEODE-1984:
---
Github user jhuynh1 commented on a diff in the pull request:
https://github.com/apache/geode/pull/303#discussion_r91390603
--- Diff:
geode-wan/src/test/java/org/apache/geode/internal/cache/wan/wancommand/WanCommandCreateDestroyGatewaySenderDUnitTest.java
---
@@ -55,7 +55,7 @@ private CommandResult
executeCommandWithIgnoredExceptions(String command) {
* GatewaySender with all default attributes
--- End diff --
Would it make sense to create different tests for destroy and keep them
separate from testing create? That way when a test fails we know exactly what
is failing (create vs destroy).
> Make GatewaySender destroy a public API
> ---
>
> Key: GEODE-1984
> URL: https://issues.apache.org/jira/browse/GEODE-1984
> Project: Geode
> Issue Type: New Feature
> Components: wan
>Reporter: Barry Oglesby
>Assignee: Avinash Dongre
>
> The internal {{AbstractGatewaySender}} class has a {{destroy}} API to destroy
> a {{GatewaySender}}. This is currently an internal API. It would be nice to
> make this public by:
> - adding destroy to the {{GatewaySender}} interface
> - provide {{gfsh}} support
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-1984) Make GatewaySender destroy a public API
[
https://issues.apache.org/jira/browse/GEODE-1984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15729981#comment-15729981
]
ASF GitHub Bot commented on GEODE-1984:
---
Github user jhuynh1 commented on a diff in the pull request:
https://github.com/apache/geode/pull/303#discussion_r91360319
--- Diff:
geode-wan/src/test/java/org/apache/geode/internal/cache/wan/wancommand/WANCommandTestBase.java
---
@@ -448,6 +452,37 @@ public void
verifyReceiverCreationWithAttributes(boolean isRunning, int startPor
}
}
+ // Added for gateway destroy command
+ // Copied from WANTestBase.java
--- End diff --
Not sure if we need to know this? Perhaps remove the comment
> Make GatewaySender destroy a public API
> ---
>
> Key: GEODE-1984
> URL: https://issues.apache.org/jira/browse/GEODE-1984
> Project: Geode
> Issue Type: New Feature
> Components: wan
>Reporter: Barry Oglesby
>Assignee: Avinash Dongre
>
> The internal {{AbstractGatewaySender}} class has a {{destroy}} API to destroy
> a {{GatewaySender}}. This is currently an internal API. It would be nice to
> make this public by:
> - adding destroy to the {{GatewaySender}} interface
> - provide {{gfsh}} support
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-1984) Make GatewaySender destroy a public API
[
https://issues.apache.org/jira/browse/GEODE-1984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15729980#comment-15729980
]
ASF GitHub Bot commented on GEODE-1984:
---
Github user jhuynh1 commented on a diff in the pull request:
https://github.com/apache/geode/pull/303#discussion_r91391868
--- Diff:
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/GatewaySenderDestroyFunction.java
---
@@ -0,0 +1,90 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
contributor license
+ * agreements. See the NOTICE file distributed with this work for
additional information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF
ANY KIND, either express
+ * or implied. See the License for the specific language governing
permissions and limitations under
+ * the License.
+ */
+package org.apache.geode.management.internal.cli.functions;
+
+import org.apache.geode.cache.Cache;
+import org.apache.geode.cache.CacheFactory;
+import org.apache.geode.cache.execute.FunctionAdapter;
+import org.apache.geode.cache.execute.FunctionContext;
+import org.apache.geode.cache.execute.ResultSender;
+import org.apache.geode.cache.wan.GatewaySender;
+import org.apache.geode.internal.InternalEntity;
+import org.apache.geode.internal.cache.wan.GatewaySenderException;
+import org.apache.geode.internal.logging.LogService;
+import org.apache.geode.management.internal.cli.CliUtil;
+import org.apache.geode.management.internal.cli.i18n.CliStrings;
+import org.apache.logging.log4j.Logger;
+
+public class GatewaySenderDestroyFunction extends FunctionAdapter
implements InternalEntity {
+ private static final long serialVersionUID = 1459761440357690134L;
+
+ private static final Logger logger = LogService.getLogger();
+ private static final String ID =
GatewaySenderDestroyFunction.class.getName();
+ public static GatewaySenderDestroyFunction INSTANCE = new
GatewaySenderDestroyFunction();
+
+ @Override
+ public void execute(FunctionContext context) {
+ResultSender resultSender = context.getResultSender();
+
+Cache cache = CacheFactory.getAnyInstance();
+String memberNameOrId =
+
CliUtil.getMemberNameOrId(cache.getDistributedSystem().getDistributedMember());
+
+GatewaySenderDestroyFunctionArgs gatewaySenderDestroyFunctionArgs =
+(GatewaySenderDestroyFunctionArgs) context.getArguments();
+
+try {
+ GatewaySender gatewaySender =
+ cache.getGatewaySender(gatewaySenderDestroyFunctionArgs.getId());
+ if (gatewaySender != null) {
+gatewaySender.stop();
--- End diff --
Is there a way to check to make sure the gateway is actually stopped
first(). I don't think the stop() method is a blocking call and the sender
itself could technically still be running. stop() probably should be changed
to actually stop the sender before returning but I don't think it's the case
today.
> Make GatewaySender destroy a public API
> ---
>
> Key: GEODE-1984
> URL: https://issues.apache.org/jira/browse/GEODE-1984
> Project: Geode
> Issue Type: New Feature
> Components: wan
>Reporter: Barry Oglesby
>Assignee: Avinash Dongre
>
> The internal {{AbstractGatewaySender}} class has a {{destroy}} API to destroy
> a {{GatewaySender}}. This is currently an internal API. It would be nice to
> make this public by:
> - adding destroy to the {{GatewaySender}} interface
> - provide {{gfsh}} support
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-1984) Make GatewaySender destroy a public API
[
https://issues.apache.org/jira/browse/GEODE-1984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15729982#comment-15729982
]
ASF GitHub Bot commented on GEODE-1984:
---
Github user jhuynh1 commented on a diff in the pull request:
https://github.com/apache/geode/pull/303#discussion_r91348684
--- Diff:
geode-core/src/main/java/org/apache/geode/cache/wan/GatewaySender.java ---
@@ -400,4 +400,19 @@
public int getMaxParallelismForReplicatedRegion();
+
+ /**
+ * Destroys the GatewaySender. Before destroying the sender, caller
needs to to ensure that the
--- End diff --
minor grammar: change the "to to" -> "to"
> Make GatewaySender destroy a public API
> ---
>
> Key: GEODE-1984
> URL: https://issues.apache.org/jira/browse/GEODE-1984
> Project: Geode
> Issue Type: New Feature
> Components: wan
>Reporter: Barry Oglesby
>Assignee: Avinash Dongre
>
> The internal {{AbstractGatewaySender}} class has a {{destroy}} API to destroy
> a {{GatewaySender}}. This is currently an internal API. It would be nice to
> make this public by:
> - adding destroy to the {{GatewaySender}} interface
> - provide {{gfsh}} support
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] geode pull request #303: GEODE-1984: Fix Issue Make GatewaySender destroy a ...
Github user upthewaterspout commented on a diff in the pull request: https://github.com/apache/geode/pull/303#discussion_r91392448 --- Diff: geode-core/src/main/java/org/apache/geode/cache/wan/GatewaySender.java --- @@ -400,4 +400,19 @@ public int getMaxParallelismForReplicatedRegion(); + + /** + * Destroys the GatewaySender. Before destroying the sender, caller needs to to ensure that the + * sender is stopped so that all the resources (threads, connection pool etc.) will be released + * properly. Stopping the sender is not handled in the destroy. Destroy is carried out in + * following steps: 1. Take the lifeCycleLock. 2. If the sender is attached to any application + * region, throw an exception. 3. Close the GatewaySenderAdvisor. 4. Remove the sender from the + * cache. 5. Destroy the region underlying the GatewaySender. + * + * In case of ParallelGatewaySender, the destroy operation does distributed destroy of the QPR. In + * case of SerialGatewaySender, the queue region is destroyed locally. --- End diff -- Is this still accurate? I see in the code you now call stop before calling destroy, so does the sender still need to be stopped? This looks like it's the internal documentation about what happens. Maybe right something more oriented towards the user for the public method? Also add an @since Geode 1.1 tag. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (GEODE-1984) Make GatewaySender destroy a public API
[
https://issues.apache.org/jira/browse/GEODE-1984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15730007#comment-15730007
]
ASF GitHub Bot commented on GEODE-1984:
---
Github user upthewaterspout commented on a diff in the pull request:
https://github.com/apache/geode/pull/303#discussion_r91393140
--- Diff:
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/GatewaySenderDestroyFunction.java
---
@@ -0,0 +1,90 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
contributor license
+ * agreements. See the NOTICE file distributed with this work for
additional information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF
ANY KIND, either express
+ * or implied. See the License for the specific language governing
permissions and limitations under
+ * the License.
+ */
+package org.apache.geode.management.internal.cli.functions;
+
+import org.apache.geode.cache.Cache;
+import org.apache.geode.cache.CacheFactory;
+import org.apache.geode.cache.execute.FunctionAdapter;
+import org.apache.geode.cache.execute.FunctionContext;
+import org.apache.geode.cache.execute.ResultSender;
+import org.apache.geode.cache.wan.GatewaySender;
+import org.apache.geode.internal.InternalEntity;
+import org.apache.geode.internal.cache.wan.GatewaySenderException;
+import org.apache.geode.internal.logging.LogService;
+import org.apache.geode.management.internal.cli.CliUtil;
+import org.apache.geode.management.internal.cli.i18n.CliStrings;
+import org.apache.logging.log4j.Logger;
+
+public class GatewaySenderDestroyFunction extends FunctionAdapter
implements InternalEntity {
+ private static final long serialVersionUID = 1459761440357690134L;
--- End diff --
Minor nitpick - you can start with the serialVersionUID of 1 for new
classes, you don't have to generate one based on the class. It's fine if you
want to leave it as this though.
> Make GatewaySender destroy a public API
> ---
>
> Key: GEODE-1984
> URL: https://issues.apache.org/jira/browse/GEODE-1984
> Project: Geode
> Issue Type: New Feature
> Components: wan
>Reporter: Barry Oglesby
>Assignee: Avinash Dongre
>
> The internal {{AbstractGatewaySender}} class has a {{destroy}} API to destroy
> a {{GatewaySender}}. This is currently an internal API. It would be nice to
> make this public by:
> - adding destroy to the {{GatewaySender}} interface
> - provide {{gfsh}} support
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] geode pull request #303: GEODE-1984: Fix Issue Make GatewaySender destroy a ...
Github user upthewaterspout commented on a diff in the pull request:
https://github.com/apache/geode/pull/303#discussion_r91393140
--- Diff:
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/GatewaySenderDestroyFunction.java
---
@@ -0,0 +1,90 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
contributor license
+ * agreements. See the NOTICE file distributed with this work for
additional information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF
ANY KIND, either express
+ * or implied. See the License for the specific language governing
permissions and limitations under
+ * the License.
+ */
+package org.apache.geode.management.internal.cli.functions;
+
+import org.apache.geode.cache.Cache;
+import org.apache.geode.cache.CacheFactory;
+import org.apache.geode.cache.execute.FunctionAdapter;
+import org.apache.geode.cache.execute.FunctionContext;
+import org.apache.geode.cache.execute.ResultSender;
+import org.apache.geode.cache.wan.GatewaySender;
+import org.apache.geode.internal.InternalEntity;
+import org.apache.geode.internal.cache.wan.GatewaySenderException;
+import org.apache.geode.internal.logging.LogService;
+import org.apache.geode.management.internal.cli.CliUtil;
+import org.apache.geode.management.internal.cli.i18n.CliStrings;
+import org.apache.logging.log4j.Logger;
+
+public class GatewaySenderDestroyFunction extends FunctionAdapter
implements InternalEntity {
+ private static final long serialVersionUID = 1459761440357690134L;
--- End diff --
Minor nitpick - you can start with the serialVersionUID of 1 for new
classes, you don't have to generate one based on the class. It's fine if you
want to leave it as this though.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[jira] [Commented] (GEODE-1984) Make GatewaySender destroy a public API
[
https://issues.apache.org/jira/browse/GEODE-1984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15730008#comment-15730008
]
ASF GitHub Bot commented on GEODE-1984:
---
Github user upthewaterspout commented on a diff in the pull request:
https://github.com/apache/geode/pull/303#discussion_r91392448
--- Diff:
geode-core/src/main/java/org/apache/geode/cache/wan/GatewaySender.java ---
@@ -400,4 +400,19 @@
public int getMaxParallelismForReplicatedRegion();
+
+ /**
+ * Destroys the GatewaySender. Before destroying the sender, caller
needs to to ensure that the
+ * sender is stopped so that all the resources (threads, connection pool
etc.) will be released
+ * properly. Stopping the sender is not handled in the destroy. Destroy
is carried out in
+ * following steps: 1. Take the lifeCycleLock. 2. If the sender is
attached to any application
+ * region, throw an exception. 3. Close the GatewaySenderAdvisor. 4.
Remove the sender from the
+ * cache. 5. Destroy the region underlying the GatewaySender.
+ *
+ * In case of ParallelGatewaySender, the destroy operation does
distributed destroy of the QPR. In
+ * case of SerialGatewaySender, the queue region is destroyed locally.
--- End diff --
Is this still accurate? I see in the code you now call stop before calling
destroy, so does the sender still need to be stopped?
This looks like it's the internal documentation about what happens. Maybe
right something more oriented towards the user for the public method?
Also add an @since Geode 1.1 tag.
> Make GatewaySender destroy a public API
> ---
>
> Key: GEODE-1984
> URL: https://issues.apache.org/jira/browse/GEODE-1984
> Project: Geode
> Issue Type: New Feature
> Components: wan
>Reporter: Barry Oglesby
>Assignee: Avinash Dongre
>
> The internal {{AbstractGatewaySender}} class has a {{destroy}} API to destroy
> a {{GatewaySender}}. This is currently an internal API. It would be nice to
> make this public by:
> - adding destroy to the {{GatewaySender}} interface
> - provide {{gfsh}} support
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-2119) gfsh user and password visible in clear text
[
https://issues.apache.org/jira/browse/GEODE-2119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15730051#comment-15730051
]
Kevin Duling commented on GEODE-2119:
-
Also suppressing password within scripts such as {{gfsh run
--file=startServer.gfsh}}
{code}
1. Executing - start server --name=srv-sec2
--locators=pdx2-office-dhcp9.eng.vmware.com[10334] --user=admin
--password= --classpath=/Users/kduling/foo
.
Server in /Users/kduling/tmp/srv-sec2 on
pdx2-office-dhcp9.eng.vmware.com[40404] as srv-sec2 is currently online.
Process ID: 13259
Uptime: 2 seconds
GemFire Version: 1.1.0-SNAPSHOT
Java Version: 1.8.0_92
Log File: /Users/kduling/tmp/srv-sec2/srv-sec2.log
JVM Arguments: -Dgemfire.security-username=admin
-Dgemfire.locators=pdx2-office-dhcp9.eng.vmware.com[10334]
-Dgemfire.use-cluster-configuration=true -Dgemfire.security-password=
-Dgemfire.start-dev-rest-api=false -XX:OnOutOfMemoryError=kill -KILL %p
-Dgemfire.launcher.registerSignalHandlers=true -Djava.awt.headless=true
-Dsun.rmi.dgc.server.gcInterval=9223372036854775806
Class-Path:
/Users/kduling/Dev/pivotal/gemfire/open/geode-assembly/build/install/apache-geode/lib/geode-core-1.1.0-SNAPSHOT.jar:/Users/kduling/foo:/Users/kduling/Dev/pivotal/gemfire/open/geode-assembly/build/install/apache-geode/lib/geode-dependencies.jar
{code}
> gfsh user and password visible in clear text
>
>
> Key: GEODE-2119
> URL: https://issues.apache.org/jira/browse/GEODE-2119
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Karen Smoler Miller
>Assignee: Kevin Duling
>
> Both gfsh connect and gfsh start server allow the specification on the
> command line of a user name and a password for use as credentials in
> authentication. Clear text versions of the user name and password are then
> visible
> 1. if the user runs gfsh history
> 2. in historyfile, if the user runs gfsh history --file=historyfile
> 3. in the output of ps
> It would be worth a check to see if clear text versions of the user or
> password end up in any locator or server logs. I don't believe it does for
> gfsh connect, but it might for the start server case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: Review Request 54499: GEODE-2092 Update docs with security examples location
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/54499/#review158412 --- Ship it! Ship It! - Kevin Duling On Dec. 7, 2016, 12:59 p.m., Karen Miller wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/54499/ > --- > > (Updated Dec. 7, 2016, 12:59 p.m.) > > > Review request for geode, Dave Barnes, Jinmei Liao, Joey McAllister, and > Kevin Duling. > > > Repository: geode > > > Description > --- > > GEODE-2092 Update docs with security examples location > > > Diffs > - > > geode-docs/managing/security/authentication_examples.html.md.erb > b7634c851121e60c20b7a138aba32bd2bc002c2e > geode-docs/managing/security/authorization_example.html.md.erb > 2e725a107986f76a621a85bcdd8711e8b56b63a5 > > Diff: https://reviews.apache.org/r/54499/diff/ > > > Testing > --- > > > Thanks, > > Karen Miller > >
[jira] [Commented] (GEODE-2092) Security examples should not be in product package
[ https://issues.apache.org/jira/browse/GEODE-2092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15730108#comment-15730108 ] ASF subversion and git services commented on GEODE-2092: Commit 22ec6a789a1cbf64e1d7677078558e17efb0c668 in geode's branch refs/heads/develop from [~karensmolermiller] [ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=22ec6a7 ] GEODE-2092 Update docs with security examples location > Security examples should not be in product package > -- > > Key: GEODE-2092 > URL: https://issues.apache.org/jira/browse/GEODE-2092 > Project: Geode > Issue Type: Bug > Components: docs, security >Affects Versions: 1.0.0-incubating >Reporter: Kirk Lund >Assignee: Kevin Duling > > These three classes are currently in geode-core product package which implies > they are fully supported user API. They cannot be released in a user API > package. > 1) Move the security examples to examples package within geode-core > * > geode-core/src/main/java/org/apache/geode/security/templates/SampleSecurityManager.java > * > geode-core/src/main/java/org/apache/geode/security/templates/SamplePostProcessor.java > To: > * > geode-core/src/main/java/org/apache/geode/security/examples/ExampleSecurityManager.java > * > geode-core/src/main/java/org/apache/geode/security/examples/ExamplePostProcessor.java > Delete this one (it should only exist in some GitHub application for demoing): > * > geode-core/src/main/java/org/apache/geode/security/templates/SimpleSecurityManager.java > 2) We have geode-core tests that use the security examples. These tests must > be altered to use new classes that implement SecurityManager and > PostProcessor. These new classes need to live under > geode-core/src/tests/java/org/apache/geode/security. > I also see > geode-assembly/src/test/java/org/apache/geode/rest/internal/web/controllers/RedactingPostProcessor.java > with javadocs indicating that it is an example. Either a) remove the > javadocs saying it's an example or b) move it to > geode-core/src/main/java/org/apache/geode/security/examples and then create a > new implementation of PostProcessor which the rest tests will use. > End results should be: > a) all examples live in either geode-examples or > geode-core/src/main/java/org/apache/geode/security/examples > b) no tests should be using the examples, they should be using test specific > implementations under geode-core/src/tests/java > c) no demoing code should be GEODE -- such code belongs in GitHub or other > project repos -- for a really good example, please see: > * https://github.com/spring-projects/spring-gemfire-examples > * > https://github.com/spring-projects/spring-gemfire-examples/tree/master/quickstart/repository > If anyone needs help creating an example repo outside of GEODE, then please > discuss this on geode dev mailing list. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (GEODE-2185) Index not used with parameterized query
[ https://issues.apache.org/jira/browse/GEODE-2185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Huynh resolved GEODE-2185. Resolution: Fixed > Index not used with parameterized query > --- > > Key: GEODE-2185 > URL: https://issues.apache.org/jira/browse/GEODE-2185 > Project: Geode > Issue Type: Bug > Components: querying >Reporter: Jason Huynh >Assignee: Jason Huynh > Fix For: 1.1.0 > > > When a query has parameterized values, indexes that should be used are > currently not used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (GEODE-2185) Index not used with parameterized query
[ https://issues.apache.org/jira/browse/GEODE-2185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Huynh reassigned GEODE-2185: -- Assignee: Jason Huynh > Index not used with parameterized query > --- > > Key: GEODE-2185 > URL: https://issues.apache.org/jira/browse/GEODE-2185 > Project: Geode > Issue Type: Bug > Components: querying >Reporter: Jason Huynh >Assignee: Jason Huynh > Fix For: 1.1.0 > > > When a query has parameterized values, indexes that should be used are > currently not used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (GEODE-2002) The index is not used on a query with a where clause containing a parameterized key on a map
[
https://issues.apache.org/jira/browse/GEODE-2002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Huynh resolved GEODE-2002.
Resolution: Duplicate
Fix Version/s: 1.1.0
> The index is not used on a query with a where clause containing a
> parameterized key on a map
>
>
> Key: GEODE-2002
> URL: https://issues.apache.org/jira/browse/GEODE-2002
> Project: Geode
> Issue Type: Bug
> Components: querying
>Reporter: Barry Oglesby
> Fix For: 1.1.0
>
>
> This is the same as GEM-1026.
> If an index is defined like:
> {noformat}
>
> {noformat}
> And a query is defined like:
> {noformat}
> select i from from /instrument i, i.tradingLines t where
> t.alternateReferences[$1]='BFNY8K9' with bind parameter 'SEDOL'.
> {noformat}
> Then, the {{instrumentTLAltIdIndex}} index won't be used when the query is
> executed.
> The message logged in the server log looks like (with {{indexesUsed(0)}}
> instead of {{indexesUsed(1)}}):
> {noformat}
> [info 2016/10/14 14:51:03.069 PDT
> tid=0x3e] Query Executed in 3.645424 ms; rowCount = 14; indexesUsed(0)
> " select i from /instrument i, i.tradingLines t where
> t.alternateReferences[$1]='BFNY8K9'"
> {noformat}
> The {{CompiledIndexOperation generateCanonicalizedExpression}} method returns
> {{index_iter2.alternateReferences\[$1\]}} instead of
> {{index_iter2.alternateReferences\['INHOUSE_SEDOL'\]}}, and the
> {{AbstractMapIndex isMatchingWithIndexExpression}} method fails to match the
> index.
> The {{$1}} is generated by CompiledBindArgument
> generateCanonicalizedExpression.
> Also, note that the trace logging is incorrect on any query using a map index.
> The static query is defined like:
> {noformat}
> select i from from /instrument i, i.tradingLines t where
> t.alternateReferences['SEDOL']='BFNY8K9'
> {noformat}
> This logs a message in the server log like:
> {noformat}
> [info 2016/10/14 14:29:58.145 PDT
> tid=0x3c] Query Executed in 54.36587 ms; rowCount = 16;
> indexesUsed(1):instrumentTLAltIdIndex-SEDOL(Results: 0) " select i
> from /instrument i, i.tradingLines t where
> t.alternateReferences['SEDOL']='BFNY8K9'"
> {noformat}
> The {{Results: 0}} part of the message is wrong. It should be {{Results: 16}}.
> The {{IndexTrackingQueryObserver beforeIndexLookup}} method saves the
> {{IndexInfo}} at {{key=instrumentTLAltIdIndex-SEDOL}}, but the
> {{afterIndexLookup}} method attempts to retrieve it using
> {{key=instrumentTLAltIdIndex}}. The {{IndexInfo}} is not found, so its
> results are not updated.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (GEODE-1984) Make GatewaySender destroy a public API
[
https://issues.apache.org/jira/browse/GEODE-1984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karen Smoler Miller updated GEODE-1984:
---
Component/s: docs
> Make GatewaySender destroy a public API
> ---
>
> Key: GEODE-1984
> URL: https://issues.apache.org/jira/browse/GEODE-1984
> Project: Geode
> Issue Type: New Feature
> Components: docs, wan
>Reporter: Barry Oglesby
>Assignee: Avinash Dongre
>
> The internal {{AbstractGatewaySender}} class has a {{destroy}} API to destroy
> a {{GatewaySender}}. This is currently an internal API. It would be nice to
> make this public by:
> - adding destroy to the {{GatewaySender}} interface
> - provide {{gfsh}} support
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-2004) Create/update/delete query through rest api should require DATA:READ instead of DATA:WRITE
[ https://issues.apache.org/jira/browse/GEODE-2004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15730157#comment-15730157 ] ASF subversion and git services commented on GEODE-2004: Commit 1d34eeb9f6217a4375590094166e5b81a820abae in geode's branch refs/heads/develop from [~dbarnes97] [ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=1d34eeb ] GEODE-2004: [doc update] change to a permission for REST-initiated queries. Updated error messages. > Create/update/delete query through rest api should require DATA:READ instead > of DATA:WRITE > -- > > Key: GEODE-2004 > URL: https://issues.apache.org/jira/browse/GEODE-2004 > Project: Geode > Issue Type: Bug > Components: docs, management, security >Affects Versions: 1.0.0-incubating >Reporter: Jinmei Liao >Assignee: Kevin Duling > Fix For: 1.0.0-incubating > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (GEODE-2189) Docs: Update Swagger UI links
Dave Barnes created GEODE-2189: -- Summary: Docs: Update Swagger UI links Key: GEODE-2189 URL: https://issues.apache.org/jira/browse/GEODE-2189 Project: Geode Issue Type: Bug Components: docs Reporter: Dave Barnes Assignee: Mark Bretl In the User Manual, at the bottom of the section Developing REST Applications -> Using the Swagger UI, there are two links, one to "more info" and one to the "Swagger specification". The first one no longer connects to anything, the second connects to a target that may be incorrect. Need to review and update these links with their correct values. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (GEODE-2189) Docs: Update Swagger UI links
[ https://issues.apache.org/jira/browse/GEODE-2189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Barnes updated GEODE-2189: --- Priority: Minor (was: Major) > Docs: Update Swagger UI links > - > > Key: GEODE-2189 > URL: https://issues.apache.org/jira/browse/GEODE-2189 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Dave Barnes >Assignee: Mark Bretl >Priority: Minor > > In the User Manual, at the bottom of the section Developing REST Applications > -> Using the Swagger UI, there are two links, one to "more info" and one to > the "Swagger specification". The first one no longer connects to anything, > the second connects to a target that may be incorrect. > Need to review and update these links with their correct values. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-734) gfsh export stack-traces should not require an output file with extension .txt
[
https://issues.apache.org/jira/browse/GEODE-734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15730216#comment-15730216
]
ASF subversion and git services commented on GEODE-734:
---
Commit 2c5a0a1688b821f95584ef4b6610c65d0433d2e7 in geode's branch
refs/heads/feature/GEODE-734 from [~deepakddixit]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=2c5a0a16 ]
GEODE-734: Remove txt file restriction when exporting stack traces
Adding throws clause to signature instead of catching it in Test.
Separating test scenarios into multiple test cases. Creating files in
TemporaryFolder.
Applying spotless checks
Updated export stack-traces in controller. Removed compulsory file
option. If file is not provided then name is generated. Added one
boolean option fail-if-file-present, if true and file already exists
then command will fail.
Updated Offline help file.
Added test cases to verify new added options
Removed compulsory file option. If file is not provided then name is
generated. Added one boolean option fail-if-file-present, if true and
file already exists then command will fail.
Added message warning user about possible overwrite of file if already
present.
Added test to check if non txt extension file is allowed.
This closes #297
> gfsh export stack-traces should not require an output file with extension .txt
> --
>
> Key: GEODE-734
> URL: https://issues.apache.org/jira/browse/GEODE-734
> Project: Geode
> Issue Type: Improvement
> Components: gfsh
>Reporter: Jens Deppe
>
> gfsh {{export stack-traces}} requires a file with a {{.txt}} extension:
> {noformat}
> gfsh>export stack-traces --file=/tmp/trace.log
> Invalid file type, the file extension must be ".txt"
> {noformat}
> This seems like a totally arbitrary restriction. Please can it be removed.
> If the concern is that an existing file might be overwritten then we should
> have a user prompt indicating that.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] geode issue #297: GEODE-734: gfsh export stack-traces should not require an ...
Github user kirklund commented on the issue: https://github.com/apache/geode/pull/297 I created feature/GEODE-734 branch and pulled in all changes. I also did a git rebase and combined all commits into a single commit: commit 2c5a0a1688b821f95584ef4b6610c65d0433d2e7 Author: Deepak Dixit Date: Sat Nov 26 19:11:52 2016 +0530 GEODE-734: Remove txt file restriction when exporting stack traces Adding throws clause to signature instead of catching it in Test. Separating test scenarios into multiple test cases. Creating files in TemporaryFolder. Applying spotless checks Updated export stack-traces in controller. Removed compulsory file option. If file is not provided then name is generated. Added one boolean option fail-if-file-present, if true and file already exists then command will fail. Updated Offline help file. Added test cases to verify new added options Removed compulsory file option. If file is not provided then name is generated. Added one boolean option fail-if-file-present, if true and file already exists then command will fail. Added message warning user about possible overwrite of file if already present. Added test to check if non txt extension file is allowed. This closes #297 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (GEODE-734) gfsh export stack-traces should not require an output file with extension .txt
[
https://issues.apache.org/jira/browse/GEODE-734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15730227#comment-15730227
]
ASF GitHub Bot commented on GEODE-734:
--
Github user kirklund commented on the issue:
https://github.com/apache/geode/pull/297
I created feature/GEODE-734 branch and pulled in all changes. I also did a
git rebase and combined all commits into a single commit:
commit 2c5a0a1688b821f95584ef4b6610c65d0433d2e7
Author: Deepak Dixit
Date: Sat Nov 26 19:11:52 2016 +0530
GEODE-734: Remove txt file restriction when exporting stack traces
Adding throws clause to signature instead of catching it in Test.
Separating test scenarios into multiple test cases. Creating files in
TemporaryFolder.
Applying spotless checks
Updated export stack-traces in controller. Removed compulsory file
option. If file is not provided then name is generated. Added one
boolean option fail-if-file-present, if true and file already exists
then command will fail.
Updated Offline help file.
Added test cases to verify new added options
Removed compulsory file option. If file is not provided then name is
generated. Added one boolean option fail-if-file-present, if true and
file already exists then command will fail.
Added message warning user about possible overwrite of file if already
present.
Added test to check if non txt extension file is allowed.
This closes #297
> gfsh export stack-traces should not require an output file with extension .txt
> --
>
> Key: GEODE-734
> URL: https://issues.apache.org/jira/browse/GEODE-734
> Project: Geode
> Issue Type: Improvement
> Components: gfsh
>Reporter: Jens Deppe
>
> gfsh {{export stack-traces}} requires a file with a {{.txt}} extension:
> {noformat}
> gfsh>export stack-traces --file=/tmp/trace.log
> Invalid file type, the file extension must be ".txt"
> {noformat}
> This seems like a totally arbitrary restriction. Please can it be removed.
> If the concern is that an existing file might be overwritten then we should
> have a user prompt indicating that.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Review Request 54503: GEODE-2186: Changing the pulse gateway status to only look at running status
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/54503/ --- Review request for geode, Barry Oglesby and xiaojian zhou. Repository: geode Description --- Gateway senders may or may not be connected, depending on what is going on with the underlying queue. If a sender is a secondary, it may be disconnected because it doesn't need to send anything. Even primaries may be disconnected for periods of time if the connection is lost when there is nothing in the queue. Diffs - geode-core/src/main/java/org/apache/geode/management/internal/beans/DistributedSystemBridge.java 3016277715864b4b66b25d9dcffc8ef7053e5467 geode-wan/src/test/java/org/apache/geode/management/WANManagementDUnitTest.java 9a6cc104a1368fa762bffd1efa1978f007819604 Diff: https://reviews.apache.org/r/54503/diff/ Testing --- Thanks, Dan Smith
[jira] [Commented] (GEODE-2179) GatewaySenderMBeans isConnected flag does not notice if a connection is destroyed
[
https://issues.apache.org/jira/browse/GEODE-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15730278#comment-15730278
]
ASF subversion and git services commented on GEODE-2179:
Commit 0494b31caf6f43cec85660fd8d939f2b1c6739c2 in geode's branch
refs/heads/develop from [~upthewaterspout]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=0494b31 ]
GEODE-2179 - Checking for disconnected connection in GatewaySenderMBean
Making sure that the mbean returns false for isConnected if the gateway
is not actually connected to the remote side.
> GatewaySenderMBeans isConnected flag does not notice if a connection is
> destroyed
> -
>
> Key: GEODE-2179
> URL: https://issues.apache.org/jira/browse/GEODE-2179
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Dan Smith
>Assignee: Amey Barve
>
> The GatewaySenderMBean has a method called isConnected which ultimately calls
> this code in GatewaySenderEventRemoteDispatcher
> {code}
> @Override
> public boolean isConnectedToRemote() {
> return connection != null;
> }
> {code}
> However, this doesn't take into account that the connection may be destroyed,
> but not null. Therefore the mbean can incorrectly indicate that the sender is
> connected.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (GEODE-2179) GatewaySenderMBeans isConnected flag does not notice if a connection is destroyed
[
https://issues.apache.org/jira/browse/GEODE-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith resolved GEODE-2179.
--
Resolution: Fixed
Fix Version/s: 1.1.0
> GatewaySenderMBeans isConnected flag does not notice if a connection is
> destroyed
> -
>
> Key: GEODE-2179
> URL: https://issues.apache.org/jira/browse/GEODE-2179
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Dan Smith
>Assignee: Dan Smith
> Fix For: 1.1.0
>
>
> The GatewaySenderMBean has a method called isConnected which ultimately calls
> this code in GatewaySenderEventRemoteDispatcher
> {code}
> @Override
> public boolean isConnectedToRemote() {
> return connection != null;
> }
> {code}
> However, this doesn't take into account that the connection may be destroyed,
> but not null. Therefore the mbean can incorrectly indicate that the sender is
> connected.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (GEODE-2179) GatewaySenderMBeans isConnected flag does not notice if a connection is destroyed
[
https://issues.apache.org/jira/browse/GEODE-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith reassigned GEODE-2179:
Assignee: Dan Smith (was: Amey Barve)
> GatewaySenderMBeans isConnected flag does not notice if a connection is
> destroyed
> -
>
> Key: GEODE-2179
> URL: https://issues.apache.org/jira/browse/GEODE-2179
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Dan Smith
>Assignee: Dan Smith
> Fix For: 1.1.0
>
>
> The GatewaySenderMBean has a method called isConnected which ultimately calls
> this code in GatewaySenderEventRemoteDispatcher
> {code}
> @Override
> public boolean isConnectedToRemote() {
> return connection != null;
> }
> {code}
> However, this doesn't take into account that the connection may be destroyed,
> but not null. Therefore the mbean can incorrectly indicate that the sender is
> connected.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] geode issue #297: GEODE-734: gfsh export stack-traces should not require an ...
Github user kirklund commented on the issue: https://github.com/apache/geode/pull/297 I'm running precheckin again just to make sure. Precheckin should be done in about 3 hours and if that looks clean I'll merge this to develop. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (GEODE-734) gfsh export stack-traces should not require an output file with extension .txt
[
https://issues.apache.org/jira/browse/GEODE-734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15730287#comment-15730287
]
ASF GitHub Bot commented on GEODE-734:
--
Github user kirklund commented on the issue:
https://github.com/apache/geode/pull/297
I'm running precheckin again just to make sure. Precheckin should be done
in about 3 hours and if that looks clean I'll merge this to develop.
> gfsh export stack-traces should not require an output file with extension .txt
> --
>
> Key: GEODE-734
> URL: https://issues.apache.org/jira/browse/GEODE-734
> Project: Geode
> Issue Type: Improvement
> Components: gfsh
>Reporter: Jens Deppe
>
> gfsh {{export stack-traces}} requires a file with a {{.txt}} extension:
> {noformat}
> gfsh>export stack-traces --file=/tmp/trace.log
> Invalid file type, the file extension must be ".txt"
> {noformat}
> This seems like a totally arbitrary restriction. Please can it be removed.
> If the concern is that an existing file might be overwritten then we should
> have a user prompt indicating that.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-1027) MBeans should be initialized with current stats when they are created.
[ https://issues.apache.org/jira/browse/GEODE-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15730299#comment-15730299 ] ASF subversion and git services commented on GEODE-1027: Commit 951e99576380119390752570849ec1947374aa37 in geode's branch refs/heads/feature/GEODE-1027 from [~apa...@the9muses.net] [ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=951e995 ] GEODE-1027: add unit test for previously committed fix > MBeans should be initialized with current stats when they are created. > -- > > Key: GEODE-1027 > URL: https://issues.apache.org/jira/browse/GEODE-1027 > Project: Geode > Issue Type: Improvement > Components: jmx >Affects Versions: 1.0.0-incubating >Reporter: Jens Deppe >Assignee: Kirk Lund > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] geode issue #304: GEODE-1835: A message logged by the configure pdx command ...
Github user kirklund commented on the issue: https://github.com/apache/geode/pull/304 I'm merging this to a local branch right now. After I run precheckin it should be ready to commit to develop. I'm anticipating committing it later this evening or tomorrow morning. Thanks! --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (GEODE-1835) A message logged by the configure pdx command is incorrect
[
https://issues.apache.org/jira/browse/GEODE-1835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15730319#comment-15730319
]
ASF GitHub Bot commented on GEODE-1835:
---
Github user kirklund commented on the issue:
https://github.com/apache/geode/pull/304
I'm merging this to a local branch right now. After I run precheckin it
should be ready to commit to develop. I'm anticipating committing it later this
evening or tomorrow morning. Thanks!
> A message logged by the configure pdx command is incorrect
> --
>
> Key: GEODE-1835
> URL: https://issues.apache.org/jira/browse/GEODE-1835
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Barry Oglesby
>Assignee: Amey Barve
>
> The message below is only logged when there are no members. Instead, it
> should be logged when there are members.
> {noformat}
> The command would only take effect on new data members joining the
> distributed system. It won't affect the existing data members
> {noformat}
> The condition in {{PDXCommands.configurePDX}} is:
> {noformat}
> if (CliUtil.getAllNormalMembers(CliUtil.getCacheIfExists()).isEmpty()) {
> ird.addLine(CliStrings.CONFIGURE_PDX__NORMAL__MEMBERS__WARNING);
> }
> {noformat}
> It should test for {{!isEmpty}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-2109) calling submit on ExecutionService can cause exceptions to be lost
[ https://issues.apache.org/jira/browse/GEODE-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15730340#comment-15730340 ] ASF GitHub Bot commented on GEODE-2109: --- Github user upthewaterspout commented on the issue: https://github.com/apache/geode/pull/296 I looking at pulling this, and I see what one of the unit tests failed for me. It's failing intermittently in the IDE: SingleHopClientExecutorSubmitTaskWithExceptionTest.submittedTaskShouldLogFailure java.lang.RuntimeException: I am expecting this to be logged at org.apache.geode.cache.client.internal.SingleHopClientExecutorSubmitTaskWithExceptionTest$1.run(SingleHopClientExecutorSubmitTaskWithExceptionTest.java:52) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) > calling submit on ExecutionService can cause exceptions to be lost > -- > > Key: GEODE-2109 > URL: https://issues.apache.org/jira/browse/GEODE-2109 > Project: Geode > Issue Type: Bug > Components: regions >Reporter: Darrel Schneider > > Geode has a number of places that call submit on ExecutionService. The submit > method returns a Future object. If the caller makes sure it calls "get" on > the Future then all is well. But in many places geode is not calling get. In > that case if the Runnable that was submitted throws an exception it gets > stored in the get and never logged. This can make it very hard to diagnose > problems. > If the caller does not want to call get on the returned Future then it should > instead call the "execute" method. In that case the exception will be > unhandled and the unhandled exception handler code we have on the > LoggingThreadGroup class will cause the exception to be logged. > Here are the places that should be changed to use execute instead of submit: > org.apache.geode.internal.util.concurrent.CustomEntryConcurrentHashMap.clear() > org.apache.geode.internal.cache.DiskStoreImpl.executeDiskStoreTask(Runnable) > org.apache.geode.internal.cache.lru.HeapEvictor.onEvent(MemoryEvent) > org.apache.geode.distributed.internal.InternalLocator.restartWithDS(InternalDistributedSystem, > GemFireCacheImpl) > org.apache.geode.distributed.internal.FunctionExecutionPooledExecutor.FunctionExecutionPooledExecutor(BlockingQueue, > int, PoolStatHelper, ThreadFactory, int, boolean) > org.apache.geode.internal.cache.PRHARedundancyProvider.scheduleCreateMissingBuckets() > org.apache.geode.distributed.internal.InternalLocator.startSharedConfigurationService(GemFireCacheImpl) > org.apache.geode.cache.client.internal.SingleHopClientExecutor.submitTask(Runnable) > org.apache.geode.management.internal.FederatingManager.submitTask(Callable) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] geode issue #296: GEODE-2109 : Calling submit on ExecutionService can cause ...
Github user upthewaterspout commented on the issue: https://github.com/apache/geode/pull/296 I looking at pulling this, and I see what one of the unit tests failed for me. It's failing intermittently in the IDE: SingleHopClientExecutorSubmitTaskWithExceptionTest.submittedTaskShouldLogFailure java.lang.RuntimeException: I am expecting this to be logged at org.apache.geode.cache.client.internal.SingleHopClientExecutorSubmitTaskWithExceptionTest$1.run(SingleHopClientExecutorSubmitTaskWithExceptionTest.java:52) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (GEODE-2112) UITests are failing due to insufficient tearDown
[
https://issues.apache.org/jira/browse/GEODE-2112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15730342#comment-15730342
]
ASF subversion and git services commented on GEODE-2112:
Commit 67dafd8e81738a32e2fbf0140f310c9936346a20 in geode's branch
refs/heads/develop from [~jstewart]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=67dafd8 ]
GEODE-2112: UITests actually take screenshots on failure
This closes #301
> UITests are failing due to insufficient tearDown
>
>
> Key: GEODE-2112
> URL: https://issues.apache.org/jira/browse/GEODE-2112
> Project: Geode
> Issue Type: Bug
> Components: pulse, tests
>Reporter: Kirk Lund
>Assignee: Jared Stewart
> Fix For: 1.1.0
>
>
> UITests are failing due to insufficient tearDown
> {noformat}
> INFO: Connecting to jmxURL :
> service:jmx:rmi://localhost/jndi/rmi://localhost:/jmxrmi
> [info 2016/11/14 15:51:15.940 PST
> tid=0x14] Logging in admin
> [warn 2016/11/14 15:51:15.940 PST
> tid=0x14] Authentication failed for token submission
> [org.apache.geode.internal.security.shiro.GeodeAuthenticationToken - admin,
> rememberMe=false]. Possible unexpected error? (Typical or expected login
> exceptions should extend from AuthenticationException).
> org.apache.geode.security.AuthenticationFailedException:
> SampleSecurityManager: wrong username/password
> at
> org.apache.geode.security.templates.SampleSecurityManager.authenticate(SampleSecurityManager.java:146)
> at
> org.apache.geode.internal.security.shiro.CustomAuthRealm.doGetAuthenticationInfo(CustomAuthRealm.java:66)
> at
> org.apache.shiro.realm.AuthenticatingRealm.getAuthenticationInfo(AuthenticatingRealm.java:568)
> at
> org.apache.shiro.authc.pam.ModularRealmAuthenticator.doSingleRealmAuthentication(ModularRealmAuthenticator.java:180)
> at
> org.apache.shiro.authc.pam.ModularRealmAuthenticator.doAuthenticate(ModularRealmAuthenticator.java:267)
> at
> org.apache.shiro.authc.AbstractAuthenticator.authenticate(AbstractAuthenticator.java:198)
> at
> org.apache.shiro.mgt.AuthenticatingSecurityManager.authenticate(AuthenticatingSecurityManager.java:106)
> at
> org.apache.shiro.mgt.DefaultSecurityManager.login(DefaultSecurityManager.java:270)
> at
> org.apache.shiro.subject.support.DelegatingSubject.login(DelegatingSubject.java:256)
> at
> org.apache.geode.internal.security.IntegratedSecurityService.login(IntegratedSecurityService.java:151)
> at
> org.apache.geode.internal.security.shiro.JMXShiroAuthenticator.authenticate(JMXShiroAuthenticator.java:58)
> at
> javax.management.remote.rmi.RMIServerImpl.doNewClient(RMIServerImpl.java:232)
> at
> javax.management.remote.rmi.RMIServerImpl.newClient(RMIServerImpl.java:199)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:324)
> at sun.rmi.transport.Transport$1.run(Transport.java:200)
> at sun.rmi.transport.Transport$1.run(Transport.java:197)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> at
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:683)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] geode pull request #301: UITests actually take screenshots on failure
Github user asfgit closed the pull request at: https://github.com/apache/geode/pull/301 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (GEODE-1835) A message logged by the configure pdx command is incorrect
[
https://issues.apache.org/jira/browse/GEODE-1835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15730390#comment-15730390
]
ASF subversion and git services commented on GEODE-1835:
Commit 07d168e6a0304d35f99b2d818bd09cff338e2288 in geode's branch
refs/heads/feature/GEODE-1835 from [~abarve]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=07d168e ]
GEODE-1835 : logging a warning message by the configure pdx command only
when there are members in the distributed system.
> A message logged by the configure pdx command is incorrect
> --
>
> Key: GEODE-1835
> URL: https://issues.apache.org/jira/browse/GEODE-1835
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Barry Oglesby
>Assignee: Amey Barve
>
> The message below is only logged when there are no members. Instead, it
> should be logged when there are members.
> {noformat}
> The command would only take effect on new data members joining the
> distributed system. It won't affect the existing data members
> {noformat}
> The condition in {{PDXCommands.configurePDX}} is:
> {noformat}
> if (CliUtil.getAllNormalMembers(CliUtil.getCacheIfExists()).isEmpty()) {
> ird.addLine(CliStrings.CONFIGURE_PDX__NORMAL__MEMBERS__WARNING);
> }
> {noformat}
> It should test for {{!isEmpty}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-1835) A message logged by the configure pdx command is incorrect
[
https://issues.apache.org/jira/browse/GEODE-1835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15730391#comment-15730391
]
ASF subversion and git services commented on GEODE-1835:
Commit 61637b996bad2eb049a41100e7288ec61425d3d5 in geode's branch
refs/heads/feature/GEODE-1835 from [~abarve]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=61637b9 ]
GEODE-1835 : unit test to verify a warning message by the configure pdx
command only when there are members in the distributed system.
This closes #304
> A message logged by the configure pdx command is incorrect
> --
>
> Key: GEODE-1835
> URL: https://issues.apache.org/jira/browse/GEODE-1835
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Barry Oglesby
>Assignee: Amey Barve
>
> The message below is only logged when there are no members. Instead, it
> should be logged when there are members.
> {noformat}
> The command would only take effect on new data members joining the
> distributed system. It won't affect the existing data members
> {noformat}
> The condition in {{PDXCommands.configurePDX}} is:
> {noformat}
> if (CliUtil.getAllNormalMembers(CliUtil.getCacheIfExists()).isEmpty()) {
> ird.addLine(CliStrings.CONFIGURE_PDX__NORMAL__MEMBERS__WARNING);
> }
> {noformat}
> It should test for {{!isEmpty}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: Review Request 54499: GEODE-2092 Update docs with security examples location
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/54499/#review158453 --- Ship it! Ship It! - Dave Barnes On Dec. 7, 2016, 8:59 p.m., Karen Miller wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/54499/ > --- > > (Updated Dec. 7, 2016, 8:59 p.m.) > > > Review request for geode, Dave Barnes, Jinmei Liao, Joey McAllister, and > Kevin Duling. > > > Repository: geode > > > Description > --- > > GEODE-2092 Update docs with security examples location > > > Diffs > - > > geode-docs/managing/security/authentication_examples.html.md.erb > b7634c851121e60c20b7a138aba32bd2bc002c2e > geode-docs/managing/security/authorization_example.html.md.erb > 2e725a107986f76a621a85bcdd8711e8b56b63a5 > > Diff: https://reviews.apache.org/r/54499/diff/ > > > Testing > --- > > > Thanks, > > Karen Miller > >
Re: Review Request 54503: GEODE-2186: Changing the pulse gateway status to only look at running status
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/54503/#review158462 --- Ship it! +1 for using Map.merge with logicalAnd. Pretty cool. - Barry Oglesby On Dec. 7, 2016, 11:14 p.m., Dan Smith wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/54503/ > --- > > (Updated Dec. 7, 2016, 11:14 p.m.) > > > Review request for geode, Barry Oglesby and xiaojian zhou. > > > Repository: geode > > > Description > --- > > Gateway senders may or may not be connected, depending on what is going > on with the underlying queue. If a sender is a secondary, it may be > disconnected because it doesn't need to send anything. Even primaries > may be disconnected for periods of time if the connection is lost when > there is nothing in the queue. > > > Diffs > - > > > geode-core/src/main/java/org/apache/geode/management/internal/beans/DistributedSystemBridge.java > 3016277715864b4b66b25d9dcffc8ef7053e5467 > > geode-wan/src/test/java/org/apache/geode/management/WANManagementDUnitTest.java > 9a6cc104a1368fa762bffd1efa1978f007819604 > > Diff: https://reviews.apache.org/r/54503/diff/ > > > Testing > --- > > > Thanks, > > Dan Smith > >
[GitHub] geode pull request #303: GEODE-1984: Fix Issue Make GatewaySender destroy a ...
Github user davinash commented on a diff in the pull request: https://github.com/apache/geode/pull/303#discussion_r91421904 --- Diff: geode-core/src/main/java/org/apache/geode/cache/wan/GatewaySender.java --- @@ -400,4 +400,19 @@ public int getMaxParallelismForReplicatedRegion(); + + /** + * Destroys the GatewaySender. Before destroying the sender, caller needs to to ensure that the --- End diff -- Fixed. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (GEODE-1984) Make GatewaySender destroy a public API
[
https://issues.apache.org/jira/browse/GEODE-1984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15730483#comment-15730483
]
ASF GitHub Bot commented on GEODE-1984:
---
Github user davinash commented on a diff in the pull request:
https://github.com/apache/geode/pull/303#discussion_r91421904
--- Diff:
geode-core/src/main/java/org/apache/geode/cache/wan/GatewaySender.java ---
@@ -400,4 +400,19 @@
public int getMaxParallelismForReplicatedRegion();
+
+ /**
+ * Destroys the GatewaySender. Before destroying the sender, caller
needs to to ensure that the
--- End diff --
Fixed.
> Make GatewaySender destroy a public API
> ---
>
> Key: GEODE-1984
> URL: https://issues.apache.org/jira/browse/GEODE-1984
> Project: Geode
> Issue Type: New Feature
> Components: docs, wan
>Reporter: Barry Oglesby
>Assignee: Avinash Dongre
>
> The internal {{AbstractGatewaySender}} class has a {{destroy}} API to destroy
> a {{GatewaySender}}. This is currently an internal API. It would be nice to
> make this public by:
> - adding destroy to the {{GatewaySender}} interface
> - provide {{gfsh}} support
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-1984) Make GatewaySender destroy a public API
[
https://issues.apache.org/jira/browse/GEODE-1984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15730486#comment-15730486
]
ASF GitHub Bot commented on GEODE-1984:
---
Github user davinash commented on a diff in the pull request:
https://github.com/apache/geode/pull/303#discussion_r91422055
--- Diff:
geode-wan/src/test/java/org/apache/geode/internal/cache/wan/wancommand/WanCommandCreateDestroyGatewaySenderDUnitTest.java
---
@@ -55,7 +55,7 @@ private CommandResult
executeCommandWithIgnoredExceptions(String command) {
* GatewaySender with all default attributes
--- End diff --
I thought it would be good to have the same Test. Any new create scenario
will also have associated destroy command.
> Make GatewaySender destroy a public API
> ---
>
> Key: GEODE-1984
> URL: https://issues.apache.org/jira/browse/GEODE-1984
> Project: Geode
> Issue Type: New Feature
> Components: docs, wan
>Reporter: Barry Oglesby
>Assignee: Avinash Dongre
>
> The internal {{AbstractGatewaySender}} class has a {{destroy}} API to destroy
> a {{GatewaySender}}. This is currently an internal API. It would be nice to
> make this public by:
> - adding destroy to the {{GatewaySender}} interface
> - provide {{gfsh}} support
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] geode pull request #303: GEODE-1984: Fix Issue Make GatewaySender destroy a ...
Github user davinash commented on a diff in the pull request:
https://github.com/apache/geode/pull/303#discussion_r91422055
--- Diff:
geode-wan/src/test/java/org/apache/geode/internal/cache/wan/wancommand/WanCommandCreateDestroyGatewaySenderDUnitTest.java
---
@@ -55,7 +55,7 @@ private CommandResult
executeCommandWithIgnoredExceptions(String command) {
* GatewaySender with all default attributes
--- End diff --
I thought it would be good to have the same Test. Any new create scenario
will also have associated destroy command.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] geode pull request #303: GEODE-1984: Fix Issue Make GatewaySender destroy a ...
Github user davinash commented on a diff in the pull request: https://github.com/apache/geode/pull/303#discussion_r91422209 --- Diff: geode-core/src/main/java/org/apache/geode/cache/wan/GatewaySender.java --- @@ -400,4 +400,19 @@ public int getMaxParallelismForReplicatedRegion(); + + /** + * Destroys the GatewaySender. Before destroying the sender, caller needs to to ensure that the + * sender is stopped so that all the resources (threads, connection pool etc.) will be released + * properly. Stopping the sender is not handled in the destroy. Destroy is carried out in + * following steps: 1. Take the lifeCycleLock. 2. If the sender is attached to any application + * region, throw an exception. 3. Close the GatewaySenderAdvisor. 4. Remove the sender from the + * cache. 5. Destroy the region underlying the GatewaySender. + * + * In case of ParallelGatewaySender, the destroy operation does distributed destroy of the QPR. In + * case of SerialGatewaySender, the queue region is destroyed locally. --- End diff -- Fixed. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] geode pull request #303: GEODE-1984: Fix Issue Make GatewaySender destroy a ...
Github user davinash commented on a diff in the pull request:
https://github.com/apache/geode/pull/303#discussion_r91422194
--- Diff:
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/GatewaySenderDestroyFunction.java
---
@@ -0,0 +1,90 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
contributor license
+ * agreements. See the NOTICE file distributed with this work for
additional information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF
ANY KIND, either express
+ * or implied. See the License for the specific language governing
permissions and limitations under
+ * the License.
+ */
+package org.apache.geode.management.internal.cli.functions;
+
+import org.apache.geode.cache.Cache;
+import org.apache.geode.cache.CacheFactory;
+import org.apache.geode.cache.execute.FunctionAdapter;
+import org.apache.geode.cache.execute.FunctionContext;
+import org.apache.geode.cache.execute.ResultSender;
+import org.apache.geode.cache.wan.GatewaySender;
+import org.apache.geode.internal.InternalEntity;
+import org.apache.geode.internal.cache.wan.GatewaySenderException;
+import org.apache.geode.internal.logging.LogService;
+import org.apache.geode.management.internal.cli.CliUtil;
+import org.apache.geode.management.internal.cli.i18n.CliStrings;
+import org.apache.logging.log4j.Logger;
+
+public class GatewaySenderDestroyFunction extends FunctionAdapter
implements InternalEntity {
+ private static final long serialVersionUID = 1459761440357690134L;
+
+ private static final Logger logger = LogService.getLogger();
+ private static final String ID =
GatewaySenderDestroyFunction.class.getName();
+ public static GatewaySenderDestroyFunction INSTANCE = new
GatewaySenderDestroyFunction();
+
+ @Override
+ public void execute(FunctionContext context) {
+ResultSender resultSender = context.getResultSender();
+
+Cache cache = CacheFactory.getAnyInstance();
+String memberNameOrId =
+
CliUtil.getMemberNameOrId(cache.getDistributedSystem().getDistributedMember());
+
+GatewaySenderDestroyFunctionArgs gatewaySenderDestroyFunctionArgs =
+(GatewaySenderDestroyFunctionArgs) context.getArguments();
+
+try {
+ GatewaySender gatewaySender =
+ cache.getGatewaySender(gatewaySenderDestroyFunctionArgs.getId());
+ if (gatewaySender != null) {
+gatewaySender.stop();
--- End diff --
Looking at the code AbstractGatewaySenderEventProcessor#closeProcessor, It
looks like stop logs the warning and goes ahead with closing. I think we should
open separate JIRA for stop behaviour.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[jira] [Commented] (GEODE-1984) Make GatewaySender destroy a public API
[
https://issues.apache.org/jira/browse/GEODE-1984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15730497#comment-15730497
]
ASF GitHub Bot commented on GEODE-1984:
---
Github user davinash commented on a diff in the pull request:
https://github.com/apache/geode/pull/303#discussion_r91422209
--- Diff:
geode-core/src/main/java/org/apache/geode/cache/wan/GatewaySender.java ---
@@ -400,4 +400,19 @@
public int getMaxParallelismForReplicatedRegion();
+
+ /**
+ * Destroys the GatewaySender. Before destroying the sender, caller
needs to to ensure that the
+ * sender is stopped so that all the resources (threads, connection pool
etc.) will be released
+ * properly. Stopping the sender is not handled in the destroy. Destroy
is carried out in
+ * following steps: 1. Take the lifeCycleLock. 2. If the sender is
attached to any application
+ * region, throw an exception. 3. Close the GatewaySenderAdvisor. 4.
Remove the sender from the
+ * cache. 5. Destroy the region underlying the GatewaySender.
+ *
+ * In case of ParallelGatewaySender, the destroy operation does
distributed destroy of the QPR. In
+ * case of SerialGatewaySender, the queue region is destroyed locally.
--- End diff --
Fixed.
> Make GatewaySender destroy a public API
> ---
>
> Key: GEODE-1984
> URL: https://issues.apache.org/jira/browse/GEODE-1984
> Project: Geode
> Issue Type: New Feature
> Components: docs, wan
>Reporter: Barry Oglesby
>Assignee: Avinash Dongre
>
> The internal {{AbstractGatewaySender}} class has a {{destroy}} API to destroy
> a {{GatewaySender}}. This is currently an internal API. It would be nice to
> make this public by:
> - adding destroy to the {{GatewaySender}} interface
> - provide {{gfsh}} support
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-1984) Make GatewaySender destroy a public API
[
https://issues.apache.org/jira/browse/GEODE-1984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15730494#comment-15730494
]
ASF GitHub Bot commented on GEODE-1984:
---
Github user davinash commented on a diff in the pull request:
https://github.com/apache/geode/pull/303#discussion_r91422194
--- Diff:
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/GatewaySenderDestroyFunction.java
---
@@ -0,0 +1,90 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
contributor license
+ * agreements. See the NOTICE file distributed with this work for
additional information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF
ANY KIND, either express
+ * or implied. See the License for the specific language governing
permissions and limitations under
+ * the License.
+ */
+package org.apache.geode.management.internal.cli.functions;
+
+import org.apache.geode.cache.Cache;
+import org.apache.geode.cache.CacheFactory;
+import org.apache.geode.cache.execute.FunctionAdapter;
+import org.apache.geode.cache.execute.FunctionContext;
+import org.apache.geode.cache.execute.ResultSender;
+import org.apache.geode.cache.wan.GatewaySender;
+import org.apache.geode.internal.InternalEntity;
+import org.apache.geode.internal.cache.wan.GatewaySenderException;
+import org.apache.geode.internal.logging.LogService;
+import org.apache.geode.management.internal.cli.CliUtil;
+import org.apache.geode.management.internal.cli.i18n.CliStrings;
+import org.apache.logging.log4j.Logger;
+
+public class GatewaySenderDestroyFunction extends FunctionAdapter
implements InternalEntity {
+ private static final long serialVersionUID = 1459761440357690134L;
+
+ private static final Logger logger = LogService.getLogger();
+ private static final String ID =
GatewaySenderDestroyFunction.class.getName();
+ public static GatewaySenderDestroyFunction INSTANCE = new
GatewaySenderDestroyFunction();
+
+ @Override
+ public void execute(FunctionContext context) {
+ResultSender resultSender = context.getResultSender();
+
+Cache cache = CacheFactory.getAnyInstance();
+String memberNameOrId =
+
CliUtil.getMemberNameOrId(cache.getDistributedSystem().getDistributedMember());
+
+GatewaySenderDestroyFunctionArgs gatewaySenderDestroyFunctionArgs =
+(GatewaySenderDestroyFunctionArgs) context.getArguments();
+
+try {
+ GatewaySender gatewaySender =
+ cache.getGatewaySender(gatewaySenderDestroyFunctionArgs.getId());
+ if (gatewaySender != null) {
+gatewaySender.stop();
--- End diff --
Looking at the code AbstractGatewaySenderEventProcessor#closeProcessor, It
looks like stop logs the warning and goes ahead with closing. I think we should
open separate JIRA for stop behaviour.
> Make GatewaySender destroy a public API
> ---
>
> Key: GEODE-1984
> URL: https://issues.apache.org/jira/browse/GEODE-1984
> Project: Geode
> Issue Type: New Feature
> Components: docs, wan
>Reporter: Barry Oglesby
>Assignee: Avinash Dongre
>
> The internal {{AbstractGatewaySender}} class has a {{destroy}} API to destroy
> a {{GatewaySender}}. This is currently an internal API. It would be nice to
> make this public by:
> - adding destroy to the {{GatewaySender}} interface
> - provide {{gfsh}} support
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] geode pull request #303: GEODE-1984: Fix Issue Make GatewaySender destroy a ...
Github user jhuynh1 commented on a diff in the pull request:
https://github.com/apache/geode/pull/303#discussion_r91423780
--- Diff:
geode-wan/src/test/java/org/apache/geode/internal/cache/wan/wancommand/WanCommandCreateDestroyGatewaySenderDUnitTest.java
---
@@ -282,13 +335,40 @@ public void
testCreateGatewaySenderWithGatewayEventFilters() {
1000, 5000, true, false, 1000, 100, 2, OrderPolicy.THREAD,
eventFilters, null));
vm5.invoke(() -> verifySenderAttributes("ln", 2, false, true, 1000,
socketReadTimeout, true,
1000, 5000, true, false, 1000, 100, 2, OrderPolicy.THREAD,
eventFilters, null));
+
+// Test Destroy Command.
+command =
+CliStrings.DESTROY_GATEWAYSENDER + " --" +
CliStrings.DESTROY_GATEWAYSENDER__ID + "=ln";
--- End diff --
This code looks copy pasted in other areas, any way we can pull it into a
separate method for reuse?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[jira] [Commented] (GEODE-1984) Make GatewaySender destroy a public API
[
https://issues.apache.org/jira/browse/GEODE-1984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15730672#comment-15730672
]
ASF GitHub Bot commented on GEODE-1984:
---
Github user jhuynh1 commented on a diff in the pull request:
https://github.com/apache/geode/pull/303#discussion_r91423780
--- Diff:
geode-wan/src/test/java/org/apache/geode/internal/cache/wan/wancommand/WanCommandCreateDestroyGatewaySenderDUnitTest.java
---
@@ -282,13 +335,40 @@ public void
testCreateGatewaySenderWithGatewayEventFilters() {
1000, 5000, true, false, 1000, 100, 2, OrderPolicy.THREAD,
eventFilters, null));
vm5.invoke(() -> verifySenderAttributes("ln", 2, false, true, 1000,
socketReadTimeout, true,
1000, 5000, true, false, 1000, 100, 2, OrderPolicy.THREAD,
eventFilters, null));
+
+// Test Destroy Command.
+command =
+CliStrings.DESTROY_GATEWAYSENDER + " --" +
CliStrings.DESTROY_GATEWAYSENDER__ID + "=ln";
--- End diff --
This code looks copy pasted in other areas, any way we can pull it into a
separate method for reuse?
> Make GatewaySender destroy a public API
> ---
>
> Key: GEODE-1984
> URL: https://issues.apache.org/jira/browse/GEODE-1984
> Project: Geode
> Issue Type: New Feature
> Components: docs, wan
>Reporter: Barry Oglesby
>Assignee: Avinash Dongre
>
> The internal {{AbstractGatewaySender}} class has a {{destroy}} API to destroy
> a {{GatewaySender}}. This is currently an internal API. It would be nice to
> make this public by:
> - adding destroy to the {{GatewaySender}} interface
> - provide {{gfsh}} support
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] geode pull request #303: GEODE-1984: Fix Issue Make GatewaySender destroy a ...
Github user davinash commented on a diff in the pull request:
https://github.com/apache/geode/pull/303#discussion_r91458212
--- Diff:
geode-wan/src/test/java/org/apache/geode/internal/cache/wan/wancommand/WanCommandCreateDestroyGatewaySenderDUnitTest.java
---
@@ -282,13 +335,40 @@ public void
testCreateGatewaySenderWithGatewayEventFilters() {
1000, 5000, true, false, 1000, 100, 2, OrderPolicy.THREAD,
eventFilters, null));
vm5.invoke(() -> verifySenderAttributes("ln", 2, false, true, 1000,
socketReadTimeout, true,
1000, 5000, true, false, 1000, 100, 2, OrderPolicy.THREAD,
eventFilters, null));
+
+// Test Destroy Command.
+command =
+CliStrings.DESTROY_GATEWAYSENDER + " --" +
CliStrings.DESTROY_GATEWAYSENDER__ID + "=ln";
--- End diff --
fixed.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[jira] [Commented] (GEODE-1984) Make GatewaySender destroy a public API
[
https://issues.apache.org/jira/browse/GEODE-1984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15731420#comment-15731420
]
ASF GitHub Bot commented on GEODE-1984:
---
Github user davinash commented on a diff in the pull request:
https://github.com/apache/geode/pull/303#discussion_r91458212
--- Diff:
geode-wan/src/test/java/org/apache/geode/internal/cache/wan/wancommand/WanCommandCreateDestroyGatewaySenderDUnitTest.java
---
@@ -282,13 +335,40 @@ public void
testCreateGatewaySenderWithGatewayEventFilters() {
1000, 5000, true, false, 1000, 100, 2, OrderPolicy.THREAD,
eventFilters, null));
vm5.invoke(() -> verifySenderAttributes("ln", 2, false, true, 1000,
socketReadTimeout, true,
1000, 5000, true, false, 1000, 100, 2, OrderPolicy.THREAD,
eventFilters, null));
+
+// Test Destroy Command.
+command =
+CliStrings.DESTROY_GATEWAYSENDER + " --" +
CliStrings.DESTROY_GATEWAYSENDER__ID + "=ln";
--- End diff --
fixed.
> Make GatewaySender destroy a public API
> ---
>
> Key: GEODE-1984
> URL: https://issues.apache.org/jira/browse/GEODE-1984
> Project: Geode
> Issue Type: New Feature
> Components: docs, wan
>Reporter: Barry Oglesby
>Assignee: Avinash Dongre
>
> The internal {{AbstractGatewaySender}} class has a {{destroy}} API to destroy
> a {{GatewaySender}}. This is currently an internal API. It would be nice to
> make this public by:
> - adding destroy to the {{GatewaySender}} interface
> - provide {{gfsh}} support
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
