[jira] [Updated] (GEODE-3438) Collection added to itself
[
https://issues.apache.org/jira/browse/GEODE-3438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-3438:
--
Labels: pull-request-available (was: )
> Collection added to itself
> --
>
> Key: GEODE-3438
> URL: https://issues.apache.org/jira/browse/GEODE-3438
> Project: Geode
> Issue Type: Bug
> Components: querying
>Reporter: JC
>Priority: Major
> Labels: pull-request-available
>
> Hi
> In a recent github mirror, I've found suspicious code.
> Branch: master
> Path:
> geode-core/src/main/java/org/apache/geode/management/internal/cli/domain/DurableCqNamesResult.java
> {code:java}
> ...
> 27 private List cqNames = new ArrayList();
> ...
> 33 public DurableCqNamesResult(final String memberNameOrId, List
> cqNames) {
> 34 super(memberNameOrId);
> 35 cqNames.addAll(cqNames);
> 36 }
> {code}
> In Line 35, should `cqNames.addAll' be `this.cqNames.addAll'? This might not
> be an issue, but I wanted to report just in case.
> Thanks!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-4311) Hotdeploy jar merged into one classloader, muti-module hard to management
[ https://issues.apache.org/jira/browse/GEODE-4311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445277#comment-16445277 ] Anthony Baker commented on GEODE-4311: -- Hi [~dyang] can you help us understand the use case for hierarchical class loaders? What meta information / status did this provide? Thanks! > Hotdeploy jar merged into one classloader, muti-module hard to management > - > > Key: GEODE-4311 > URL: https://issues.apache.org/jira/browse/GEODE-4311 > Project: Geode > Issue Type: Improvement > Components: configuration >Reporter: Dong Yang >Priority: Major > > Gemfire previous version have JarClassLoader for each deployed jar packages. > Then I can design my modules as hierarchical ， there can have a core module > to save some internal status, sometimes it means a lot of meta informations. > But now , only one newest ClassPathLoader used for all deployed jar. Each > time you invoke the deploy command through gfsh , geode server-side will > rebuild the classloader and include all jars. It's simple than before, but i > lose all my meta informations even I have no code change for these part. > Just want to know what's the purpose for this change , Do I need implement my > own loader or these will be enhanced in future. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-4301) Need an API for retrieving keys for OQL query resultset
[ https://issues.apache.org/jira/browse/GEODE-4301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker resolved GEODE-4301. -- Resolution: Not A Problem > Need an API for retrieving keys for OQL query resultset > --- > > Key: GEODE-4301 > URL: https://issues.apache.org/jira/browse/GEODE-4301 > Project: Geode > Issue Type: Improvement > Components: querying, rest (dev) >Reporter: Abhay Dandekar >Priority: Major > > Hi All, > I was facing an issue where we are trying to retrieve data from Geode server > using REST API. We are using Adhoc query API. And our OQL results is a huge > dataset. Its generally returns a million rows. > In this case, the server errors out with an OOM exception. > The idea is to have an REST API to retrieve just the keys of a QOL result > set. Which can be later iterated over to retrieve the complete resultset. > I searched this over the documentation, did not find it. I also searched in > the latest codebase, but could not pinpoint to the code which can help me > achieve this. > Do let me know, if this feature is already implemented. If yes, I can move > this issue to as a documentation bug and fix it. > Thanks and Regards, > Abhay Dandekar -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-4301) Need an API for retrieving keys for OQL query resultset
[ https://issues.apache.org/jira/browse/GEODE-4301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker closed GEODE-4301. > Need an API for retrieving keys for OQL query resultset > --- > > Key: GEODE-4301 > URL: https://issues.apache.org/jira/browse/GEODE-4301 > Project: Geode > Issue Type: Improvement > Components: querying, rest (dev) >Reporter: Abhay Dandekar >Priority: Major > > Hi All, > I was facing an issue where we are trying to retrieve data from Geode server > using REST API. We are using Adhoc query API. And our OQL results is a huge > dataset. Its generally returns a million rows. > In this case, the server errors out with an OOM exception. > The idea is to have an REST API to retrieve just the keys of a QOL result > set. Which can be later iterated over to retrieve the complete resultset. > I searched this over the documentation, did not find it. I also searched in > the latest codebase, but could not pinpoint to the code which can help me > achieve this. > Do let me know, if this feature is already implemented. If yes, I can move > this issue to as a documentation bug and fix it. > Thanks and Regards, > Abhay Dandekar -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-4279) Move DistributedTest to a different worker type
[ https://issues.apache.org/jira/browse/GEODE-4279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker closed GEODE-4279. > Move DistributedTest to a different worker type > --- > > Key: GEODE-4279 > URL: https://issues.apache.org/jira/browse/GEODE-4279 > Project: Geode > Issue Type: Task > Components: ci >Reporter: Sean Goller >Priority: Major > > DistributedTest should run on a different worker to give it enough headroom -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-4279) Move DistributedTest to a different worker type
[ https://issues.apache.org/jira/browse/GEODE-4279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker resolved GEODE-4279. -- Resolution: Fixed > Move DistributedTest to a different worker type > --- > > Key: GEODE-4279 > URL: https://issues.apache.org/jira/browse/GEODE-4279 > Project: Geode > Issue Type: Task > Components: ci >Reporter: Sean Goller >Priority: Major > > DistributedTest should run on a different worker to give it enough headroom -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4268) Move jmh benchmarks to geode-code
[ https://issues.apache.org/jira/browse/GEODE-4268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445274#comment-16445274 ] Anthony Baker commented on GEODE-4268: -- [~klund] can this issue be closed? > Move jmh benchmarks to geode-code > - > > Key: GEODE-4268 > URL: https://issues.apache.org/jira/browse/GEODE-4268 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Nick Reich >Priority: Major > > Instead of having all jmh benchmarks in their own module, add them to the > module where the codd they benchmark resides. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-4274) Add geode-examples job to CI
[ https://issues.apache.org/jira/browse/GEODE-4274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker resolved GEODE-4274. -- Resolution: Fixed > Add geode-examples job to CI > > > Key: GEODE-4274 > URL: https://issues.apache.org/jira/browse/GEODE-4274 > Project: Geode > Issue Type: Task > Components: ci >Reporter: Sean Goller >Priority: Major > > The concourse pipeline should test geode-examples. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-4274) Add geode-examples job to CI
[ https://issues.apache.org/jira/browse/GEODE-4274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker closed GEODE-4274. > Add geode-examples job to CI > > > Key: GEODE-4274 > URL: https://issues.apache.org/jira/browse/GEODE-4274 > Project: Geode > Issue Type: Task > Components: ci >Reporter: Sean Goller >Priority: Major > > The concourse pipeline should test geode-examples. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-4247) Email does not get sent when a unit test takes too long to execute
[ https://issues.apache.org/jira/browse/GEODE-4247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker resolved GEODE-4247. -- Resolution: Fixed > Email does not get sent when a unit test takes too long to execute > -- > > Key: GEODE-4247 > URL: https://issues.apache.org/jira/browse/GEODE-4247 > Project: Geode > Issue Type: Bug > Components: ci >Reporter: Sean Goller >Priority: Major > > If a concourse task hangs and the container is killed, email is not sent out. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-4247) Email does not get sent when a unit test takes too long to execute
[ https://issues.apache.org/jira/browse/GEODE-4247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker closed GEODE-4247. > Email does not get sent when a unit test takes too long to execute > -- > > Key: GEODE-4247 > URL: https://issues.apache.org/jira/browse/GEODE-4247 > Project: Geode > Issue Type: Bug > Components: ci >Reporter: Sean Goller >Priority: Major > > If a concourse task hangs and the container is killed, email is not sent out. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-4123) Improve build notification from geode concourse
[ https://issues.apache.org/jira/browse/GEODE-4123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker resolved GEODE-4123. -- Resolution: Fixed > Improve build notification from geode concourse > --- > > Key: GEODE-4123 > URL: https://issues.apache.org/jira/browse/GEODE-4123 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Robert Houghton >Priority: Major > > From: > Date: Wed, Dec 6, 2017 at 4:55 PM > Subject: Geode tests completed in pipeline with non-zero exit code > To: d...@geode.apache.org > Pipeline results can be found at: > Concourse: > https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/FlakyTest/builds/17 > And the pipeline name is missing from the subject too -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-4123) Improve build notification from geode concourse
[ https://issues.apache.org/jira/browse/GEODE-4123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker closed GEODE-4123. > Improve build notification from geode concourse > --- > > Key: GEODE-4123 > URL: https://issues.apache.org/jira/browse/GEODE-4123 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Robert Houghton >Priority: Major > > From: > Date: Wed, Dec 6, 2017 at 4:55 PM > Subject: Geode tests completed in pipeline with non-zero exit code > To: d...@geode.apache.org > Pipeline results can be found at: > Concourse: > https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/FlakyTest/builds/17 > And the pipeline name is missing from the subject too -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4066) Add test coverage using SecurityManager
[ https://issues.apache.org/jira/browse/GEODE-4066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445270#comment-16445270 ] Anthony Baker commented on GEODE-4066: -- [~eburghardt] can this issue be closed? > Add test coverage using SecurityManager > --- > > Key: GEODE-4066 > URL: https://issues.apache.org/jira/browse/GEODE-4066 > Project: Geode > Issue Type: Test > Components: native client >Reporter: Ernest Burghardt >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-4023) Add precheckin tests to concourse pipeline
[ https://issues.apache.org/jira/browse/GEODE-4023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker resolved GEODE-4023. -- Resolution: Fixed > Add precheckin tests to concourse pipeline > -- > > Key: GEODE-4023 > URL: https://issues.apache.org/jira/browse/GEODE-4023 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Sean Goller >Priority: Major > > Improve the Geode Concourse pipeline by adding those tests run by the > `precheckin` gradle target. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-4023) Add precheckin tests to concourse pipeline
[ https://issues.apache.org/jira/browse/GEODE-4023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker closed GEODE-4023. > Add precheckin tests to concourse pipeline > -- > > Key: GEODE-4023 > URL: https://issues.apache.org/jira/browse/GEODE-4023 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Sean Goller >Priority: Major > > Improve the Geode Concourse pipeline by adding those tests run by the > `precheckin` gradle target. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-3985) rolling upgrade tests accidentally rolls vms back to the current version
[ https://issues.apache.org/jira/browse/GEODE-3985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445262#comment-16445262 ] Anthony Baker commented on GEODE-3985: -- [~jinmeiliao] can this issue be closed? > rolling upgrade tests accidentally rolls vms back to the current version > > > Key: GEODE-3985 > URL: https://issues.apache.org/jira/browse/GEODE-3985 > Project: Geode > Issue Type: Bug >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-3946) Attempting to connect an older version gfsh to a newer version JMX manager should fail
[
https://issues.apache.org/jira/browse/GEODE-3946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445259#comment-16445259
]
Anthony Baker commented on GEODE-3946:
--
[~jinmeiliao] can this issue be closed?
> Attempting to connect an older version gfsh to a newer version JMX manager
> should fail
> --
>
> Key: GEODE-3946
> URL: https://issues.apache.org/jira/browse/GEODE-3946
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Barry Oglesby
>Assignee: Kenneth Howe
>Priority: Trivial
>
> Currently, an older version of gfsh can connect to a newer version JMX
> manager, but when a command is invoked, it'll fail with a cryptic message.
> An example is:
> 9.1.1 JMX manager
> 9.0.3 gfsh
> Attempting to execute a query with this scenario logs a 'Could not parse
> command string' message:
> {noformat}
> gfsh>query --query='SELECT sauce FROM /data' --interactive=true
> Could not parse command string. query --query='SELECT sauce FROM /data'
> --interactive=true --step-name=SELECT_EXEC
> {noformat}
> Instead, gfsh should fail at connect time with an
> {{IncompatibleVersionException}} or something similar.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-3971) JSON/REST API yields inconsistent Number types and breaks Aggregation functions
[
https://issues.apache.org/jira/browse/GEODE-3971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-3971:
-
Component/s: rest (dev)
> JSON/REST API yields inconsistent Number types and breaks Aggregation
> functions
> ---
>
> Key: GEODE-3971
> URL: https://issues.apache.org/jira/browse/GEODE-3971
> Project: Geode
> Issue Type: Bug
> Components: rest (dev)
>Reporter: Christian Tzolov
>Priority: Major
>
> If you POST through the REST API, JSON documents with numeric field, chances
> are that Geode will use different Java types to represent those number fields
> (e.g from Byte to Long)
> For example if you post the following tree JSON documents with different pop
> field values:
> {code}
> { "_id" : "27821", "city" : "EDWARD", "loc" : [ -76.8793880001, 35.323588
> ], "pop" : 122, "state" : "NC" }
> { "_id" : "75227", "city" : "DALLAS", "loc" : [ -96.6835860001, 32.767226
> ], "pop" : 39631, "state" : "TX" }
> { "_id" : "12461", "city" : "KRUMVILLE", "loc" : [ -74.246954, 41.895906 ],
> "pop" : 1423, "state" : "NY" }
> {code}
> It will result in 3 different java number types being used by Geode:
> {panel}
> gfsh>query --query="SELECT pop.getClass().getCanonicalName(), count(*) as cnt
> FROM /geodeRegion group by(pop.getClass().getCanonicalName())"
> getCanonicalName | cnt
> - | -
> java.lang.Integer | 1
> java.lang.Byte| 1
> java.lang.Short | 1
> {panel}
> This inconsistency alone is bad enough but it also causes aggregation
> functions to fail:
> {panel}
> gfsh>query --query="SELECT MAX(pop) from /geodeRegion"
> Message : java.lang.Integer cannot be cast to java.lang.Byte
> Result : false
> {panel}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GEODE-3942) Add concourse pipeline scripts
[
https://issues.apache.org/jira/browse/GEODE-3942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker closed GEODE-3942.
> Add concourse pipeline scripts
> --
>
> Key: GEODE-3942
> URL: https://issues.apache.org/jira/browse/GEODE-3942
> Project: Geode
> Issue Type: Improvement
> Components: ci
>Reporter: Anthony Baker
>Priority: Trivial
>
> Add scripts for concourse pipelines. The initial jobs should just run
> {{gradle build}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-3942) Add concourse pipeline scripts
[
https://issues.apache.org/jira/browse/GEODE-3942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker resolved GEODE-3942.
--
Resolution: Fixed
> Add concourse pipeline scripts
> --
>
> Key: GEODE-3942
> URL: https://issues.apache.org/jira/browse/GEODE-3942
> Project: Geode
> Issue Type: Improvement
> Components: ci
>Reporter: Anthony Baker
>Priority: Trivial
>
> Add scripts for concourse pipelines. The initial jobs should just run
> {{gradle build}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-3936) Cleanup ThreadUtil
[ https://issues.apache.org/jira/browse/GEODE-3936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445256#comment-16445256 ] Anthony Baker commented on GEODE-3936: -- [~jinmeiliao] can this issue be closed? > Cleanup ThreadUtil > -- > > Key: GEODE-3936 > URL: https://issues.apache.org/jira/browse/GEODE-3936 > Project: Geode > Issue Type: Bug >Reporter: Jinmei Liao >Priority: Major > > It's not useful anymore. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-3905) write speed decreases when using geode redis server for wan replication
[ https://issues.apache.org/jira/browse/GEODE-3905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker closed GEODE-3905. > write speed decreases when using geode redis server for wan replication > --- > > Key: GEODE-3905 > URL: https://issues.apache.org/jira/browse/GEODE-3905 > Project: Geode > Issue Type: Improvement > Components: redis, wan >Reporter: shivam mitra >Priority: Major > > I am trying to use WAN replication between two redis geode servers. I have > set up the replication as was given in the tutorial about wan replication. > Two data centers each having a single node on which everything is > running(sender,reciever,locator,geode server). > I am benchmarking it with redis-benchmark. I have noticed that write/sec > keeps on decreasing as i keep on inserting more data. I feel the decrease is > due to replication of the data. It decrease from 4 w/s to 8000 w/s. > How can I optimise it so that replication doesn't decrease the write speed? I > have 8 cores on my system. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-3905) write speed decreases when using geode redis server for wan replication
[ https://issues.apache.org/jira/browse/GEODE-3905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker resolved GEODE-3905. -- Resolution: Not A Problem > write speed decreases when using geode redis server for wan replication > --- > > Key: GEODE-3905 > URL: https://issues.apache.org/jira/browse/GEODE-3905 > Project: Geode > Issue Type: Improvement > Components: redis, wan >Reporter: shivam mitra >Priority: Major > > I am trying to use WAN replication between two redis geode servers. I have > set up the replication as was given in the tutorial about wan replication. > Two data centers each having a single node on which everything is > running(sender,reciever,locator,geode server). > I am benchmarking it with redis-benchmark. I have noticed that write/sec > keeps on decreasing as i keep on inserting more data. I feel the decrease is > due to replication of the data. It decrease from 4 w/s to 8000 w/s. > How can I optimise it so that replication doesn't decrease the write speed? I > have 8 cores on my system. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-3905) write speed decreases when using geode redis server for wan replication
[ https://issues.apache.org/jira/browse/GEODE-3905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445254#comment-16445254 ] Anthony Baker commented on GEODE-3905: -- [~codophobia] sorry for the delayed response. I recommend you take your question to the dev list for help before opening a bug report. Thanks! > write speed decreases when using geode redis server for wan replication > --- > > Key: GEODE-3905 > URL: https://issues.apache.org/jira/browse/GEODE-3905 > Project: Geode > Issue Type: Improvement > Components: redis, wan >Reporter: shivam mitra >Priority: Major > > I am trying to use WAN replication between two redis geode servers. I have > set up the replication as was given in the tutorial about wan replication. > Two data centers each having a single node on which everything is > running(sender,reciever,locator,geode server). > I am benchmarking it with redis-benchmark. I have noticed that write/sec > keeps on decreasing as i keep on inserting more data. I feel the decrease is > due to replication of the data. It decrease from 4 w/s to 8000 w/s. > How can I optimise it so that replication doesn't decrease the write speed? I > have 8 cores on my system. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-3892) Create docker image for building geode in GCP
[ https://issues.apache.org/jira/browse/GEODE-3892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker resolved GEODE-3892. -- Resolution: Done > Create docker image for building geode in GCP > - > > Key: GEODE-3892 > URL: https://issues.apache.org/jira/browse/GEODE-3892 > Project: Geode > Issue Type: New Feature >Reporter: Scott Jewell >Priority: Major > > We need a docker image for use when building Geode within GCP. > This is for use with the upcoming GCP Geode pipeline. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-3892) Create docker image for building geode in GCP
[ https://issues.apache.org/jira/browse/GEODE-3892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker closed GEODE-3892. > Create docker image for building geode in GCP > - > > Key: GEODE-3892 > URL: https://issues.apache.org/jira/browse/GEODE-3892 > Project: Geode > Issue Type: New Feature >Reporter: Scott Jewell >Priority: Major > > We need a docker image for use when building Geode within GCP. > This is for use with the upcoming GCP Geode pipeline. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-3818) Dockerfile still points to incubator-geode.git
[
https://issues.apache.org/jira/browse/GEODE-3818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker resolved GEODE-3818.
--
Resolution: Fixed
This was fixed when we rewrote the {{Dockerfile}} for GEODE-3921.
> Dockerfile still points to incubator-geode.git
> --
>
> Key: GEODE-3818
> URL: https://issues.apache.org/jira/browse/GEODE-3818
> Project: Geode
> Issue Type: Improvement
> Components: build, configuration
>Reporter: Arun Yadav
>Priority: Major
>
> The docker/Dockerfile is pointing to
> https://github.com/apache/incubator-geode.git. This can be now changed to
> https://github.com/apache/geode.git, followed by other references to
> incubator directory can be changed in Dockerfile
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GEODE-3818) Dockerfile still points to incubator-geode.git
[ https://issues.apache.org/jira/browse/GEODE-3818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker closed GEODE-3818. > Dockerfile still points to incubator-geode.git > -- > > Key: GEODE-3818 > URL: https://issues.apache.org/jira/browse/GEODE-3818 > Project: Geode > Issue Type: Improvement > Components: build, configuration >Reporter: Arun Yadav >Priority: Major > > The docker/Dockerfile is pointing to > https://github.com/apache/incubator-geode.git. This can be now changed to > https://github.com/apache/geode.git, followed by other references to > incubator directory can be changed in Dockerfile -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-3716) Monitoring steal time in stats
[ https://issues.apache.org/jira/browse/GEODE-3716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker resolved GEODE-3716. -- Resolution: Fixed > Monitoring steal time in stats > -- > > Key: GEODE-3716 > URL: https://issues.apache.org/jira/browse/GEODE-3716 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Charlie Black >Priority: Major > Attachments: screenshot-1.png > > > In virtualized deployments of Geode some latency issues can be mapped back to > the hypervisor not giving the guest enough cycles. For this improvement, > Geode will capture stolen time as presented by the OS in the /proc/stat file > for Linux. Steal time represents the time the virtual processor is waiting > to be scheduled on the physical processor. > Geode already monitors several CPU fields and Geode will be adding in support > to capture STEAL time. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-3716) Monitoring steal time in stats
[ https://issues.apache.org/jira/browse/GEODE-3716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker closed GEODE-3716. > Monitoring steal time in stats > -- > > Key: GEODE-3716 > URL: https://issues.apache.org/jira/browse/GEODE-3716 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Charlie Black >Priority: Major > Attachments: screenshot-1.png > > > In virtualized deployments of Geode some latency issues can be mapped back to > the hypervisor not giving the guest enough cycles. For this improvement, > Geode will capture stolen time as presented by the OS in the /proc/stat file > for Linux. Steal time represents the time the virtual processor is waiting > to be scheduled on the physical processor. > Geode already monitors several CPU fields and Geode will be adding in support > to capture STEAL time. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-3709) Geode Version: 1.1.1 In one of the project we a...
[
https://issues.apache.org/jira/browse/GEODE-3709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445241#comment-16445241
]
Anthony Baker commented on GEODE-3709:
--
Is this investigation still active?
> Geode Version: 1.1.1In one of the project we a...
> -
>
> Key: GEODE-3709
> URL: https://issues.apache.org/jira/browse/GEODE-3709
> Project: Geode
> Issue Type: Improvement
> Components: client queues
>Reporter: Gregory Chase
>Priority: Major
> Attachments: 20171006-logs-stats-tds.zip, 20171020.zip,
> CacheClientProxyStats_sentBytes.gif,
> DistributionStats_receivedBytes_CacheClientProxyStats_sentBytes.gif,
> gf-rest-stats-12-05.gfs, myStatisticsArchiveFile-04-01.gfs
>
>
> Geode Version: 1.1.1
> In one of the project we are using Geode. Here is a summary of how we use it.
> - Geode servers have multiple regions.
> - Clients subscribe to the data from these regions.
> - Clients subscribe interest in all the entries, therefore they get updates
> about all the entries from creation to modification to deletion.
> - One of the regions usually has 5-10 million entries with a TTL of 24 hours.
> Most entries are added in an hour's span one after other. So when TTL kicks
> in, they are often destroyed in an hour.
> Problem:
> Every now and then we observe following message:
> Client queue for
> _gfe_non_durable_client_with_id_x.x.x.x(14229:loner):42754:e4266fc4_2_queue
> client is full.
> This seems to happen when the TTL kicks in on the region with 5-10 million
> entries. Entries start getting evicted (deleted); the updates (destroys) now
> must be sent to clients. We see that the updates do happen for a while but
> suddenly the updates stop and the queue size starts growing. This is becoming
> a major issue for smooth functioning of our production setup. Any help will
> be much appreciated.
> I did some ground work by downloading and looking at the code. I see
> reference to 2 issues #37581, #51400. But I am unable to view actual JIRA
> tickets (needs login credentials) Hopefully, it helps someone looking at the
> issue.
> Here is the pertinent code:
>@Override
> @edu.umd.cs.findbugs.annotations.SuppressWarnings("TLW_TWO_LOCK_WAIT")
> void checkQueueSizeConstraint() throws InterruptedException {
> if (this.haContainer instanceof HAContainerMap && isPrimary()) { // Fix
> for bug 39413
> if (Thread.interrupted())
> throw new InterruptedException();
> synchronized (this.putGuard) {
> if (putPermits <= 0) {
> synchronized (this.permitMon) {
> if (reconcilePutPermits() <= 0) {
> if
> (region.getSystem().getConfig().getRemoveUnresponsiveClient()) {
> isClientSlowReciever = true;
> } else {
> try {
> long logFrequency =
> CacheClientNotifier.DEFAULT_LOG_FREQUENCY;
> CacheClientNotifier ccn =
> CacheClientNotifier.getInstance();
> if (ccn != null) { // check needed for junit tests
> logFrequency = ccn.getLogFrequency();
> }
> if ((this.maxQueueSizeHitCount % logFrequency) == 0) {
> logger.warn(LocalizedMessage.create(
>
> LocalizedStrings.HARegionQueue_CLIENT_QUEUE_FOR_0_IS_FULL,
> new Object[] {region.getName()}));
> this.maxQueueSizeHitCount = 0;
> }
> ++this.maxQueueSizeHitCount;
> this.region.checkReadiness(); // fix for bug 37581
> // TODO: wait called while holding two locks
>
> this.permitMon.wait(CacheClientNotifier.eventEnqueueWaitTime);
> this.region.checkReadiness(); // fix for bug 37581
> // Fix for #51400. Allow the queue to grow beyond its
> // capacity/maxQueueSize, if it is taking a long time to
> // drain the queue, either due to a slower client or the
> // deadlock scenario mentioned in the ticket.
> reconcilePutPermits();
> if ((this.maxQueueSizeHitCount % logFrequency) == 1) {
> logger.info(LocalizedMessage
>
> .create(LocalizedStrings.HARegionQueue_RESUMING_WITH_PROCESSING_PUTS));
> }
> } catch (InterruptedException ex) {
> // TODO: The line below is meaningless. Comment it out
> later
> this.permitMon.notifyAll();
> throw ex;
> }
> }
> }
>
[jira] [Commented] (GEODE-3688) Query engine cannot compare int to long
[
https://issues.apache.org/jira/browse/GEODE-3688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445235#comment-16445235
]
Anthony Baker commented on GEODE-3688:
--
[~huynhja] can we close this issue?
> Query engine cannot compare int to long
> ---
>
> Key: GEODE-3688
> URL: https://issues.apache.org/jira/browse/GEODE-3688
> Project: Geode
> Issue Type: Bug
> Components: querying
>Reporter: Swapnil Bawaskar
>Priority: Major
>
> I created an object with a long field:
> {noformat}
> public class Customer implements Serializable {
> private long id;
> private String name;
> private String address;
> private List accounts;
> ...
> }
> {noformat}
> and inserted 10 objects (with id 0 to 9) but the simple query to get customer
> with id=9 did not give any results
> {noformat}
> gfsh>query --query=" select c.name from /customer c where c.id=9"
> Result : true
> Limit : 100
> Rows : 0
> {noformat}
> I then changed the domain object to make id an {{int}} type after which the
> query worked:
> {noformat}
> gfsh>query --query=" select c.name from /customer c where c.id=9"
> Result : true
> Limit : 100
> Rows : 1
> Result
> --
> Customer_9
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-3682) Trace displaying incorrect indexes being used
[ https://issues.apache.org/jira/browse/GEODE-3682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445227#comment-16445227 ] Anthony Baker commented on GEODE-3682: -- Do you have a way to produce this issue? Do you have a log that shows the error? > Trace displaying incorrect indexes being used > - > > Key: GEODE-3682 > URL: https://issues.apache.org/jira/browse/GEODE-3682 > Project: Geode > Issue Type: Bug > Components: querying >Reporter: nabarun >Priority: Major > > This issue is occurs in an instance with region entries with indexes present. > Running a query with trace option set shows indexes being used which are not > supposed to be used for that particular query. > This sometimes occurs when indexes are being created or destroyed in between > queries. > This also occurs if different types of queries are executed one after > another. It sometimes feels like it is showing the residue of the index used > in the previous query execution. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-3926) Lucene Query should throw an exception while lucene index is being built on existing region
[ https://issues.apache.org/jira/browse/GEODE-3926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445124#comment-16445124 ] ASF subversion and git services commented on GEODE-3926: Commit 5ce726bd7b4f8d2648fd011a807a1bcc624ddfa5 in geode's branch refs/heads/release/1.6.0 from nabarun [ https://gitbox.apache.org/repos/asf?p=geode.git;h=5ce726b ] Revert "GEODE-3926: Lucene Query Exception is thrown if queries are executed in the middle of reindexing a region (#1742)" This reverts commit 75ae584 > Lucene Query should throw an exception while lucene index is being built on > existing region > --- > > Key: GEODE-3926 > URL: https://issues.apache.org/jira/browse/GEODE-3926 > Project: Geode > Issue Type: Sub-task > Components: lucene >Reporter: Jason Huynh >Assignee: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > Time Spent: 1h 50m > Remaining Estimate: 0h > > When GEODE-3928 is complete, we will have a process to index existing data in > a region when a lucene index is added. That process may take some time. While > indexing is going on queries should not block for a long period of time or > return incorrect results. Instead the query should throw an exception > indicating that the index does not exist/is not built yet. > Acceptance: > Queries executed while indexing is going on throw an exception, rather than > blocking or returning incorrect results. > Implementation Details: > GEODE-3928 is about modifying computeRepository to actually do the indexing. > Queries also call compute repository, so they will block until > computeRepository is done. > To avoid blocking, we can make computeRepo to return an IndexRepository in > an "building" state. That index repo could contain an asynchronous task that > is actually indexing the data. Until the asynchronous task is complete, the > IndexRepostory could throw exceptions from query operations. This has the > advantage of making sure that whenever computeRepository is called, we always > at least start or make sure there is a task running to index the data. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5113) Update docs for EvictionAttributes.getMaximum() no longer throwing UnsupportedOperationException for LRU Heap
[ https://issues.apache.org/jira/browse/GEODE-5113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fred Krone updated GEODE-5113: -- Summary: Update docs for EvictionAttributes.getMaximum() no longer throwing UnsupportedOperationException for LRU Heap (was: EvictionAttributes.getMaximum() no longer throws UnsupportedOperationException for LRU Heap) > Update docs for EvictionAttributes.getMaximum() no longer throwing > UnsupportedOperationException for LRU Heap > - > > Key: GEODE-5113 > URL: https://issues.apache.org/jira/browse/GEODE-5113 > Project: Geode > Issue Type: Bug > Components: eviction >Reporter: Fred Krone >Priority: Major > > TLDR: I think we can just document this updated change. I didn't have much > time to think about it earlier today but thinking about it now I can see why > we changed this. > Previously, the EvictionAttributes.getMaximum() used to throw an > UnsupportedOperationException if the user tried to configure a Maximum on an > LRU Heap Eviction Policy (Apache Geode 1.4). Now Geode (and by extension, > GemFire) will just silently return 0. > IF this change is intentional the docs should be updated accordingly. > [http://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/EvictionAttributes.html#getMaximum--] > > in 1.4 > [https://github.com/apache/geode/blob/rel/v1.4.0/geode-core/src/main/java/org/apache/geode/internal/cache/EvictionAttributesImpl.java#L138-L144] > > in 1.5 > [https://github.com/apache/geode/blob/rel/v1.5.0/geode-core/src/main/java/org/apache/geode/internal/cache/EvictionAttributesImpl.java#L95-L101] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-3438) Collection added to itself
[
https://issues.apache.org/jira/browse/GEODE-3438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445065#comment-16445065
]
Anilkumar Gingade commented on GEODE-3438:
--
This constructor call is not used anywhere...We could go ahead and remove this
safely.
> Collection added to itself
> --
>
> Key: GEODE-3438
> URL: https://issues.apache.org/jira/browse/GEODE-3438
> Project: Geode
> Issue Type: Bug
> Components: querying
>Reporter: JC
>Priority: Major
>
> Hi
> In a recent github mirror, I've found suspicious code.
> Branch: master
> Path:
> geode-core/src/main/java/org/apache/geode/management/internal/cli/domain/DurableCqNamesResult.java
> {code:java}
> ...
> 27 private List cqNames = new ArrayList();
> ...
> 33 public DurableCqNamesResult(final String memberNameOrId, List
> cqNames) {
> 34 super(memberNameOrId);
> 35 cqNames.addAll(cqNames);
> 36 }
> {code}
> In Line 35, should `cqNames.addAll' be `this.cqNames.addAll'? This might not
> be an issue, but I wanted to report just in case.
> Thanks!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5113) EvictionAttributes.getMaximum() no longer throws UnsupportedOperationException for LRU Heap
[ https://issues.apache.org/jira/browse/GEODE-5113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fred Krone updated GEODE-5113: -- Description: TLDR: I think we can just document this updated change. I didn't have much time to think about it earlier today but thinking about it now I can see why we changed this. Previously, the EvictionAttributes.getMaximum() used to throw an UnsupportedOperationException if the user tried to configure a Maximum on an LRU Heap Eviction Policy (Apache Geode 1.4). Now Geode (and by extension, GemFire) will just silently return 0. IF this change is intentional the docs should be updated accordingly. [http://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/EvictionAttributes.html#getMaximum--] in 1.4 [https://github.com/apache/geode/blob/rel/v1.4.0/geode-core/src/main/java/org/apache/geode/internal/cache/EvictionAttributesImpl.java#L138-L144] in 1.5 [https://github.com/apache/geode/blob/rel/v1.5.0/geode-core/src/main/java/org/apache/geode/internal/cache/EvictionAttributesImpl.java#L95-L101] was: Previously, the EvictionAttributes.getMaximum() used to throw an UnsupportedOperationException if the user tried to configure a Maximum on an LRU Heap Eviction Policy (Apache Geode 1.4). Now Geode (and by extension, GemFire) will just silently return 0. IF this change is intentional the docs should be updated accordingly. We should avoid these API changes however so I think we should revert this for now if possible. If not I think we can update and move on. http://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/EvictionAttributes.html#getMaximum-- in 1.4 [https://github.com/apache/geode/blob/rel/v1.4.0/geode-core/src/main/java/org/apache/geode/internal/cache/EvictionAttributesImpl.java#L138-L144] in 1.5 [https://github.com/apache/geode/blob/rel/v1.5.0/geode-core/src/main/java/org/apache/geode/internal/cache/EvictionAttributesImpl.java#L95-L101] > EvictionAttributes.getMaximum() no longer throws > UnsupportedOperationException for LRU Heap > --- > > Key: GEODE-5113 > URL: https://issues.apache.org/jira/browse/GEODE-5113 > Project: Geode > Issue Type: Bug > Components: eviction >Reporter: Fred Krone >Priority: Major > > TLDR: I think we can just document this updated change. I didn't have much > time to think about it earlier today but thinking about it now I can see why > we changed this. > Previously, the EvictionAttributes.getMaximum() used to throw an > UnsupportedOperationException if the user tried to configure a Maximum on an > LRU Heap Eviction Policy (Apache Geode 1.4). Now Geode (and by extension, > GemFire) will just silently return 0. > IF this change is intentional the docs should be updated accordingly. > [http://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/EvictionAttributes.html#getMaximum--] > > in 1.4 > [https://github.com/apache/geode/blob/rel/v1.4.0/geode-core/src/main/java/org/apache/geode/internal/cache/EvictionAttributesImpl.java#L138-L144] > > in 1.5 > [https://github.com/apache/geode/blob/rel/v1.5.0/geode-core/src/main/java/org/apache/geode/internal/cache/EvictionAttributesImpl.java#L95-L101] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-3508) Removed unused internal deprecated classes.
[
https://issues.apache.org/jira/browse/GEODE-3508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445059#comment-16445059
]
Anthony Baker commented on GEODE-3508:
--
[~prhomberg] can this issue be closed?
> Removed unused internal deprecated classes.
> ---
>
> Key: GEODE-3508
> URL: https://issues.apache.org/jira/browse/GEODE-3508
> Project: Geode
> Issue Type: Improvement
>Reporter: Patrick Rhomberg
>Priority: Major
>
> The following classes are internal, deprecated, and (essentially) unused.
> {noformat}
> geode-core/src/main/java/org/apache/geode/distributed/internal/MessageFactory.java
> geode-core/src/main/java/org/apache/geode/internal/process/ClusterConfigurationNotAvailableException.java
> geode-core/src/main/java/org/apache/geode/management/internal/configuration/utils/DtdResolver.java
> {noformat}
> They may be safely deleted.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-3519) servers are not locking on remove or invalidate ops initiated by clients
[ https://issues.apache.org/jira/browse/GEODE-3519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445058#comment-16445058 ] Anthony Baker commented on GEODE-3519: -- [~bschuchardt] can this issue be closed? > servers are not locking on remove or invalidate ops initiated by clients > > > Key: GEODE-3519 > URL: https://issues.apache.org/jira/browse/GEODE-3519 > Project: Geode > Issue Type: Bug > Components: client/server >Reporter: Bruce Schuchardt >Assignee: Bruce Schuchardt >Priority: Major > > While debugging a DLockToken leak I found that a Scope.GLOBAL region in a > server was recording CachePerfStats.conflatedEvents. This should be zero in > a Scope.GLOBAL region because each operation on the region is supposed to be > performed while holding a distributed lock on the affected key. > The problem stems from DistributedRegion not overriding the "basicBridge" > operations that handle these events and surrounding the superclass's method > with locking. > The only operations currently performing correct locking are "put" and > "replace". -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-3451) Data inconsistency detected in distributed ack test on empty region
[
https://issues.apache.org/jira/browse/GEODE-3451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-3451:
-
Labels: ci (was: )
> Data inconsistency detected in distributed ack test on empty region
> ---
>
> Key: GEODE-3451
> URL: https://issues.apache.org/jira/browse/GEODE-3451
> Project: Geode
> Issue Type: Bug
> Components: regions
>Reporter: Nick Reich
>Priority: Major
> Labels: ci
>
> {noformat}
> org.apache.geode.cache30.DistributedAckRegionCCEOffHeapDUnitTest >
> testConcurrentEventsOnEmptyRegion FAILED
> org.junit.ComparisonFailure: region contents are not consistent for
> cckey8 expected: but was:
> {noformat}
> Note: test failure was not readily reproduced
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-3438) Collection added to itself
[
https://issues.apache.org/jira/browse/GEODE-3438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445057#comment-16445057
]
Anthony Baker commented on GEODE-3438:
--
[~lifove] sorry for the delayed response. Thanks for this report! I agree
that we need to look into this issue.
> Collection added to itself
> --
>
> Key: GEODE-3438
> URL: https://issues.apache.org/jira/browse/GEODE-3438
> Project: Geode
> Issue Type: Bug
> Components: querying
>Reporter: JC
>Priority: Major
>
> Hi
> In a recent github mirror, I've found suspicious code.
> Branch: master
> Path:
> geode-core/src/main/java/org/apache/geode/management/internal/cli/domain/DurableCqNamesResult.java
> {code:java}
> ...
> 27 private List cqNames = new ArrayList();
> ...
> 33 public DurableCqNamesResult(final String memberNameOrId, List
> cqNames) {
> 34 super(memberNameOrId);
> 35 cqNames.addAll(cqNames);
> 36 }
> {code}
> In Line 35, should `cqNames.addAll' be `this.cqNames.addAll'? This might not
> be an issue, but I wanted to report just in case.
> Thanks!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-3429) Deploy does not register Functions whose parent classes live in separate jar files
[
https://issues.apache.org/jira/browse/GEODE-3429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445054#comment-16445054
]
Anthony Baker commented on GEODE-3429:
--
[~khowe] does this issue still exist?
> Deploy does not register Functions whose parent classes live in separate jar
> files
> --
>
> Key: GEODE-3429
> URL: https://issues.apache.org/jira/browse/GEODE-3429
> Project: Geode
> Issue Type: Bug
> Components: gfsh, management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>Priority: Major
>
> Consider the following scenario:
> Abstract.jar - public abstract class AbstractFunction implements Function
> {...}
> Concrete.jar - public class ConcreteFunction extends AbstractFunction {...}
> When Concrete.jar is deployed, we are not registering ConcreteFunction.
> Everything works as expected if AbstractFunction and ConcreteFunction live in
> the same jar.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-3195) Create new geode-example about querying
[ https://issues.apache.org/jira/browse/GEODE-3195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker resolved GEODE-3195. -- Resolution: Fixed > Create new geode-example about querying > --- > > Key: GEODE-3195 > URL: https://issues.apache.org/jira/browse/GEODE-3195 > Project: Geode > Issue Type: New Feature > Components: querying >Reporter: Karen Smoler Miller >Assignee: Karen Smoler Miller >Priority: Major > > The more examples, the better. . . > Create an example that demonstrates how to do some simple OQL queries. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-3195) Create new geode-example about querying
[ https://issues.apache.org/jira/browse/GEODE-3195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker closed GEODE-3195. > Create new geode-example about querying > --- > > Key: GEODE-3195 > URL: https://issues.apache.org/jira/browse/GEODE-3195 > Project: Geode > Issue Type: New Feature > Components: querying >Reporter: Karen Smoler Miller >Assignee: Karen Smoler Miller >Priority: Major > > The more examples, the better. . . > Create an example that demonstrates how to do some simple OQL queries. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-3184) Clean up session replication testing
[ https://issues.apache.org/jira/browse/GEODE-3184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker resolved GEODE-3184. -- Resolution: Fixed > Clean up session replication testing > > > Key: GEODE-3184 > URL: https://issues.apache.org/jira/browse/GEODE-3184 > Project: Geode > Issue Type: Improvement > Components: http session >Reporter: David Anuta >Assignee: David Anuta >Priority: Minor > > Would be good to review the code base and make sure methods are properly > organized. > Also, the previous session replication testing is still in place in the > extensions folder. This needs to be reviewed and any tests not covered by > cargo should be transferred over into the new cargo replication testing. An > example of something within this that needs to be cleaned up would be > QueryCommand and CommandServlet classes, which are both in the > extensions/geode-modules and extensions/session-testing-war projects. the > QueryCommand and Command Servlet class within the extensions/geode-modules > project could be removed if the previous session tests were all ported to > cargo and then removed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-3184) Clean up session replication testing
[ https://issues.apache.org/jira/browse/GEODE-3184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker closed GEODE-3184. > Clean up session replication testing > > > Key: GEODE-3184 > URL: https://issues.apache.org/jira/browse/GEODE-3184 > Project: Geode > Issue Type: Improvement > Components: http session >Reporter: David Anuta >Assignee: David Anuta >Priority: Minor > > Would be good to review the code base and make sure methods are properly > organized. > Also, the previous session replication testing is still in place in the > extensions folder. This needs to be reviewed and any tests not covered by > cargo should be transferred over into the new cargo replication testing. An > example of something within this that needs to be cleaned up would be > QueryCommand and CommandServlet classes, which are both in the > extensions/geode-modules and extensions/session-testing-war projects. the > QueryCommand and Command Servlet class within the extensions/geode-modules > project could be removed if the previous session tests were all ported to > cargo and then removed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-3157) Application servers need shiro and commons lang when running geode session modules
[ https://issues.apache.org/jira/browse/GEODE-3157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445044#comment-16445044 ] Anthony Baker commented on GEODE-3157: -- [~upthewaterspout] can this issue be closed? > Application servers need shiro and commons lang when running geode session > modules > -- > > Key: GEODE-3157 > URL: https://issues.apache.org/jira/browse/GEODE-3157 > Project: Geode > Issue Type: Bug > Components: http session >Reporter: Dan Smith >Priority: Major > > Our testing of the session modules with GEODE-2901 discovered that the > session modules now require the user to add shiro and commons-lang to the > classpath of their application server in order for the session module to work. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-3151) Configuration Parameter Based Registration Of internal Region over JMX
[ https://issues.apache.org/jira/browse/GEODE-3151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker closed GEODE-3151. > Configuration Parameter Based Registration Of internal Region over JMX > -- > > Key: GEODE-3151 > URL: https://issues.apache.org/jira/browse/GEODE-3151 > Project: Geode > Issue Type: New Feature > Components: general >Reporter: dinesh akhand >Priority: Major > > I am Adding the Configuration parameter which will have the internal region > name/function name > which we want to register in JMX. > currently for Internal Region Bean is not getting registered in JMX. > I want to make this as configurable. > If user provided internal region names in configuration[property file ] then > bean should get register in JMX. > Current use: we want to register the async queue associated internal region > in JMX. > future scope: using same parameter we want to register few functions to JMX. > output : only defined internal regions in property file are going to be show > in JMX. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-3151) Configuration Parameter Based Registration Of internal Region over JMX
[ https://issues.apache.org/jira/browse/GEODE-3151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker resolved GEODE-3151. -- Resolution: Won't Do Closing due to inactivity. Please reopen if needed. > Configuration Parameter Based Registration Of internal Region over JMX > -- > > Key: GEODE-3151 > URL: https://issues.apache.org/jira/browse/GEODE-3151 > Project: Geode > Issue Type: New Feature > Components: general >Reporter: dinesh akhand >Priority: Major > > I am Adding the Configuration parameter which will have the internal region > name/function name > which we want to register in JMX. > currently for Internal Region Bean is not getting registered in JMX. > I want to make this as configurable. > If user provided internal region names in configuration[property file ] then > bean should get register in JMX. > Current use: we want to register the async queue associated internal region > in JMX. > future scope: using same parameter we want to register few functions to JMX. > output : only defined internal regions in property file are going to be show > in JMX. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-3133) New api request for Logger: errorOnce(Exception)
[ https://issues.apache.org/jira/browse/GEODE-3133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-3133: - Issue Type: Improvement (was: Bug) > New api request for Logger: errorOnce(Exception) > - > > Key: GEODE-3133 > URL: https://issues.apache.org/jira/browse/GEODE-3133 > Project: Geode > Issue Type: Improvement > Components: tools >Reporter: Brian Rowe >Priority: Major > > Many times we want to log certain error once only. For that we need to > maintain state of that exception in class. Thus, we were thinking to add this > functionality at logger level, so that any component can use that. > It would also be useful to make this behavior time sensitive, i.e. log this > exception only once in any five minute window. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-3130) Refactor communication mode handling in AcceptorImpl.handleNewClientConnection
[ https://issues.apache.org/jira/browse/GEODE-3130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445041#comment-16445041 ] Anthony Baker commented on GEODE-3130: -- [~WireBaron] can this issue be closed? > Refactor communication mode handling in AcceptorImpl.handleNewClientConnection > -- > > Key: GEODE-3130 > URL: https://issues.apache.org/jira/browse/GEODE-3130 > Project: Geode > Issue Type: Bug > Components: client/server >Reporter: Brian Rowe >Priority: Major > > This is pending review feedback from the implementation of 2995 which didn't > get addressed prior to the merge. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-3123) Complete OptionAliasesIntegrationTest
[
https://issues.apache.org/jira/browse/GEODE-3123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-3123:
-
Issue Type: Task (was: Bug)
> Complete OptionAliasesIntegrationTest
> -
>
> Key: GEODE-3123
> URL: https://issues.apache.org/jira/browse/GEODE-3123
> Project: Geode
> Issue Type: Task
> Components: gfsh
>Reporter: Emily Yeh
>Priority: Major
>
> {{OptionAliasesIntegrationTest.java}} was created for GEODE-2818. However,
> implementation could not be completed because it became impractical to make
> temporary clients, authorizations, etc. to continue testing all the commands
> affected by GEODE-2818. If a more practical way to achieve these tasks
> becomes available, these tests should be completed. (Refer to
> {{OptionAliasesParsingTest.java}} for a full list of all the commands to be
> tested.)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-3116) Unable to import data (No such file or directory)
[
https://issues.apache.org/jira/browse/GEODE-3116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445038#comment-16445038
]
Anthony Baker commented on GEODE-3116:
--
Hi [~abhsc] sorry for the delayed response. Have you checked the docs for this
command:
[https://geode.apache.org/docs/guide/15/tools_modules/gfsh/command-pages/import.html#topic_jw2_2ld_2l]
I would guess that the data file is not accessible from server1.
> Unable to import data (No such file or directory)
> -
>
> Key: GEODE-3116
> URL: https://issues.apache.org/jira/browse/GEODE-3116
> Project: Geode
> Issue Type: Bug
>Reporter: Alan Barrington-Hughes
>Priority: Major
>
> I am unable to import data into a GEODE cache server.
> {code:none}
> gfsh>import data --region=TEST --file=/data/basedata.gfd --member=server1
> Could not process command due to GemFire error. /data/basedata.gfd (No such
> file or directory)
> gfsh>sh ls -asl /data
> total 1486892
> 0 drwxr-xr-x 1 1000 ftp 204 Jun 22 2017 .
> 4 drwxr-xr-x 32 root root 4096 Jun 22 00:09 ..
> 1251476 -rw-r--r-- 1 1000 ftp 1281509737 Jun 21 16:18 basedata.gfd
> gfsh>version
> 1.1.0
> {code}
> logs are not illuminating. Please advise of possible course of action.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-3109) Correct artifacts published for Geode modules
[
https://issues.apache.org/jira/browse/GEODE-3109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker resolved GEODE-3109.
--
Resolution: Fixed
> Correct artifacts published for Geode modules
> -
>
> Key: GEODE-3109
> URL: https://issues.apache.org/jira/browse/GEODE-3109
> Project: Geode
> Issue Type: Task
> Components: http session
>Reporter: Jens Deppe
>Priority: Major
>
> Currently we are publishing Geode modules artifacts (jars) but these are not
> useful in themselves. We should be publishing the artifacts produced by
> {{geode-modules-assembly}} (zips) which contain not just the necessary code,
> but also configuration files.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-3102) IndexOutOfBoundsException In Replicated Region With TTL
[ https://issues.apache.org/jira/browse/GEODE-3102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16444964#comment-16444964 ] Jeff Nadler commented on GEODE-3102: I no longer work at the company where I ran into this. It is (or was) a real problem for us, but I'm not in a position to reproduce it. Feel free to close. > IndexOutOfBoundsException In Replicated Region With TTL > --- > > Key: GEODE-3102 > URL: https://issues.apache.org/jira/browse/GEODE-3102 > Project: Geode > Issue Type: Bug > Components: regions >Reporter: Jeff Nadler >Priority: Major > > We have a replicated region with TTL. After running without issue for quite > some time, we started getting the following errors in our logs - almost 5gb > of the same message over and over on one server node: > [severe 2017/06/15 23:54:10.091 UTC server-geode-va-1.pdx.aerohive.internal > tid=0x41] GemFire garbage > collection service encountered an unexpected exception > java.lang.IndexOutOfBoundsException: fromIndex < 0: -1 > at java.util.BitSet.checkRange(BitSet.java:362) > at java.util.BitSet.get(BitSet.java:645) > at > org.apache.geode.internal.cache.versions.RegionVersionHolder.addBitSetExceptions(RegionVersionHolder.java:318) > at > org.apache.geode.internal.cache.versions.RegionVersionHolder.mergeBitSet(RegionVersionHolder.java:254) > at > org.apache.geode.internal.cache.versions.RegionVersionHolder.removeExceptionsOlderThan(RegionVersionHolder.java:399) > at > org.apache.geode.internal.cache.versions.RegionVersionVector.pruneOldExceptions(RegionVersionVector.java:1347) > at > org.apache.geode.internal.cache.TombstoneService$ReplicateTombstoneSweeper.expireBatch(TombstoneService.java:535) > at > org.apache.geode.internal.cache.TombstoneService$ReplicateTombstoneSweeper.checkExpiredTombstoneGC(TombstoneService.java:596) > at > org.apache.geode.internal.cache.TombstoneService$TombstoneSweeper.run(TombstoneService.java:882) > at java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-3102) IndexOutOfBoundsException In Replicated Region With TTL
[ https://issues.apache.org/jira/browse/GEODE-3102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16444961#comment-16444961 ] Anthony Baker commented on GEODE-3102: -- Hi [~jnadler] thanks for the report. Sorry for the delay in responding. Are you still encountering this issue? > IndexOutOfBoundsException In Replicated Region With TTL > --- > > Key: GEODE-3102 > URL: https://issues.apache.org/jira/browse/GEODE-3102 > Project: Geode > Issue Type: Bug > Components: regions >Reporter: Jeff Nadler >Priority: Major > > We have a replicated region with TTL. After running without issue for quite > some time, we started getting the following errors in our logs - almost 5gb > of the same message over and over on one server node: > [severe 2017/06/15 23:54:10.091 UTC server-geode-va-1.pdx.aerohive.internal > tid=0x41] GemFire garbage > collection service encountered an unexpected exception > java.lang.IndexOutOfBoundsException: fromIndex < 0: -1 > at java.util.BitSet.checkRange(BitSet.java:362) > at java.util.BitSet.get(BitSet.java:645) > at > org.apache.geode.internal.cache.versions.RegionVersionHolder.addBitSetExceptions(RegionVersionHolder.java:318) > at > org.apache.geode.internal.cache.versions.RegionVersionHolder.mergeBitSet(RegionVersionHolder.java:254) > at > org.apache.geode.internal.cache.versions.RegionVersionHolder.removeExceptionsOlderThan(RegionVersionHolder.java:399) > at > org.apache.geode.internal.cache.versions.RegionVersionVector.pruneOldExceptions(RegionVersionVector.java:1347) > at > org.apache.geode.internal.cache.TombstoneService$ReplicateTombstoneSweeper.expireBatch(TombstoneService.java:535) > at > org.apache.geode.internal.cache.TombstoneService$ReplicateTombstoneSweeper.checkExpiredTombstoneGC(TombstoneService.java:596) > at > org.apache.geode.internal.cache.TombstoneService$TombstoneSweeper.run(TombstoneService.java:882) > at java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-4919) Alter regions must update PRconfig
[ https://issues.apache.org/jira/browse/GEODE-4919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller resolved GEODE-4919. > Alter regions must update PRconfig > -- > > Key: GEODE-4919 > URL: https://issues.apache.org/jira/browse/GEODE-4919 > Project: Geode > Issue Type: Bug > Components: wan >Reporter: nabarun >Assignee: Karen Smoler Miller >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 40m > Remaining Estimate: 0h > > Altering the region to add parallel gateway sender to non colocated regions > must fail. > The check is done using the PartitionRegionConfig but we never update it > after altering the region to add the gateway sender. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-5117) Favor SetPropName() methods over Set(string, string) for system properties
Ryan McMahon created GEODE-5117: --- Summary: Favor SetPropName() methods over Set(string, string) for system properties Key: GEODE-5117 URL: https://issues.apache.org/jira/browse/GEODE-5117 Project: Geode Issue Type: Improvement Components: native client Reporter: Ryan McMahon Currently, system properties can be specified programmatically using the Set(key, value) method on the CacheFactory. This leaves room for error because its possible to enter a key that doesn't exist or a key that has been deprecated. Also, it is not consistent with our Region/Cache settings API which uses methods for each property e.g. SetRegionTimeToLive(). It would be better to have a method for each supported system property e.g. SetLogLevel() and SetCacheXml(). That way, deprecating system settings is enforced at compile time, and the system settings API is consistent with the Region/Cache settings API. Also it is more self-documenting than the current API. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4919) Alter regions must update PRconfig
[ https://issues.apache.org/jira/browse/GEODE-4919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16444953#comment-16444953 ] ASF subversion and git services commented on GEODE-4919: Commit 65da520e209055bf1e266d7c8acb325e6ed6ba3d in geode's branch refs/heads/develop from Karen Miller [ https://gitbox.apache.org/repos/asf?p=geode.git;h=65da520 ] GEDOE-4919 Make WAN region creation restrictions more prominent (#1829) * GEDOE-4919 Make WAN region creation restrictions more prominent * GEODE-4919 Revise wording per review > Alter regions must update PRconfig > -- > > Key: GEODE-4919 > URL: https://issues.apache.org/jira/browse/GEODE-4919 > Project: Geode > Issue Type: Bug > Components: wan >Reporter: nabarun >Assignee: Karen Smoler Miller >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 40m > Remaining Estimate: 0h > > Altering the region to add parallel gateway sender to non colocated regions > must fail. > The check is done using the PartitionRegionConfig but we never update it > after altering the region to add the gateway sender. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (GEODE-2121) add DLockTest, MembershipTest, ClientServerTest, ClientSubscriptionTest and RestAPITest categories
[ https://issues.apache.org/jira/browse/GEODE-2121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruce Schuchardt reopened GEODE-2121: - New tests have been introduced that do not have categories. There are also Redis tests that need to be categorized. > add DLockTest, MembershipTest, ClientServerTest, ClientSubscriptionTest and > RestAPITest categories > -- > > Key: GEODE-2121 > URL: https://issues.apache.org/jira/browse/GEODE-2121 > Project: Geode > Issue Type: Test > Components: client queues, client/server, distributed lock service, > membership, rest (dev), serialization >Reporter: Bruce Schuchardt >Assignee: Bruce Schuchardt >Priority: Major > Fix For: 1.1.0 > > > I need these test categories in order to run code-coverage analysis for the > components I usually work with. The categories should be added to the > appropriate unit tests. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (GEODE-2542) LocatorDUnitTest and LocatorUDPSecurityDUnitTest fail frequently in Geode Nightly Build
[
https://issues.apache.org/jira/browse/GEODE-2542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16444917#comment-16444917
]
Michael Dodge edited comment on GEODE-2542 at 4/19/18 10:46 PM:
{{testStartTwoLocators}} includes a 10-second wait for the view to have five
members. Is this test flaky simply because under some conditions it takes
longer than 10 seconds without there being an error condition, e.g., one of the
machines is very, very slow? After running it 700 times locally there were zero
failures.
was (Author: pivotalsarge):
{{testStartTwoLocators}} includes a 10-second wait for the view to have five
members. Is this test flaky simply because under some conditions it takes
longer than 10 seconds without there being an error condition, e.g., one of the
machines is very, very slow?
> LocatorDUnitTest and LocatorUDPSecurityDUnitTest fail frequently in Geode
> Nightly Build
> ---
>
> Key: GEODE-2542
> URL: https://issues.apache.org/jira/browse/GEODE-2542
> Project: Geode
> Issue Type: Bug
> Components: locator
>Reporter: Kirk Lund
>Assignee: Brian Baynes
>Priority: Major
> Labels: Flaky
>
> testMultipleLocators:
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.NamedRunnable.run in VM 0 running on Host
> asf919.gq1.ygridcore.net with 5 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:377)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:347)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:280)
> at
> org.apache.geode.distributed.LocatorDUnitTest.testMultipleLocators(LocatorDUnitTest.java:1567)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.i
[jira] [Created] (GEODE-5116) Identify and document changes to supported system properties
Ryan McMahon created GEODE-5116: --- Summary: Identify and document changes to supported system properties Key: GEODE-5116 URL: https://issues.apache.org/jira/browse/GEODE-5116 Project: Geode Issue Type: Task Components: native client Reporter: Ryan McMahon It has been identified that some system properties were no longer needed and therefore have been removed or deprecated in our code. We need to ensure that the properties in the geode.properties file in the defaultSystem directory are correct and up-to-date. Also, we need to ensure that any documentation contain the correct properties and their descriptions. This could involve going through each property and ensuring that it is supported and tested, and removing the ones which are not. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-2542) LocatorDUnitTest and LocatorUDPSecurityDUnitTest fail frequently in Geode Nightly Build
[
https://issues.apache.org/jira/browse/GEODE-2542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16444917#comment-16444917
]
Michael Dodge commented on GEODE-2542:
--
{{testStartTwoLocators}} includes a 10-second wait for the view to have five
members. Is this test flaky simply because under some conditions it takes
longer than 10 seconds without there being an error condition, e.g., one of the
machines is very, very slow?
> LocatorDUnitTest and LocatorUDPSecurityDUnitTest fail frequently in Geode
> Nightly Build
> ---
>
> Key: GEODE-2542
> URL: https://issues.apache.org/jira/browse/GEODE-2542
> Project: Geode
> Issue Type: Bug
> Components: locator
>Reporter: Kirk Lund
>Assignee: Brian Baynes
>Priority: Major
> Labels: Flaky
>
> testMultipleLocators:
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.NamedRunnable.run in VM 0 running on Host
> asf919.gq1.ygridcore.net with 5 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:377)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:347)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:280)
> at
> org.apache.geode.distributed.LocatorDUnitTest.testMultipleLocators(LocatorDUnitTest.java:1567)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
> at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
> at
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.Delegat
[jira] [Updated] (GEODE-5113) EvictionAttributes.getMaximum() no longer throws UnsupportedOperationException for LRU Heap
[ https://issues.apache.org/jira/browse/GEODE-5113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fred Krone updated GEODE-5113: -- Description: Previously, the EvictionAttributes.getMaximum() used to throw an UnsupportedOperationException if the user tried to configure a Maximum on an LRU Heap Eviction Policy (Apache Geode 1.4). Now Geode (and by extension, GemFire) will just silently return 0. IF this change is intentional the docs should be updated accordingly. We should avoid these API changes however so I think we should revert this for now if possible. If not I think we can update and move on. http://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/EvictionAttributes.html#getMaximum-- in 1.4 [https://github.com/apache/geode/blob/rel/v1.4.0/geode-core/src/main/java/org/apache/geode/internal/cache/EvictionAttributesImpl.java#L138-L144] in 1.5 [https://github.com/apache/geode/blob/rel/v1.5.0/geode-core/src/main/java/org/apache/geode/internal/cache/EvictionAttributesImpl.java#L95-L101] was: Previously, the EvictionAttributes.getMaximum() used to throw an UnsupportedOperationException if the user tried to configure a Maximum on an LRU Heap Eviction Policy (Apache Geode 1.4). Now Geode (and by extension, GemFire) will just silently return 0. in 1.4 [https://github.com/apache/geode/blob/rel/v1.4.0/geode-core/src/main/java/org/apache/geode/internal/cache/EvictionAttributesImpl.java#L138-L144] in 1.5 [https://github.com/apache/geode/blob/rel/v1.5.0/geode-core/src/main/java/org/apache/geode/internal/cache/EvictionAttributesImpl.java#L95-L101] > EvictionAttributes.getMaximum() no longer throws > UnsupportedOperationException for LRU Heap > --- > > Key: GEODE-5113 > URL: https://issues.apache.org/jira/browse/GEODE-5113 > Project: Geode > Issue Type: Bug > Components: eviction >Reporter: Fred Krone >Priority: Major > > > Previously, the EvictionAttributes.getMaximum() used to throw an > UnsupportedOperationException if the user tried to configure a Maximum on an > LRU Heap Eviction Policy (Apache Geode 1.4). Now Geode (and by extension, > GemFire) will just silently return 0. > IF this change is intentional the docs should be updated accordingly. We > should avoid these API changes however so I think we should revert this for > now if possible. If not I think we can update and move on. > http://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/EvictionAttributes.html#getMaximum-- > > in 1.4 > [https://github.com/apache/geode/blob/rel/v1.4.0/geode-core/src/main/java/org/apache/geode/internal/cache/EvictionAttributesImpl.java#L138-L144] > > in 1.5 > [https://github.com/apache/geode/blob/rel/v1.5.0/geode-core/src/main/java/org/apache/geode/internal/cache/EvictionAttributesImpl.java#L95-L101] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (GEODE-4647) Add a new stat for AyncEventQueue/GatewaySender to track secondaryEventsQueueSize
[ https://issues.apache.org/jira/browse/GEODE-4647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller reopened GEODE-4647: Assignee: Karen Smoler Miller (was: xiaojian zhou) Reopening ticket in order to do the documentation. > Add a new stat for AyncEventQueue/GatewaySender to track > secondaryEventsQueueSize > - > > Key: GEODE-4647 > URL: https://issues.apache.org/jira/browse/GEODE-4647 > Project: Geode > Issue Type: Bug > Components: docs, wan >Reporter: Jason Huynh >Assignee: Karen Smoler Miller >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 4.5h > Remaining Estimate: 0h > > Currently we have eventsQueueSize which tells us how big the queue is based > on how many primary events are in the queue. > It would be nice to have the same type of stat for how many secondary events > are in the queue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (GEODE-2542) LocatorDUnitTest and LocatorUDPSecurityDUnitTest fail frequently in Geode Nightly Build
[
https://issues.apache.org/jira/browse/GEODE-2542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16444848#comment-16444848
]
Michael Dodge edited comment on GEODE-2542 at 4/19/18 10:07 PM:
The last stack trace in the comments no longer appears to be possible:
{noformat}
protected byte[] getClusterSecretKey() {
if (this.clusterEncryptor != null) {
return this.clusterEncryptor.getSecretBytes();
} else {
return null;
}
}
{noformat}
was (Author: pivotalsarge):
The last stack trace in the comments no longer appears to be possible:
{quote} protected byte[] getClusterSecretKey() {
if (this.clusterEncryptor != null) {
return this.clusterEncryptor.getSecretBytes();
} else {
return null;
}
}
{quote}
> LocatorDUnitTest and LocatorUDPSecurityDUnitTest fail frequently in Geode
> Nightly Build
> ---
>
> Key: GEODE-2542
> URL: https://issues.apache.org/jira/browse/GEODE-2542
> Project: Geode
> Issue Type: Bug
> Components: locator
>Reporter: Kirk Lund
>Assignee: Brian Baynes
>Priority: Major
> Labels: Flaky
>
> testMultipleLocators:
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.NamedRunnable.run in VM 0 running on Host
> asf919.gq1.ygridcore.net with 5 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:377)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:347)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:280)
> at
> org.apache.geode.distributed.LocatorDUnitTest.testMultipleLocators(LocatorDUnitTest.java:1567)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
> at c
[jira] [Comment Edited] (GEODE-2542) LocatorDUnitTest and LocatorUDPSecurityDUnitTest fail frequently in Geode Nightly Build
[
https://issues.apache.org/jira/browse/GEODE-2542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16444848#comment-16444848
]
Michael Dodge edited comment on GEODE-2542 at 4/19/18 10:05 PM:
The last stack trace in the comments no longer appears to be possible:
{quote} protected byte[] getClusterSecretKey() {
if (this.clusterEncryptor != null) {
return this.clusterEncryptor.getSecretBytes();
} else {
return null;
}
}
{quote}
was (Author: pivotalsarge):
The last stack trace in the comments no longer appears to be possible:
{{
protected byte[] getClusterSecretKey() {
if (this.clusterEncryptor != null) {
return this.clusterEncryptor.getSecretBytes();
} else {
return null;
}
}
}}
> LocatorDUnitTest and LocatorUDPSecurityDUnitTest fail frequently in Geode
> Nightly Build
> ---
>
> Key: GEODE-2542
> URL: https://issues.apache.org/jira/browse/GEODE-2542
> Project: Geode
> Issue Type: Bug
> Components: locator
>Reporter: Kirk Lund
>Assignee: Brian Baynes
>Priority: Major
> Labels: Flaky
>
> testMultipleLocators:
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.NamedRunnable.run in VM 0 running on Host
> asf919.gq1.ygridcore.net with 5 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:377)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:347)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:280)
> at
> org.apache.geode.distributed.LocatorDUnitTest.testMultipleLocators(LocatorDUnitTest.java:1567)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
> at com.sun.proxy.$Prox
[jira] [Commented] (GEODE-5115) jdbc-connection does not provide a way to configure the connection pool
[ https://issues.apache.org/jira/browse/GEODE-5115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16444865#comment-16444865 ] Darrel Schneider commented on GEODE-5115: - As a workaround you can set the system property "hikaricp.configurationFile" to a file that contains the pool properties you want to configure. > jdbc-connection does not provide a way to configure the connection pool > --- > > Key: GEODE-5115 > URL: https://issues.apache.org/jira/browse/GEODE-5115 > Project: Geode > Issue Type: Bug > Components: extensions >Reporter: Darrel Schneider >Priority: Major > > The jdbc-connection allows parameters to be configured. These parameters are > always given to the jdbc data source. But the connection pool (implemented > using HikariCP) can not be configured. The parameters are always passed on to > the jdbc data source. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-3102) IndexOutOfBoundsException In Replicated Region With TTL
[ https://issues.apache.org/jira/browse/GEODE-3102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-3102: - Component/s: regions > IndexOutOfBoundsException In Replicated Region With TTL > --- > > Key: GEODE-3102 > URL: https://issues.apache.org/jira/browse/GEODE-3102 > Project: Geode > Issue Type: Bug > Components: regions >Reporter: Jeff Nadler >Priority: Major > > We have a replicated region with TTL. After running without issue for quite > some time, we started getting the following errors in our logs - almost 5gb > of the same message over and over on one server node: > [severe 2017/06/15 23:54:10.091 UTC server-geode-va-1.pdx.aerohive.internal > tid=0x41] GemFire garbage > collection service encountered an unexpected exception > java.lang.IndexOutOfBoundsException: fromIndex < 0: -1 > at java.util.BitSet.checkRange(BitSet.java:362) > at java.util.BitSet.get(BitSet.java:645) > at > org.apache.geode.internal.cache.versions.RegionVersionHolder.addBitSetExceptions(RegionVersionHolder.java:318) > at > org.apache.geode.internal.cache.versions.RegionVersionHolder.mergeBitSet(RegionVersionHolder.java:254) > at > org.apache.geode.internal.cache.versions.RegionVersionHolder.removeExceptionsOlderThan(RegionVersionHolder.java:399) > at > org.apache.geode.internal.cache.versions.RegionVersionVector.pruneOldExceptions(RegionVersionVector.java:1347) > at > org.apache.geode.internal.cache.TombstoneService$ReplicateTombstoneSweeper.expireBatch(TombstoneService.java:535) > at > org.apache.geode.internal.cache.TombstoneService$ReplicateTombstoneSweeper.checkExpiredTombstoneGC(TombstoneService.java:596) > at > org.apache.geode.internal.cache.TombstoneService$TombstoneSweeper.run(TombstoneService.java:882) > at java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-3096) Refactor and unify GFSH http clients
[ https://issues.apache.org/jira/browse/GEODE-3096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16444857#comment-16444857 ] Anthony Baker commented on GEODE-3096: -- [~khowe] can this issue be closed? > Refactor and unify GFSH http clients > > > Key: GEODE-3096 > URL: https://issues.apache.org/jira/browse/GEODE-3096 > Project: Geode > Issue Type: Improvement > Components: gfsh, management >Reporter: Jared Stewart >Assignee: Jared Stewart >Priority: Major > > We currently have at least two separate HTTP clients used by GFSH over HTTP. > (See SimpleHttpRequester, AbstractHttpOperationInvoker, > RestHttpOperationInvoker, SimpleHttpOperationInvoker). This results in a lot > of duplicated and inconsistent logic. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-5115) jdbc-connection does not provide a way to configure the connection pool
Darrel Schneider created GEODE-5115: --- Summary: jdbc-connection does not provide a way to configure the connection pool Key: GEODE-5115 URL: https://issues.apache.org/jira/browse/GEODE-5115 Project: Geode Issue Type: Bug Components: extensions Reporter: Darrel Schneider The jdbc-connection allows parameters to be configured. These parameters are always given to the jdbc data source. But the connection pool (implemented using HikariCP) can not be configured. The parameters are always passed on to the jdbc data source. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-3051) Removing obsolete SSL handling in `AcceptorImpl.accept` catch block
[ https://issues.apache.org/jira/browse/GEODE-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker closed GEODE-3051. > Removing obsolete SSL handling in `AcceptorImpl.accept` catch block > --- > > Key: GEODE-3051 > URL: https://issues.apache.org/jira/browse/GEODE-3051 > Project: Geode > Issue Type: Improvement > Components: client/server >Affects Versions: 1.1.1 >Reporter: Udo Kohlmeyer >Assignee: Galen O'Sullivan >Priority: Major > > SSL handshake is now done in a separate thread and will never reach the > handler code which is being removed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-3051) Removing obsolete SSL handling in `AcceptorImpl.accept` catch block
[ https://issues.apache.org/jira/browse/GEODE-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker resolved GEODE-3051. -- Resolution: Fixed > Removing obsolete SSL handling in `AcceptorImpl.accept` catch block > --- > > Key: GEODE-3051 > URL: https://issues.apache.org/jira/browse/GEODE-3051 > Project: Geode > Issue Type: Improvement > Components: client/server >Affects Versions: 1.1.1 >Reporter: Udo Kohlmeyer >Assignee: Galen O'Sullivan >Priority: Major > > SSL handshake is now done in a separate thread and will never reach the > handler code which is being removed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-2375) GemFireException should not inherit from RuntimeException
[
https://issues.apache.org/jira/browse/GEODE-2375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16444847#comment-16444847
]
John Blum commented on GEODE-2375:
--
As a side note, I would argue that most (if not all) _Exceptions_ coming out of
Apache Geode should be _RuntimeExceptions_ anyway.
How should/would a user handle/recover from an Authentication failure (e.g. on
reconnect), or a No Subscriptions Servers Available Error/Exception, etc, in
code, at runtime?
Most of these type of problems require a configuration change and therefore
should lead to a RuntimeException and _fail-fast_ behavior.
If the internal Geode mechanisms (e.g. type system) detecting Exceptions in
order to induce a orderly shutdown along with properly cleaning up resources,
then I would suggest it be based on an Exception hierarchy defined by Geode
(rooted by a base Exception class, no less), and not whether the Exception is
checked or not.
As a general rule of thumb, users should not be forced to "catch" Exceptions
for which they cannot handle or recover from in their application code. That
is typically a design flaw.
> GemFireException should not inherit from RuntimeException
> -
>
> Key: GEODE-2375
> URL: https://issues.apache.org/jira/browse/GEODE-2375
> Project: Geode
> Issue Type: Improvement
> Components: core, general
>Reporter: Galen O'Sullivan
>Priority: Major
>
> {{GemFireException}} inherits from {{RuntimeException}}, which means that the
> majority of exceptions in Geode are unchecked. This means that we don't have
> the type system helping us to check potential failure conditions of our code,
> and it's not clear which functions may throw exceptions as a part of their
> nomal failure modes -- for example, {{ReplyException}} has a
> {{handleAsUnexpected}} method that seems to indicate that a normal
> {{ReplyException}} is not unexpected -- but that's not what the type
> inheritance says. {{GemFireException}} accounts for most of the exceptions in
> the codebase.
> Even if we were to convert most of the existing instances of
> {{GemFireException}} to {{GemFireRuntimeException}}, developers (especially
> new ones) would still be tempted to use {{GemFireException}} for new
> exceptions.
> Perhaps the best way to solve this (if we want all our exceptions to inherit
> from a central exception type, which I'm not entirely sold on) would be to
> create a new {{GeodeUncheckedException}} and {{GeodeCheckedException}}, and
> deprecate both kinds of {{GemFireException}}? Then we could convert old
> exceptions as time permits.
> There's a significant amount of work involved here whatever way we decide to
> change it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-2542) LocatorDUnitTest and LocatorUDPSecurityDUnitTest fail frequently in Geode Nightly Build
[
https://issues.apache.org/jira/browse/GEODE-2542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16444848#comment-16444848
]
Michael Dodge commented on GEODE-2542:
--
The last stack trace in the comments no longer appears to be possible:
{{
protected byte[] getClusterSecretKey() {
if (this.clusterEncryptor != null) {
return this.clusterEncryptor.getSecretBytes();
} else {
return null;
}
}
}}
> LocatorDUnitTest and LocatorUDPSecurityDUnitTest fail frequently in Geode
> Nightly Build
> ---
>
> Key: GEODE-2542
> URL: https://issues.apache.org/jira/browse/GEODE-2542
> Project: Geode
> Issue Type: Bug
> Components: locator
>Reporter: Kirk Lund
>Assignee: Brian Baynes
>Priority: Major
> Labels: Flaky
>
> testMultipleLocators:
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.NamedRunnable.run in VM 0 running on Host
> asf919.gq1.ygridcore.net with 5 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:377)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:347)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:280)
> at
> org.apache.geode.distributed.LocatorDUnitTest.testMultipleLocators(LocatorDUnitTest.java:1567)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
> at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
> at
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMeth
[jira] [Closed] (GEODE-3028) Fix the expected value of the test that depended on Locale
[ https://issues.apache.org/jira/browse/GEODE-3028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker closed GEODE-3028. > Fix the expected value of the test that depended on Locale > -- > > Key: GEODE-3028 > URL: https://issues.apache.org/jira/browse/GEODE-3028 > Project: Geode > Issue Type: Test > Components: tests >Reporter: Masaki Yamakawa >Priority: Minor > > I am testing in Japanese environment. Running the test in the Japanese > environment will cause the Assertion to fail due to the difference in Locale, > so I want to change this so that it does not depend on the runtime > environment. > The target classes are as follows: > - > org.apache.geode.distributed.internal.membership.gms.auth.GMSAuthenticatorWithAuthenticatorTest > - > org.apache.geode.distributed.internal.membership.gms.auth.GMSAuthenticatorWithSecurityManagerTest > - org.apache.geode.internal.cache.tier.sockets.ServerConnectionTest > - org.apache.geode.internal.cache.ColocationHelperTest -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-3028) Fix the expected value of the test that depended on Locale
[ https://issues.apache.org/jira/browse/GEODE-3028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker resolved GEODE-3028. -- Resolution: Fixed > Fix the expected value of the test that depended on Locale > -- > > Key: GEODE-3028 > URL: https://issues.apache.org/jira/browse/GEODE-3028 > Project: Geode > Issue Type: Test > Components: tests >Reporter: Masaki Yamakawa >Priority: Minor > > I am testing in Japanese environment. Running the test in the Japanese > environment will cause the Assertion to fail due to the difference in Locale, > so I want to change this so that it does not depend on the runtime > environment. > The target classes are as follows: > - > org.apache.geode.distributed.internal.membership.gms.auth.GMSAuthenticatorWithAuthenticatorTest > - > org.apache.geode.distributed.internal.membership.gms.auth.GMSAuthenticatorWithSecurityManagerTest > - org.apache.geode.internal.cache.tier.sockets.ServerConnectionTest > - org.apache.geode.internal.cache.ColocationHelperTest -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-3022) [JGRP00001] configuration error: the following properties in org.apache.geode.distributed.internal.membership.gms.messenger.Transport are not recognized: {ignore_dont_b
[
https://issues.apache.org/jira/browse/GEODE-3022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16444844#comment-16444844
]
Anthony Baker commented on GEODE-3022:
--
Closing due to inactivity. Please reopen if needed.
> [JGRP1] configuration error: the following properties in
> org.apache.geode.distributed.internal.membership.gms.messenger.Transport are
> not recognized: {ignore_dont_bundle=false}
>
>
> Key: GEODE-3022
> URL: https://issues.apache.org/jira/browse/GEODE-3022
> Project: Geode
> Issue Type: Bug
>Reporter: Sumitra Chatterjee
>Priority: Blocker
>
> Getting above exception when trying to start cache server. Further checked in
> JGroupsMessenger.java and found below:
> void setMessageFlags(DistributionMessage gfmsg, Message msg) {
> // Bundling is mostly only useful if we're doing no-ack work,
> // which is fairly rare
> msg.setFlag(Flag.DONT_BUNDLE);
> As per https://issues.jboss.org/browse/JGRP-1737, DONT_BUNDLE is probably not
> to be used (correct me if I am misunderstanding). Any ideas how to get the
> server start up would be very helpful.
> Thanks
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GEODE-3022) [JGRP00001] configuration error: the following properties in org.apache.geode.distributed.internal.membership.gms.messenger.Transport are not recognized: {ignore_dont_bund
[
https://issues.apache.org/jira/browse/GEODE-3022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker closed GEODE-3022.
> [JGRP1] configuration error: the following properties in
> org.apache.geode.distributed.internal.membership.gms.messenger.Transport are
> not recognized: {ignore_dont_bundle=false}
>
>
> Key: GEODE-3022
> URL: https://issues.apache.org/jira/browse/GEODE-3022
> Project: Geode
> Issue Type: Bug
>Reporter: Sumitra Chatterjee
>Priority: Blocker
>
> Getting above exception when trying to start cache server. Further checked in
> JGroupsMessenger.java and found below:
> void setMessageFlags(DistributionMessage gfmsg, Message msg) {
> // Bundling is mostly only useful if we're doing no-ack work,
> // which is fairly rare
> msg.setFlag(Flag.DONT_BUNDLE);
> As per https://issues.jboss.org/browse/JGRP-1737, DONT_BUNDLE is probably not
> to be used (correct me if I am misunderstanding). Any ideas how to get the
> server start up would be very helpful.
> Thanks
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-3022) [JGRP00001] configuration error: the following properties in org.apache.geode.distributed.internal.membership.gms.messenger.Transport are not recognized: {ignore_dont_bu
[
https://issues.apache.org/jira/browse/GEODE-3022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker resolved GEODE-3022.
--
Resolution: Cannot Reproduce
> [JGRP1] configuration error: the following properties in
> org.apache.geode.distributed.internal.membership.gms.messenger.Transport are
> not recognized: {ignore_dont_bundle=false}
>
>
> Key: GEODE-3022
> URL: https://issues.apache.org/jira/browse/GEODE-3022
> Project: Geode
> Issue Type: Bug
>Reporter: Sumitra Chatterjee
>Priority: Blocker
>
> Getting above exception when trying to start cache server. Further checked in
> JGroupsMessenger.java and found below:
> void setMessageFlags(DistributionMessage gfmsg, Message msg) {
> // Bundling is mostly only useful if we're doing no-ack work,
> // which is fairly rare
> msg.setFlag(Flag.DONT_BUNDLE);
> As per https://issues.jboss.org/browse/JGRP-1737, DONT_BUNDLE is probably not
> to be used (correct me if I am misunderstanding). Any ideas how to get the
> server start up would be very helpful.
> Thanks
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (GEODE-5113) EvictionAttributes.getMaximum() no longer throws UnsupportedOperationException for LRU Heap
[
https://issues.apache.org/jira/browse/GEODE-5113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16444816#comment-16444816
]
John Blum edited comment on GEODE-5113 at 4/19/18 9:41 PM:
---
Hi [~dschneider] -
It is unlikely that this change will affect most applications (IMO), unless
users/developers are explicitly handling the previously thrown
{{UnsupportedOperationException}} from the {{EvictionAttributes.getMaximum()}}
method when called and LRU Heap Eviction is configured, which is technically
possible, no matter how unlikely. If so, clearly this will no will longer be
"handled" in the way that the user expects.
I actually agree with this change, partially.
When I informed the GemFire PM team of this issue/change in API (behavior),
which broke some tests in SDG's test suite, where SDG was configuring LRU Heap
Eviction and expecting this behavior when calling
{{EvictionAttributes.getMaximum()}}, it was to point out that this API change
was not "properly documented", in Javadoc on the
[{{EvictionAttributes.getMaximum()}}|http://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/EvictionAttributes.html]
method.
Unfortunately, the {{UnsupportedOperationException}} was never properly
documented in Javadoc either, i.e. by declaring the Exception in a {{@throws}}
tag on the method. As a result, I had to dig into Geode's source to figure out
what hand changed when the Exception was no longer thrown, which is when I
realized the method [now returned
0|https://github.com/apache/geode/blob/rel/v1.5.0/geode-core/src/main/java/org/apache/geode/internal/cache/EvictionAttributesImpl.java#L95-L101]
vs. [throwing the
{{UnsupportedOperationException}}|https://github.com/apache/geode/blob/rel/v1.4.0/geode-core/src/main/java/org/apache/geode/internal/cache/EvictionAttributesImpl.java#L138-L144]
as before, #sigh).
Now, why do I partially agree with this change?
Well, I am wondering, would it make more sense to return
[{{Cache.getResourceManager().getEvictionHeapPercentage()}}|http://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/control/ResourceManager.html#getEvictionHeapPercentage--]
from {{EvictionAttributes.getMaximum()}} instead since that is the technically
the setting affecting LRU Heap Eviction?
I mean, currently we "overload" the use of {{EvictionAttributes.getMaximum()}}
to return the "memory size" in megabytes (MB) when the LRU_MEMORY Eviction
Policy is configured, which leaves LRU_HEAP to be the 1 off, difference. Both
LRU_COUNT (which makes the most sense) and LRU_MEMORY (which make less sense,
is somewhat confusing) use {{EvictionAttributes.getMaximum()}} to assess the
Eviction Policy threshold, but LRU_HEAP is "special", requiring a user to
inspect {{ResourceManager.getEivctionHeapThreshold()}}, AFAIK.
Food for thought,
-John
was (Author: jblum):
Hi [~dschneider] -
It is unlikely that this change will affect most applications (IMO), unless
users/developers are explicitly handling the previously thrown
{{UnsupportedOperationException}} from the {{EvictionAttributes.getMaximum()}}
method when called and LRU Heap Eviction is configured, which is technically
possible, no matter how unlikely. If so, clearly this will no will longer be
"handled" in the way that the user expects.
I actually agree with this change, partially.
When I informed the GemFire PM team of this issue/change in API (behavior),
which broke some tests in SDG's test suite, where SDG was configuring LRU Heap
Eviction and expecting this behavior when calling
{{EvictionAttributes.getMaximum()}}, it was to point out that this API change
was not "properly documented", in Javadoc on the
[{{EvictionAttributes.getMaximum()}}|http://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/EvictionAttributes.html]
method.
Unfortunately, the {{UnsupportedOperationException}} was never properly
documented in Javadoc either, i.e. by declaring the Exception in a {{@throws}}
tag on the method. As a result, I had to dig into Geode's source to figure out
what hand changed when the Exception was no longer thrown, which is when I
realized the method [now returned
0|https://github.com/apache/geode/blob/rel/v1.5.0/geode-core/src/main/java/org/apache/geode/internal/cache/EvictionAttributesImpl.java#L95-L101]
vs. [throwing the
{{UnsupportedOperationException}}|https://github.com/apache/geode/blob/rel/v1.4.0/geode-core/src/main/java/org/apache/geode/internal/cache/EvictionAttributesImpl.java#L138-L144]
as before, #sigh).
Now, why do I partially agree with this change?
Well, I am wondering, would it make more sense to return
[{{Cache.getResourceManager().getEvictionHeapPercentage()}}|http://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/control/ResourceManager.html#getEvictionHeapPercentage--]
instead since that is the setting affecting LR
[jira] [Updated] (GEODE-2984) Gfsh command error handling should use exceptions rather than status returns
[ https://issues.apache.org/jira/browse/GEODE-2984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-2984: - Issue Type: Task (was: Bug) > Gfsh command error handling should use exceptions rather than status returns > > > Key: GEODE-2984 > URL: https://issues.apache.org/jira/browse/GEODE-2984 > Project: Geode > Issue Type: Task > Components: gfsh >Reporter: Jared Stewart >Assignee: Kenneth Howe >Priority: Major > > Currently, a given gfsh command either returns an InfoResultData (in the > happy case) or an ErrorResultData (in the exceptional case). This requires > putting error handling code inside of *each* command separately. It would > be far better to instead allow gfsh commands throw an exception, and to have > GfshExecutionStrategy (or somewhere similar) handle wrapping up any exception > into an ErrorResultData in a generic fashion. > It may also be worth looking at the built-in mechanism in Spring Shell for > this strategy (see afterThrowingInvocation): > http://docs.spring.io/autorepo/docs/spring-shell/1.2.0.M1/api/org/springframework/shell/core/ExecutionProcessor.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (GEODE-5113) EvictionAttributes.getMaximum() no longer throws UnsupportedOperationException for LRU Heap
[
https://issues.apache.org/jira/browse/GEODE-5113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16444816#comment-16444816
]
John Blum edited comment on GEODE-5113 at 4/19/18 9:37 PM:
---
Hi [~dschneider] -
It is unlikely that this change will affect most applications (IMO), unless
users/developers are explicitly handling the previously thrown
{{UnsupportedOperationException}} from the {{EvictionAttributes.getMaximum()}}
method when called and LRU Heap Eviction is configured, which is technically
possible, no matter how unlikely. If so, clearly this will no will longer be
"handled" in the way that the user expects.
I actually agree with this change, partially.
When I informed the GemFire PM team of this issue/change in API (behavior),
which broke some tests in SDG's test suite, where SDG was configuring LRU Heap
Eviction and expecting this behavior when calling
{{EvictionAttributes.getMaximum()}}, it was to point out that this API change
was not "properly documented", in Javadoc on the
[{{EvictionAttributes.getMaximum()}}|http://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/EvictionAttributes.html]
method.
Unfortunately, the {{UnsupportedOperationException}} was never properly
documented in Javadoc either, i.e. by declaring the Exception in a {{@throws}}
tag on the method. As a result, I had to dig into Geode's source to figure out
what hand changed when the Exception was no longer thrown, which is when I
realized the method [now returned
0|https://github.com/apache/geode/blob/rel/v1.5.0/geode-core/src/main/java/org/apache/geode/internal/cache/EvictionAttributesImpl.java#L95-L101]
vs. [throwing the
{{UnsupportedOperationException}}|https://github.com/apache/geode/blob/rel/v1.4.0/geode-core/src/main/java/org/apache/geode/internal/cache/EvictionAttributesImpl.java#L138-L144]
as before, #sigh).
Now, why do I partially agree with this change?
Well, I am wondering, would it make more sense to return
[{{Cache.getResourceManager().getEvictionHeapPercentage()}}|http://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/control/ResourceManager.html#getEvictionHeapPercentage--]
instead since that is the setting affecting LRU Heap Eviction?
Food for thought,
-John
was (Author: jblum):
Hi [~dschneider] -
It is unlikely that this change will affect most applications (IMO), unless
users/developers are explicitly handling the previously thrown
{{UnsupportedOperationException}} from the {{EvictionAttributes.getMaximum()}}
method when called and LRU Heap Eviction is configured, which is technically
possible, no matter how unlikely. If so, clearly this will no will longer be
"handled" in the way that the user expects.
I actually agree with this change, partially.
When I informed the GemFire PM team of this issue/change in API (behavior),
which broke some tests in SDG's test suite, where SDG was configuring LRU Heap
Eviction and expecting this behavior when calling
{{EvictionAttributes.getMaximum()}}, it was to point out that this API change
was not "properly documented", in Javadoc on the
[{{EvictionAttributes.getMaximum()}}|http://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/EvictionAttributes.html]
method.
Unfortunately, the {{UnsupportedOperationException}} was never properly
documented in Javadoc either, i.e. by declaring the Exception in a {{@throws}}
tag on the method. As a result, I had to dig into Geode's source to figure out
what hand changed when the Exception was no longer thrown, which is when I
realized the method [now returned
0|https://github.com/apache/geode/blob/rel/v1.5.0/geode-core/src/main/java/org/apache/geode/internal/cache/EvictionAttributesImpl.java#L95-L101]
vs. [throwing the
{{UnsupportedOperationException}}|https://github.com/apache/geode/blob/rel/v1.4.0/geode-core/src/main/java/org/apache/geode/internal/cache/EvictionAttributesImpl.java#L138-L144]
as before, ).
Now, why do I partially agree with this change?
Well, I am wondering, would it make more sense to return
[{{Cache.getResourceManager().getEvictionHeapPercentage()}}|http://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/control/ResourceManager.html#getEvictionHeapPercentage--]
instead since that is the setting affecting LRU Heap Eviction?
Food for thought,
-John
> EvictionAttributes.getMaximum() no longer throws
> UnsupportedOperationException for LRU Heap
> ---
>
> Key: GEODE-5113
> URL: https://issues.apache.org/jira/browse/GEODE-5113
> Project: Geode
> Issue Type: Bug
> Components: eviction
>Reporter: Fred Krone
>Priority: Major
>
>
> Previously, the EvictionAttributes.getMaximum() used to throw an
> UnsupportedOperationExc
[jira] [Commented] (GEODE-2981) Fix the line feed code of the test expected value
[ https://issues.apache.org/jira/browse/GEODE-2981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16444838#comment-16444838 ] Anthony Baker commented on GEODE-2981: -- [~khowe] can this issue be closed? > Fix the line feed code of the test expected value > - > > Key: GEODE-2981 > URL: https://issues.apache.org/jira/browse/GEODE-2981 > Project: Geode > Issue Type: Test > Components: management, tests >Reporter: Masaki Yamakawa >Assignee: Jinmei Liao >Priority: Minor > > I mainly use the Windows. When I run the test on Windows, because Assertion > fails due to the difference in line feed code, I want to change this so that > it does not depend on the runtime environment. > The target classes are as follows: > - org.apache.geode.management.internal.cli.shell.GfshJunitTest > - org.apache.geode.management.internal.cli.help.HelpBlockUnitTest > - org.apache.geode.management.internal.cli.help.HelperUnitTest -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (GEODE-5113) EvictionAttributes.getMaximum() no longer throws UnsupportedOperationException for LRU Heap
[
https://issues.apache.org/jira/browse/GEODE-5113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16444816#comment-16444816
]
John Blum edited comment on GEODE-5113 at 4/19/18 9:36 PM:
---
Hi [~dschneider] -
It is unlikely that this change will affect most applications (IMO), unless
users/developers are explicitly handling the previously thrown
{{UnsupportedOperationException}} from the {{EvictionAttributes.getMaximum()}}
method when called and LRU Heap Eviction is configured, which is technically
possible, no matter how unlikely. If so, clearly this will no will longer be
"handled" in the way that the user expects.
I actually agree with this change, partially.
When I informed the GemFire PM team of this issue/change in API (behavior),
which broke some tests in SDG's test suite, where SDG was configuring LRU Heap
Eviction and expecting this behavior when calling
{{EvictionAttributes.getMaximum()}}, it was to point out that this API change
was not "properly documented", in Javadoc on the
[{{EvictionAttributes.getMaximum()}}|http://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/EvictionAttributes.html]
method.
Unfortunately, the {{UnsupportedOperationException}} was never properly
documented in Javadoc either, i.e. by declaring the Exception in a {{@throws}}
tag on the method. As a result, I had to dig into Geode's source to figure out
what hand changed when the Exception was no longer thrown, which is when I
realized the method [now returned
0|https://github.com/apache/geode/blob/rel/v1.5.0/geode-core/src/main/java/org/apache/geode/internal/cache/EvictionAttributesImpl.java#L95-L101]
vs. [throwing the
{{UnsupportedOperationException}}|https://github.com/apache/geode/blob/rel/v1.4.0/geode-core/src/main/java/org/apache/geode/internal/cache/EvictionAttributesImpl.java#L138-L144]
as before , ).
Now, why do I partially agree with this change?
Well, I am wondering, would it make more sense to return
[{{Cache.getResourceManager().getEvictionHeapPercentage()}}|http://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/control/ResourceManager.html#getEvictionHeapPercentage--]
instead since that is the setting affecting LRU Heap Eviction?
Food for thought,
-John
was (Author: jblum):
Hi [~dschneider] -
It is unlikely that this change will affect most applications (IMO), unless
users/developers are explicitly handling the previously thrown
{{UnsupportedOperationException}} from the {{EvictionAttributes.getMaximum()}}
method when called and LRU Heap Eviction is configured, which is technically
possible, no matter how unlikely. If so, clearly this will no will longer be
"handled" in the way that the user expects.
I actually agree with this change, partially.
When I informed the GemFire PM team of this issue/change in API (behavior),
which broke some tests in SDG's test suite, where SDG was configuring LRU Heap
Eviction and expecting this behavior when calling
{{EvictionAttributes.getMaximum()}}, it was to point out that this API change
was not "properly documented", in Javadoc on the
[{{EvictionAttributes.getMaximum()}}|http://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/EvictionAttributes.html]
method.
Unfortunately, the {{UnsupportedOperationException}} was never properly
documented in Javadoc either, i.e. by declaring the Exception in a {{@throws}}
tag on the method. As a result, I had to dig into Geode's source to figure out
what hand changed when the Exception was no longer thrown, which is when I
realized the method [now returned
0|https://github.com/apache/geode/blob/rel/v1.5.0/geode-core/src/main/java/org/apache/geode/internal/cache/EvictionAttributesImpl.java#L95-L101]
vs.
[throwing|https://github.com/apache/geode/blob/rel/v1.4.0/geode-core/src/main/java/org/apache/geode/internal/cache/EvictionAttributesImpl.java#L138-L144]
the {{UnsupportedOperationException}} previously, ).
Now, why do I partially agree with this change?
Well, I am wondering, would it make more sense to return
[{{Cache.getResourceManager().getEvictionHeapPercentage()}}|http://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/control/ResourceManager.html#getEvictionHeapPercentage--]
instead since that is the setting affecting LRU Heap Eviction?
Food for thought,
-John
> EvictionAttributes.getMaximum() no longer throws
> UnsupportedOperationException for LRU Heap
> ---
>
> Key: GEODE-5113
> URL: https://issues.apache.org/jira/browse/GEODE-5113
> Project: Geode
> Issue Type: Bug
> Components: eviction
>Reporter: Fred Krone
>Priority: Major
>
>
> Previously, the EvictionAttributes.getMaximum() used to throw an
> UnsupportedOperationExcept
[jira] [Comment Edited] (GEODE-5113) EvictionAttributes.getMaximum() no longer throws UnsupportedOperationException for LRU Heap
[
https://issues.apache.org/jira/browse/GEODE-5113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16444816#comment-16444816
]
John Blum edited comment on GEODE-5113 at 4/19/18 9:36 PM:
---
Hi [~dschneider] -
It is unlikely that this change will affect most applications (IMO), unless
users/developers are explicitly handling the previously thrown
{{UnsupportedOperationException}} from the {{EvictionAttributes.getMaximum()}}
method when called and LRU Heap Eviction is configured, which is technically
possible, no matter how unlikely. If so, clearly this will no will longer be
"handled" in the way that the user expects.
I actually agree with this change, partially.
When I informed the GemFire PM team of this issue/change in API (behavior),
which broke some tests in SDG's test suite, where SDG was configuring LRU Heap
Eviction and expecting this behavior when calling
{{EvictionAttributes.getMaximum()}}, it was to point out that this API change
was not "properly documented", in Javadoc on the
[{{EvictionAttributes.getMaximum()}}|http://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/EvictionAttributes.html]
method.
Unfortunately, the {{UnsupportedOperationException}} was never properly
documented in Javadoc either, i.e. by declaring the Exception in a {{@throws}}
tag on the method. As a result, I had to dig into Geode's source to figure out
what hand changed when the Exception was no longer thrown, which is when I
realized the method [now returned
0|https://github.com/apache/geode/blob/rel/v1.5.0/geode-core/src/main/java/org/apache/geode/internal/cache/EvictionAttributesImpl.java#L95-L101]
vs. [throwing the
{{UnsupportedOperationException}}|https://github.com/apache/geode/blob/rel/v1.4.0/geode-core/src/main/java/org/apache/geode/internal/cache/EvictionAttributesImpl.java#L138-L144]
as before, ).
Now, why do I partially agree with this change?
Well, I am wondering, would it make more sense to return
[{{Cache.getResourceManager().getEvictionHeapPercentage()}}|http://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/control/ResourceManager.html#getEvictionHeapPercentage--]
instead since that is the setting affecting LRU Heap Eviction?
Food for thought,
-John
was (Author: jblum):
Hi [~dschneider] -
It is unlikely that this change will affect most applications (IMO), unless
users/developers are explicitly handling the previously thrown
{{UnsupportedOperationException}} from the {{EvictionAttributes.getMaximum()}}
method when called and LRU Heap Eviction is configured, which is technically
possible, no matter how unlikely. If so, clearly this will no will longer be
"handled" in the way that the user expects.
I actually agree with this change, partially.
When I informed the GemFire PM team of this issue/change in API (behavior),
which broke some tests in SDG's test suite, where SDG was configuring LRU Heap
Eviction and expecting this behavior when calling
{{EvictionAttributes.getMaximum()}}, it was to point out that this API change
was not "properly documented", in Javadoc on the
[{{EvictionAttributes.getMaximum()}}|http://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/EvictionAttributes.html]
method.
Unfortunately, the {{UnsupportedOperationException}} was never properly
documented in Javadoc either, i.e. by declaring the Exception in a {{@throws}}
tag on the method. As a result, I had to dig into Geode's source to figure out
what hand changed when the Exception was no longer thrown, which is when I
realized the method [now returned
0|https://github.com/apache/geode/blob/rel/v1.5.0/geode-core/src/main/java/org/apache/geode/internal/cache/EvictionAttributesImpl.java#L95-L101]
vs. [throwing the
{{UnsupportedOperationException}}|https://github.com/apache/geode/blob/rel/v1.4.0/geode-core/src/main/java/org/apache/geode/internal/cache/EvictionAttributesImpl.java#L138-L144]
as before , ).
Now, why do I partially agree with this change?
Well, I am wondering, would it make more sense to return
[{{Cache.getResourceManager().getEvictionHeapPercentage()}}|http://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/control/ResourceManager.html#getEvictionHeapPercentage--]
instead since that is the setting affecting LRU Heap Eviction?
Food for thought,
-John
> EvictionAttributes.getMaximum() no longer throws
> UnsupportedOperationException for LRU Heap
> ---
>
> Key: GEODE-5113
> URL: https://issues.apache.org/jira/browse/GEODE-5113
> Project: Geode
> Issue Type: Bug
> Components: eviction
>Reporter: Fred Krone
>Priority: Major
>
>
> Previously, the EvictionAttributes.getMaximum() used to throw an
> UnsupportedOperationExcepti
[jira] [Commented] (GEODE-2960) gfsh create index should trim from field names
[ https://issues.apache.org/jira/browse/GEODE-2960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16444835#comment-16444835 ] Anthony Baker commented on GEODE-2960: -- [~huynhja] can this issue be closed? > gfsh create index should trim from field names > -- > > Key: GEODE-2960 > URL: https://issues.apache.org/jira/browse/GEODE-2960 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: Jason Huynh >Assignee: Deepak Dixit >Priority: Major > > When creating an index with specific fields, the parameter expects a comma > separated string. However we are not trimming after splitting the string. > So if fields are defined as --field="name, age, height, weight" the indexed > fields are actually "name", " age", " height", " weight" > The command should probably trim the spaces before creating the index. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-2930) Remove unused serialVersionUIDs from non-Serializable clases
[ https://issues.apache.org/jira/browse/GEODE-2930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-2930: - Labels: starter (was: ) > Remove unused serialVersionUIDs from non-Serializable clases > > > Key: GEODE-2930 > URL: https://issues.apache.org/jira/browse/GEODE-2930 > Project: Geode > Issue Type: Task > Components: core >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: starter > > Non-Serializable classes should not have serialVersionUID defined. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-2930) Remove unused serialVersionUIDs from non-Serializable clases
[ https://issues.apache.org/jira/browse/GEODE-2930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-2930: - Issue Type: Task (was: Bug) > Remove unused serialVersionUIDs from non-Serializable clases > > > Key: GEODE-2930 > URL: https://issues.apache.org/jira/browse/GEODE-2930 > Project: Geode > Issue Type: Task > Components: core >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > > Non-Serializable classes should not have serialVersionUID defined. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-2789) Rewrite AutoBalancerJUnitTest to allow refactoring of GemFireCacheImpl
[
https://issues.apache.org/jira/browse/GEODE-2789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16444831#comment-16444831
]
Anthony Baker commented on GEODE-2789:
--
[~klund] can this issue be closed?
> Rewrite AutoBalancerJUnitTest to allow refactoring of GemFireCacheImpl
> --
>
> Key: GEODE-2789
> URL: https://issues.apache.org/jira/browse/GEODE-2789
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Kirk Lund
>Priority: Major
>
> This test is so brittle that any changes to GemFireCacheImpl results in a
> bunch of JMock failures:
> {noformat}
> java.lang.IllegalArgumentException
> at net.sf.cglib.asm.ClassReader.(Unknown Source)
> at net.sf.cglib.asm.ClassReader.(Unknown Source)
> at net.sf.cglib.asm.ClassReader.(Unknown Source)
> at
> net.sf.cglib.proxy.BridgeMethodResolver.resolveAll(BridgeMethodResolver.java:61)
> at net.sf.cglib.proxy.Enhancer.emitMethods(Enhancer.java:911)
> at net.sf.cglib.proxy.Enhancer.generateClass(Enhancer.java:498)
> at
> net.sf.cglib.core.DefaultGeneratorStrategy.generate(DefaultGeneratorStrategy.java:25)
> at
> net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:216)
> at net.sf.cglib.proxy.Enhancer.createHelper(Enhancer.java:377)
> at net.sf.cglib.proxy.Enhancer.createClass(Enhancer.java:317)
> at
> org.jmock.lib.legacy.ClassImposteriser.proxyClass(ClassImposteriser.java:121)
> at
> org.jmock.lib.legacy.ClassImposteriser.imposterise(ClassImposteriser.java:66)
> at org.jmock.Mockery.mock(Mockery.java:148)
> at org.jmock.Mockery.mock(Mockery.java:124)
> at
> org.apache.geode.cache.util.AutoBalancerJUnitTest.testFacadeCollectMemberDetails2Regions(AutoBalancerJUnitTest.java:427)
> 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:497)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:51)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:237)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> {noformat}
> {noformat}
> java.lang.IllegalArgumentException
> at net.sf.cglib.asm.ClassReader.(Unknown Source)
> at net.sf.cglib.asm.ClassReader.(Unknown Source)
> at net.sf.cglib.asm.ClassReader.(Unknown Source)
> at
> net.sf.cglib.proxy.BridgeMethodResolver.resolveAll(BridgeMethodResolver.java:61)
> at net.sf.cglib.proxy.Enhancer.emitMethods(Enhancer.java:911)
> at net.sf.cglib.proxy.Enhancer.generateClass(Enhancer.java:498)
> at
> net.sf.cglib.core.DefaultGeneratorStrategy.generate(DefaultGeneratorStrategy.java:25)
> at
> net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:216)
> at net.sf.cglib.proxy.Enhancer.createHelper(Enhancer.java:377)
> at net.sf.cglib.proxy.Enhancer.createClass(Enhancer.java:317)
> at
> org.jmock.lib.legacy.ClassImposteriser.proxyClass(ClassImposteriser.java:121)
> at
[jira] [Resolved] (GEODE-2744) Dependency version conflict between spring shell and commons IO
[ https://issues.apache.org/jira/browse/GEODE-2744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker resolved GEODE-2744. -- Resolution: Fixed > Dependency version conflict between spring shell and commons IO > --- > > Key: GEODE-2744 > URL: https://issues.apache.org/jira/browse/GEODE-2744 > Project: Geode > Issue Type: Bug > Components: build >Affects Versions: 1.1.0 >Reporter: Anthony Baker >Priority: Minor > > Spring Shell v1.2.0.RELEASE depends on commons-io-2.4. > In Geode v1.1.x, we specify commons-io-2.3. > In Geode v1.2.0-SNAPSHOT, we specify commons-2.5. > We should make this consistent or add an exclusion rule. > http://mail-archives.apache.org/mod_mbox/geode-dev/201703.mbox/%3cCAF3UAT0K=5_xocgx_yquj+frdfk2hbkqv4wu04ao2pdvfof...@mail.gmail.com%3e -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-2744) Dependency version conflict between spring shell and commons IO
[ https://issues.apache.org/jira/browse/GEODE-2744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker closed GEODE-2744. > Dependency version conflict between spring shell and commons IO > --- > > Key: GEODE-2744 > URL: https://issues.apache.org/jira/browse/GEODE-2744 > Project: Geode > Issue Type: Bug > Components: build >Affects Versions: 1.1.0 >Reporter: Anthony Baker >Priority: Minor > > Spring Shell v1.2.0.RELEASE depends on commons-io-2.4. > In Geode v1.1.x, we specify commons-io-2.3. > In Geode v1.2.0-SNAPSHOT, we specify commons-2.5. > We should make this consistent or add an exclusion rule. > http://mail-archives.apache.org/mod_mbox/geode-dev/201703.mbox/%3cCAF3UAT0K=5_xocgx_yquj+frdfk2hbkqv4wu04ao2pdvfof...@mail.gmail.com%3e -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-2715) Move Pulse to its own repo
[ https://issues.apache.org/jira/browse/GEODE-2715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker closed GEODE-2715. > Move Pulse to its own repo > -- > > Key: GEODE-2715 > URL: https://issues.apache.org/jira/browse/GEODE-2715 > Project: Geode > Issue Type: Improvement > Components: pulse >Reporter: Swapnil Bawaskar >Priority: Major > > Pulse should be moved to a separate repository so that it can be > independently released. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-2715) Move Pulse to its own repo
[ https://issues.apache.org/jira/browse/GEODE-2715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker resolved GEODE-2715. -- Resolution: Won't Fix > Move Pulse to its own repo > -- > > Key: GEODE-2715 > URL: https://issues.apache.org/jira/browse/GEODE-2715 > Project: Geode > Issue Type: Improvement > Components: pulse >Reporter: Swapnil Bawaskar >Priority: Major > > Pulse should be moved to a separate repository so that it can be > independently released. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-2660) Mark Redis Adapter as Experimental
[ https://issues.apache.org/jira/browse/GEODE-2660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16444823#comment-16444823 ] Anthony Baker commented on GEODE-2660: -- [~gosullivan] this seems to have been merged, can it be closed? > Mark Redis Adapter as Experimental > -- > > Key: GEODE-2660 > URL: https://issues.apache.org/jira/browse/GEODE-2660 > Project: Geode > Issue Type: Bug >Reporter: Galen O'Sullivan >Priority: Major > > I put this up for a vote recently. The Redis adapter is really not ready for > prime time at this point. We should mark it experimental so people don't > mistakenly think it's ready, and so that we can change it more readily on > develop. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-2652) IntegratedSecurityService class has state that is not thread safe
[ https://issues.apache.org/jira/browse/GEODE-2652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16444821#comment-16444821 ] Anthony Baker commented on GEODE-2652: -- [~khowe] is this still an issue? > IntegratedSecurityService class has state that is not thread safe > - > > Key: GEODE-2652 > URL: https://issues.apache.org/jira/browse/GEODE-2652 > Project: Geode > Issue Type: Bug > Components: security >Reporter: Kirk Lund >Priority: Major > > The state of IntegratedSecurityService is currently not thread safe. One > thread may set these values by invoking initSecurity, while others threads > invoke methods which access these values: > * private PostProcessor postProcessor; > * private SecurityManager securityManager; > * private Boolean isIntegratedSecurity; > * private boolean isClientAuthenticator; // is there a > SECURITY_CLIENT_AUTHENTICATOR > * private boolean isPeerAuthenticator; // is there a > SECURITY_PEER_AUTHENTICATOR > This could manifest as thread visibility bugs (other thread does not see the > value set by another thread). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5113) EvictionAttributes.getMaximum() no longer throws UnsupportedOperationException for LRU Heap
[
https://issues.apache.org/jira/browse/GEODE-5113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16444816#comment-16444816
]
John Blum commented on GEODE-5113:
--
Hi [~dschneider] -
It is unlikely that this change will affect most applications (IMO), unless
users/developers are explicitly handling the previously thrown
{{UnsupportedOperationException}} from the {{EvictionAttributes.getMaximum()}}
method when called and LRU Heap Eviction is configured, which is technically
possible, no matter how unlikely. If so, clearly this will no will longer be
"handled" in the way that the user expects.
I actually agree with this change, partially.
When I informed the GemFire PM team of this issue/change in API (behavior),
which broke some tests in SDG's test suite, where SDG was configuring LRU Heap
Eviction and expecting this behavior when calling
{{EvictionAttributes.getMaximum()}}, it was to point out that this API change
was not "properly documented", in Javadoc on the
[{{EvictionAttributes.getMaximum()}}|http://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/EvictionAttributes.html]
method.
Unfortunately, the {{UnsupportedOperationException}} was never properly
documented in Javadoc either, i.e. by declaring the Exception in a {{@throws}}
tag on the method. As a result, I had to dig into Geode's source to figure out
what hand changed when the Exception was no longer thrown, which is when I
realized the method [now returned
0|https://github.com/apache/geode/blob/rel/v1.5.0/geode-core/src/main/java/org/apache/geode/internal/cache/EvictionAttributesImpl.java#L95-L101]
vs.
[throwing|https://github.com/apache/geode/blob/rel/v1.4.0/geode-core/src/main/java/org/apache/geode/internal/cache/EvictionAttributesImpl.java#L138-L144]
the {{UnsupportedOperationException}} previously, ).
Now, why do I partially agree with this change?
Well, I am wondering, would it make more sense to return
[{{Cache.getResourceManager().getEvictionHeapPercentage()}}|http://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/control/ResourceManager.html#getEvictionHeapPercentage--]
instead since that is the setting affecting LRU Heap Eviction?
Food for thought,
-John
> EvictionAttributes.getMaximum() no longer throws
> UnsupportedOperationException for LRU Heap
> ---
>
> Key: GEODE-5113
> URL: https://issues.apache.org/jira/browse/GEODE-5113
> Project: Geode
> Issue Type: Bug
> Components: eviction
>Reporter: Fred Krone
>Priority: Major
>
>
> Previously, the EvictionAttributes.getMaximum() used to throw an
> UnsupportedOperationException if the user tried to configure a Maximum on an
> LRU Heap Eviction Policy (Apache Geode 1.4). Now Geode (and by extension,
> GemFire) will just silently return 0.
>
> in 1.4
> [https://github.com/apache/geode/blob/rel/v1.4.0/geode-core/src/main/java/org/apache/geode/internal/cache/EvictionAttributesImpl.java#L138-L144]
>
> in 1.5
> [https://github.com/apache/geode/blob/rel/v1.5.0/geode-core/src/main/java/org/apache/geode/internal/cache/EvictionAttributesImpl.java#L95-L101]
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-2524) Refactor LuceneIntegration Tests
[ https://issues.apache.org/jira/browse/GEODE-2524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-2524: - Issue Type: Task (was: Improvement) > Refactor LuceneIntegration Tests > > > Key: GEODE-2524 > URL: https://issues.apache.org/jira/browse/GEODE-2524 > Project: Geode > Issue Type: Task > Components: lucene >Reporter: Jason Huynh >Priority: Major > > After refactoring the dunit tests, we should probably have the same structure > for the integration tests. This means changing them to use parameters and > removing as many tests inheritance as possible. > Relates to GEODE-2522 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-1597) gfsh parameters are not validated
[
https://issues.apache.org/jira/browse/GEODE-1597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker resolved GEODE-1597.
--
Resolution: Fixed
> gfsh parameters are not validated
> -
>
> Key: GEODE-1597
> URL: https://issues.apache.org/jira/browse/GEODE-1597
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Swapnil Bawaskar
>Priority: Major
>
> As a result of fixing GEODE-835, we now do not validate parameters passed
> into gfsh. For example
> {noformat}
> >gfsh start locator foo --name=loc1
> {noformat}
> will succeed even though foo is not a valid parameter. All options are
> correctly validated though, so:
> {noformat}
> >gfsh start locator --name=loc1 --foo
> {noformat}
> will result in an error.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
