[GitHub] geode issue #720: GEODE-3462: FunctionStats Exposed over JMX

[dineshakhand]

Github user dineshakhand commented on the issue:

https://github.com/apache/geode/pull/720
  
Closing the pull rquest after your comments.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] geode pull request #720: GEODE-3462: FunctionStats Exposed over JMX

[dineshakhand]

Github user dineshakhand closed the pull request at:

https://github.com/apache/geode/pull/720


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [Discuss] Use of -1 as Infinite/All for retry related functions...

[Jacob Barrett]

That is a really good point. Does the retry attempts even make sense anymore?

Does the Java client still have it? If so would it make sense to deprecate it 
there too?

-Jake


Sent from my iPhone

> On Aug 30, 2017, at 8:36 PM, Dan Smith  wrote:
> 
> In general, I think we need making the configuration of geode less complex,
> not more.
> 
> As far as retry-attempts goes, maybe the best thing to do is to get rid of
> it. The P2P layer has no such concept. I don't think users should really
> have to care about how many servers an operation is attempted against. A
> user may want to specify how long an operation is allowed to take, but that
> could be better specified with an operation timeout rather than the current
> read-timeout + retry-attempts.
> 
> -Dan
> 
> 
> 
> On Wed, Aug 30, 2017 at 2:08 PM, Patrick Rhomberg 
> wrote:
> 
>> Personally, I don't much like sentinel values, even if they have their
>> occasional use.
>> 
>> Do we need to provide an authentic infinite value?  64-bit MAXINT is nearly
>> 10 quintillion.  At 10GHz, that still takes almost three years.  If each
>> retry takes as much as 10ms, we're still looking at "retry for as long as
>> the earth has existed."  32-bit's is much more attainable, of course, but I
>> think the point stands -- if you need to retry that much, something else is
>> very wrong.
>> 
>> In the more general sense, I struggle to think of a context where an
>> authentic infinity is meaningfully distinct in application from a massive
>> finite like MAXINT.  But I could be wrong and would love to hear what other
>> people think.
>> 
>>> On Wed, Aug 30, 2017 at 1:26 PM, Mark Hanson  wrote:
>>> 
>>> Hi All,
>>> 
>>> 
>>> *Question: how should we deal in a very forward and clean fashion with
>> the
>>> implicit ambiguity of -1 or all, or infinite, or forever?*
>>> 
>>> 
>>> *Background:*
>>> 
>>> 
>>> We are looking to get some feedback on the subject of
>> infinite/all/forever
>>> in the geode/geode-native code.
>>> 
>>> 
>>> In looking at the code, we see an example function,
>>> 
>>> 
>>> setRetryAttempts
>>> >> 006df0e70eeb481ef5e9e821dba0050dee9c6893/cppcache/include/
>>> geode/PoolFactory.hpp#L327>()
>>> [1] currently -1 means try all servers before failing. 0 means try 1
>> server
>>> before failing, and a number greater than 0 means try number of servers
>> +1
>>> before failing. In the case of setRetryAttempts, we don’t know how many
>>> servers there are. This means that -1 for "All" servers has no relation
>> to
>>> the actual number of servers that we have. Perhaps setRetryAttempts could
>>> be renamed to setNumberOfAttempts to clarify as well, but the problem
>> still
>>> stands...
>>> 
>>> 
>>> *Discussion:*
>>> 
>>> 
>>> In an attempt to provide the best code possible to the geode community,
>>> there has been some discussion of the use of infinite/all/forever as an
>>> overload of a count. Often -1 indicates infinite, while 0 indicates
>> never,
>>> and 1 to MAXINT, inclusive, indicates a count.
>>> 
>>> 
>>> There are three obvious approaches to solve the problem of the
>> overloading
>>> of -1. The first approach is do nothing… Status quo.
>>> 
>>> 
>>> The second approach to clarify things would be to create an enumeration
>>> that would be passed in as well as the number or an object..
>>> 
>>> 
>>> struct Retries
>>> 
>>> {
>>> 
>>>  typedef enum { eINFINITE, eCOUNT, eNONE} eCount;
>>> 
>>>  eCount approach;
>>> 
>>>  unsigned int count;
>>> 
>>> };
>>> 
>>> 
>>> 
>>> The third approach would be to pass a continue object of some sort such
>>> that it tells you if it is ok to continue through the use of an
>> algorithm.
>>> 
>>> 
>>> An example would be
>>> 
>>> 
>>> class Continue
>>> 
>>> {
>>> 
>>> virtual bool Continue() = 0;
>>> 
>>> }
>>> 
>>> 
>>> class InfiniteContinue : public Continue
>>> 
>>> {
>>> 
>>> bool Continue()
>>> 
>>> {
>>> 
>>> return true;
>>> 
>>> }
>>> 
>>> }
>>> 
>>> 
>>> Continue co = InfiniteContinue;
>>> 
>>> 
>>> while( co.Continue() )
>>> 
>>> {
>>> 
>>> //do a thing
>>> 
>>> }
>>> 
>>> 
>>> Another example would be a Continue limited to 5 let’s say,
>>> 
>>> 
>>> class CountContinue : public Continue
>>> 
>>> {
>>> 
>>> private:
>>> 
>>> int count;
>>> 
>>> 
>>> public:
>>> 
>>> CountContinue(int count)
>>> 
>>> {
>>> 
>>> this.count = count;
>>> 
>>> }
>>> 
>>> bool Continue()
>>> 
>>> {
>>> 
>>>  return count— > 0;
>>> 
>>> }
>>> 
>>> }
>>> 
>>> 
>>> In both of these cases what is happening is that the algorithm is being
>>> outsourced.
>>> 
>>> 
>>> *Conclusion:*
>>> 
>>> 
>>> We are putting this out, to start a discussion on the best way to move
>> this
>>> forward… *What do people think? What direction would be the best going
>>> forward?*
>>> 
>>> 
>>> [1]
>>> https://github.com/apache/geode-native/blob/
>> 006df0e70eeb481ef5e9e821dba005
>>> 0dee9c6893/cppcache/include/geode/PoolFactory.hpp#L327
>>> 
>> 

Re: [Discuss] Use of -1 as Infinite/All for retry related functions...

[Dan Smith]

In general, I think we need making the configuration of geode less complex,
not more.

As far as retry-attempts goes, maybe the best thing to do is to get rid of
it. The P2P layer has no such concept. I don't think users should really
have to care about how many servers an operation is attempted against. A
user may want to specify how long an operation is allowed to take, but that
could be better specified with an operation timeout rather than the current
read-timeout + retry-attempts.

-Dan



On Wed, Aug 30, 2017 at 2:08 PM, Patrick Rhomberg 
wrote:

> Personally, I don't much like sentinel values, even if they have their
> occasional use.
>
> Do we need to provide an authentic infinite value?  64-bit MAXINT is nearly
> 10 quintillion.  At 10GHz, that still takes almost three years.  If each
> retry takes as much as 10ms, we're still looking at "retry for as long as
> the earth has existed."  32-bit's is much more attainable, of course, but I
> think the point stands -- if you need to retry that much, something else is
> very wrong.
>
> In the more general sense, I struggle to think of a context where an
> authentic infinity is meaningfully distinct in application from a massive
> finite like MAXINT.  But I could be wrong and would love to hear what other
> people think.
>
> On Wed, Aug 30, 2017 at 1:26 PM, Mark Hanson  wrote:
>
> > Hi All,
> >
> >
> > *Question: how should we deal in a very forward and clean fashion with
> the
> > implicit ambiguity of -1 or all, or infinite, or forever?*
> >
> >
> > *Background:*
> >
> >
> > We are looking to get some feedback on the subject of
> infinite/all/forever
> > in the geode/geode-native code.
> >
> >
> > In looking at the code, we see an example function,
> >
> >
> > setRetryAttempts
> >  > 006df0e70eeb481ef5e9e821dba0050dee9c6893/cppcache/include/
> > geode/PoolFactory.hpp#L327>()
> > [1] currently -1 means try all servers before failing. 0 means try 1
> server
> > before failing, and a number greater than 0 means try number of servers
> +1
> > before failing. In the case of setRetryAttempts, we don’t know how many
> > servers there are. This means that -1 for "All" servers has no relation
> to
> > the actual number of servers that we have. Perhaps setRetryAttempts could
> > be renamed to setNumberOfAttempts to clarify as well, but the problem
> still
> > stands...
> >
> >
> > *Discussion:*
> >
> >
> > In an attempt to provide the best code possible to the geode community,
> > there has been some discussion of the use of infinite/all/forever as an
> > overload of a count. Often -1 indicates infinite, while 0 indicates
> never,
> > and 1 to MAXINT, inclusive, indicates a count.
> >
> >
> > There are three obvious approaches to solve the problem of the
> overloading
> > of -1. The first approach is do nothing… Status quo.
> >
> >
> > The second approach to clarify things would be to create an enumeration
> > that would be passed in as well as the number or an object..
> >
> >
> > struct Retries
> >
> > {
> >
> >   typedef enum { eINFINITE, eCOUNT, eNONE} eCount;
> >
> >   eCount approach;
> >
> >   unsigned int count;
> >
> > };
> >
> >
> >
> > The third approach would be to pass a continue object of some sort such
> > that it tells you if it is ok to continue through the use of an
> algorithm.
> >
> >
> > An example would be
> >
> >
> > class Continue
> >
> > {
> >
> > virtual bool Continue() = 0;
> >
> > }
> >
> >
> > class InfiniteContinue : public Continue
> >
> > {
> >
> > bool Continue()
> >
> > {
> >
> > return true;
> >
> > }
> >
> > }
> >
> >
> > Continue co = InfiniteContinue;
> >
> >
> > while( co.Continue() )
> >
> > {
> >
> > //do a thing
> >
> > }
> >
> >
> > Another example would be a Continue limited to 5 let’s say,
> >
> >
> > class CountContinue : public Continue
> >
> > {
> >
> > private:
> >
> > int count;
> >
> >
> > public:
> >
> > CountContinue(int count)
> >
> > {
> >
> > this.count = count;
> >
> > }
> >
> > bool Continue()
> >
> > {
> >
> >   return count— > 0;
> >
> > }
> >
> > }
> >
> >
> > In both of these cases what is happening is that the algorithm is being
> > outsourced.
> >
> >
> > *Conclusion:*
> >
> >
> > We are putting this out, to start a discussion on the best way to move
> this
> > forward… *What do people think? What direction would be the best going
> > forward?*
> >
> >
> > [1]
> > https://github.com/apache/geode-native/blob/
> 006df0e70eeb481ef5e9e821dba005
> > 0dee9c6893/cppcache/include/geode/PoolFactory.hpp#L327
> >
>

Re: [Discuss] Use of -1 as Infinite/All for retry related functions...

[Jacob Barrett]

-1 for using -1!

Another option is to change the factory API to:

withRetryAttempts(uint32_t retryAttempts)
Will attempt no more than `retryAttempts`, may be less if all available
servers are exhausted.

withRetryAttemptsAllServers()
Will retry on all servers.

withoutRetryAttempts()
Will not retry. Same behavior as `withRetryAttempts(0)`.

-Jake


On Wed, Aug 30, 2017 at 2:09 PM Patrick Rhomberg 
wrote:

> Personally, I don't much like sentinel values, even if they have their
> occasional use.
>
> Do we need to provide an authentic infinite value?  64-bit MAXINT is nearly
> 10 quintillion.  At 10GHz, that still takes almost three years.  If each
> retry takes as much as 10ms, we're still looking at "retry for as long as
> the earth has existed."  32-bit's is much more attainable, of course, but I
> think the point stands -- if you need to retry that much, something else is
> very wrong.
>
> In the more general sense, I struggle to think of a context where an
> authentic infinity is meaningfully distinct in application from a massive
> finite like MAXINT.  But I could be wrong and would love to hear what other
> people think.
>
> On Wed, Aug 30, 2017 at 1:26 PM, Mark Hanson  wrote:
>
> > Hi All,
> >
> >
> > *Question: how should we deal in a very forward and clean fashion with
> the
> > implicit ambiguity of -1 or all, or infinite, or forever?*
> >
> >
> > *Background:*
> >
> >
> > We are looking to get some feedback on the subject of
> infinite/all/forever
> > in the geode/geode-native code.
> >
> >
> > In looking at the code, we see an example function,
> >
> >
> > setRetryAttempts
> >  > 006df0e70eeb481ef5e9e821dba0050dee9c6893/cppcache/include/
> > geode/PoolFactory.hpp#L327>()
> > [1] currently -1 means try all servers before failing. 0 means try 1
> server
> > before failing, and a number greater than 0 means try number of servers
> +1
> > before failing. In the case of setRetryAttempts, we don’t know how many
> > servers there are. This means that -1 for "All" servers has no relation
> to
> > the actual number of servers that we have. Perhaps setRetryAttempts could
> > be renamed to setNumberOfAttempts to clarify as well, but the problem
> still
> > stands...
> >
> >
> > *Discussion:*
> >
> >
> > In an attempt to provide the best code possible to the geode community,
> > there has been some discussion of the use of infinite/all/forever as an
> > overload of a count. Often -1 indicates infinite, while 0 indicates
> never,
> > and 1 to MAXINT, inclusive, indicates a count.
> >
> >
> > There are three obvious approaches to solve the problem of the
> overloading
> > of -1. The first approach is do nothing… Status quo.
> >
> >
> > The second approach to clarify things would be to create an enumeration
> > that would be passed in as well as the number or an object..
> >
> >
> > struct Retries
> >
> > {
> >
> >   typedef enum { eINFINITE, eCOUNT, eNONE} eCount;
> >
> >   eCount approach;
> >
> >   unsigned int count;
> >
> > };
> >
> >
> >
> > The third approach would be to pass a continue object of some sort such
> > that it tells you if it is ok to continue through the use of an
> algorithm.
> >
> >
> > An example would be
> >
> >
> > class Continue
> >
> > {
> >
> > virtual bool Continue() = 0;
> >
> > }
> >
> >
> > class InfiniteContinue : public Continue
> >
> > {
> >
> > bool Continue()
> >
> > {
> >
> > return true;
> >
> > }
> >
> > }
> >
> >
> > Continue co = InfiniteContinue;
> >
> >
> > while( co.Continue() )
> >
> > {
> >
> > //do a thing
> >
> > }
> >
> >
> > Another example would be a Continue limited to 5 let’s say,
> >
> >
> > class CountContinue : public Continue
> >
> > {
> >
> > private:
> >
> > int count;
> >
> >
> > public:
> >
> > CountContinue(int count)
> >
> > {
> >
> > this.count = count;
> >
> > }
> >
> > bool Continue()
> >
> > {
> >
> >   return count— > 0;
> >
> > }
> >
> > }
> >
> >
> > In both of these cases what is happening is that the algorithm is being
> > outsourced.
> >
> >
> > *Conclusion:*
> >
> >
> > We are putting this out, to start a discussion on the best way to move
> this
> > forward… *What do people think? What direction would be the best going
> > forward?*
> >
> >
> > [1]
> >
> https://github.com/apache/geode-native/blob/006df0e70eeb481ef5e9e821dba005
> > 0dee9c6893/cppcache/include/geode/PoolFactory.hpp#L327
> >
>

Build failed in Jenkins: Geode-nightly-flaky #107

[Apache Jenkins Server]

See 


Changes:

[jiliao] GEODE-3472: Remove a great deal of commented-out code.

[jstewart] GEODE-2859: Fix race condition in ShowDeadlockDUnitTest

[jiliao] GEODE-3539: add test for invalid command

[bschuchardt] GEODE-3249 Validate internal client/server messages

[kmiller] GEODE-3330 Document modified CQ authorization permissions

[kmiller] GEODE-3330 Correct doc of CQ authorization permissions

--
[...truncated 111.61 KB...]
:geode-lucene:javadocJar
:geode-lucene:sourcesJar
:geode-lucene:signArchives SKIPPED
:geode-old-client-support:jar
:geode-old-client-support:javadoc
:geode-old-client-support:javadocJar
:geode-old-client-support:sourcesJar
:geode-old-client-support:signArchives SKIPPED
:geode-protobuf:jar
:geode-protobuf:javadoc
:geode-protobuf:javadocJar
:geode-protobuf:sourcesJar
:geode-protobuf:signArchives SKIPPED
:geode-pulse:javadoc
:geode-pulse:javadocJar
:geode-pulse:sourcesJar
:geode-pulse:war
:geode-pulse:signArchives SKIPPED
:geode-rebalancer:jar
:geode-rebalancer:javadoc
:geode-rebalancer:javadocJar
:geode-rebalancer:sourcesJar
:geode-rebalancer:signArchives SKIPPED
:geode-wan:jar
:geode-wan:javadoc
:geode-wan:javadocJar
:geode-wan:sourcesJar
:geode-wan:signArchives SKIPPED
:geode-web:javadoc NO-SOURCE
:geode-web:javadocJar
:geode-web:sourcesJar
:geode-web:war
:geode-web:signArchives SKIPPED
:geode-web-api:javadoc
:geode-web-api:javadocJar
:geode-web-api:sourcesJar
:geode-web-api:war
:geode-web-api:signArchives SKIPPED
:geode-assembly:installDist
:geode-pulse:jar
:geode-assembly:compileTestJava
Download 
https://repo1.maven.org/maven2/org/codehaus/cargo/cargo-core-uberjar/1.6.3/cargo-core-uberjar-1.6.3.pom
Download 
https://repo1.maven.org/maven2/org/codehaus/cargo/cargo-core/1.6.3/cargo-core-1.6.3.pom
Download 
https://repo1.maven.org/maven2/org/codehaus/cargo/codehaus-cargo/1.6.3/codehaus-cargo-1.6.3.pom
Download 
https://repo1.maven.org/maven2/org/codehaus/cargo/cargo-core-uberjar/1.6.3/cargo-core-uberjar-1.6.3.jar
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
:geode-assembly:processTestResources
:geode-assembly:testClasses
:geode-assembly:flakyTest
:geode-benchmarks:compileTestJava NO-SOURCE
:geode-benchmarks:processTestResources NO-SOURCE
:geode-benchmarks:testClasses UP-TO-DATE
:geode-benchmarks:flakyTest NO-SOURCE
:geode-common:compileTestJava
:geode-common:processTestResources NO-SOURCE
:geode-common:testClasses
:geode-common:flakyTest
:geode-core:flakyTest

org.apache.geode.management.RegionManagementDUnitTest > testNavigationAPIS 
FAILED
org.apache.geode.test.dunit.RMIException: While invoking 
org.apache.geode.test.dunit.NamedRunnable.run in VM 0 running on Host 
asf914.gq1.ygridcore.net with 4 VMs
at org.apache.geode.test.dunit.VM.invoke(VM.java:387)
at org.apache.geode.test.dunit.VM.invoke(VM.java:357)
at org.apache.geode.test.dunit.VM.invoke(VM.java:290)
at 
org.apache.geode.management.RegionManagementDUnitTest.verifyNavigationApis(RegionManagementDUnitTest.java:422)
at 
org.apache.geode.management.RegionManagementDUnitTest.testNavigationAPIS(RegionManagementDUnitTest.java:285)

Caused by:
org.awaitility.core.ConditionTimeoutException: Condition defined as a 
lambda expression in org.apache.geode.management.RegionManagementDUnitTest that 
uses org.apache.geode.management.DistributedSystemMXBean, 
org.apache.geode.management.DistributedSystemMXBeanint expected:<[4]> but 
was:<[5]> within 2 minutes.
at 
org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:104)
at 
org.awaitility.core.AssertionCondition.await(AssertionCondition.java:117)
at 
org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
at 
org.awaitility.core.ConditionFactory.until(ConditionFactory.java:809)
at 
org.awaitility.core.ConditionFactory.until(ConditionFactory.java:648)
at 
org.apache.geode.management.RegionManagementDUnitTest.awaitMemberCount(RegionManagementDUnitTest.java:1065)
at 
org.apache.geode.management.RegionManagementDUnitTest.lambda$verifyNavigationApis$8ec4a763$1(RegionManagementDUnitTest.java:426)

339 tests completed, 1 failed, 9 skipped
:geode-core:flakyTest FAILED
:geode-cq:compileTestJavaNote: Some input files use or override a deprecated 
API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-cq:processTestResources
:geode-cq:testClasses
:geode-cq:flakyTest
:geode-json:compileTestJava NO-SOURCE
:geode-json:processTestResources
:geode-json:testClasses
:geode-json:flakyTest NO-SOURCE

Build failed in Jenkins: Geode-nightly #939

[Apache Jenkins Server]

See 


Changes:

[jiliao] GEODE-3436: Restore refactoring of MemberCommands

[jiliao] GEODE-3436: Restore refactoring of DurableClientCommands

[jiliao] GEODE-3436: Restore refactoring of PDXCommands

[jiliao] GEODE-3436: Restore refactoring of RegionCommands

[jiliao] GEODE-3436: Restore refactoring of QueueCommands

[jiliao] GEODE-3436: Restore refactoring of GfshHelpCommands

[jiliao] GEODE-3436: Restore refactoring of CreateAlterDestroyRegionCommands

[jiliao] GEODE-3436: Restore refactoring of Refactoring FunctionCommands

[jiliao] GEODE-3436: Restore refactoring of Refactoring MiscellaneousCommands

[jiliao] GEODE-3436: Restore refactoring of ConfigCommands

[jiliao] GEODE-3436: Restore refactoring of IndexCommands

[jiliao] GEODE-3436: Restore refactoring of DiskStoreCommands

[jiliao] GEODE-3436: Restore refactoring of DeployCommands

[jiliao] GEODE-3436: Restore refactoring of StatusCommands

[jiliao] GEODE-3436: Suggested improvements to touched files.

[dbarnes] GEODE-3515 User Guide: bad table format, multi-site firewall 
properties

[khowe] GEODE-3277: revert changes to Launcher bind address and State

[dcavender] Define acceptanceTest task for all submodules

[bschuchardt] GEODE-3519 servers are not locking on some ops initiated by 
clients

[bschuchardt] GEODE-3529 move new client/server security classes to a different

[klund] GEODE-3404: add FlakyTest category to entire test class

[klund] GEODE-3538: make RequiresGeodeHome Serializable

[klund] GEODE-3530: move FlakyTest category to class

[nnag] GEODE-3502: Added awaitility clauses.

[jstewart] GEODE-3445: Convert connect acceptance test to DUnit test

--
[...truncated 271.30 KB...]
---
* What went wrong:
Execution failed for task ':geode-cq:distributedTest'.
> There were failing tests. See the report at: 
> file://

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug 
option to get more log output.
==

5: Task failed with an exception.
---
* What went wrong:
Execution failed for task ':geode-web:distributedTest'.
> There were failing tests. See the report at: 
> file://

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug 
option to get more log output.
==

6: Task failed with an exception.
---
* Where:
Script ' 
line: 116

* What went wrong:
Execution failed for task ':extensions/geode-modules-assembly:uploadArchives'.
> Could not find which method repositories() to invoke from this list:
public org.gradle.api.artifacts.dsl.RepositoryHandler 
org.gradle.api.tasks.Upload#repositories(groovy.lang.Closure)
public org.gradle.api.artifacts.dsl.RepositoryHandler 
org.gradle.api.tasks.Upload#repositories(org.gradle.api.Action)

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug 
option to get more log output.
==

7: Task failed with an exception.
---
* Where:
Script ' 
line: 116

* What went wrong:
Execution failed for task ':geode-common:uploadArchives'.
> Could not find which method repositories() to invoke from this list:
public org.gradle.api.artifacts.dsl.RepositoryHandler 
org.gradle.api.tasks.Upload#repositories(groovy.lang.Closure)
public org.gradle.api.artifacts.dsl.RepositoryHandler 
org.gradle.api.tasks.Upload#repositories(org.gradle.api.Action)

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug 
option to get more log output.
==

8: Task failed with an exception.
---
* Where:
Script ' 
line: 116

* What went wrong:
Execution failed for task ':geode-core:uploadArchives'.
> Could not find which method repositories() to invoke from this list:
public org.gradle.api.artifacts.dsl.RepositoryHandler 
org.gradle.api.tasks.Upload#repositories(groovy.lang.Closure)
public org.gradle.api.artifacts.dsl.RepositoryHandler 
org.gradle.api.tasks.Upload#repositories(org.gradle.api.Action)

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug 
option to get more log output.
==

9: Task failed with an exception.

[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #663 was SUCCESSFUL (with 2027 tests)

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #663 was successful.
---
Scheduled
2029 tests in total.

https://build.spring.io/browse/SGF-NAG-663/





--
This message is automatically generated by Atlassian Bamboo

Review Request 62002: GEODE-3539: Add tests for List Members and Describe Member

[Jared Stewart]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/62002/
---

Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, Kirk Lund, and 
Patrick Rhomberg.


Repository: geode


Description
---

GEODE-3539: Add tests for List Members and Describe Member


Diffs
-

  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ListMemberCommand.java
 ea88c69ebdd2ce5ffbab486fcb7a4dda71935586 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/result/CommandResult.java
 bbb59d0755ffd2cf405f78c89b420a5279844e29 
  
geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/MemberCommandsController.java
 ba5c788f90ef68dc8ac338a4619646b4f3608293 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/DescribeMembersCommandDUnitTest.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ListMembersCommandDUnitTest.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/MemberCommandsDUnitTest.java
 fe6bc404d33b48e5384348241c17ccf924f4627c 
  
geode-core/src/test/java/org/apache/geode/management/internal/security/TestCommand.java
 17719be16338ab9894878660054b75ff9cc6c3ec 


Diff: https://reviews.apache.org/r/62002/diff/1/


Testing
---

Precheckin running


Thanks,

Jared Stewart

Re: [CANCEL][VOTE] Apache Geode release - v1.2.1 RC1

[Bruce Schuchardt]

I've pushed the fix for the problem with geode-3249 to develop and 
cherry-picked it on the release/1.2.1 branch



On 8/30/17 2:59 PM, Anthony Baker wrote:

This vote is cancelled due to an error an in the fix for GEODE-3249.

Anthony


On Wed, Aug 30, 2017 at 10:25 AM, Bruce Schuchardt
 wrote:

We've found a problem with the fix for geode-3249 that should probably be
corrected in the 1.2.1 release.



On 8/29/17 12:07 PM, Anthony Baker wrote:

I encourage the PMC members to review and vote so we can close out this
release.  Of course, all feedback is welcome.

Thanks,
Anthony


On Aug 25, 2017, at 3:20 PM, Anthony Baker  wrote:

This is the first release candidate for Apache Geode, version 1.2.1.
Thanks to all the community members for their contributions to this
release!

*** Please download, test and vote by Wednesday, August 25, 0800 hrs
US Pacific. ***

It fixes the following issues:

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318420=12341124

Note that we are voting upon the source tags:  rel/v1.2.1.RC1

https://git-wip-us.apache.org/repos/asf?p=geode.git;a=commit;h=1bb1cae34814bdca298e476f8b88d19e4bc0dd51

https://git-wip-us.apache.org/repos/asf?p=geode-examples.git;a=commit;h=5d034de588a43cdefb8fbb3a6259579785768340

Commit ID:
   1bb1cae34814bdca298e476f8b88d19e4bc0dd51 (geode)
   5d034de588a43cdefb8fbb3a6259579785768340 (geode-examples)

Source and binary files:
   https://dist.apache.org/repos/dist/dev/geode/1.2.1.RC1

Maven staging repo:
   https://repository.apache.org/content/repositories/orgapachegeode-1021

Geode's KEYS file containing PGP keys we use to sign the release:

https://git-wip-us.apache.org/repos/asf?p=geode.git;a=blob_plain;f=KEYS;hb=HEAD

pub  4096R/C72CFB64 2015-10-01
   Fingerprint=948E 8234 14BE 693A 7F74  ABBE 19DB CAEE C72C FB64

Anthony

Review Request 62001: GEODE-3525: Dockerize AcceptanceTests

[Jared Stewart]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/62001/
---

Review request for geode, Anthony Baker, Jens Deppe, Jinmei Liao, Jared 
Stewart, Ken Howe, Kirk Lund, and Patrick Rhomberg.


Repository: geode


Description
---

GEODE-3525: Dockerize AcceptanceTests


Diffs
-

  gradle/docker.gradle b5a356f6222848f672261cf0050c02044b3c112e 


Diff: https://reviews.apache.org/r/62001/diff/1/


Testing
---

Passed precheckin, both with and without the -PparallelDUnit flag set.


Thanks,

Jared Stewart

[CANCEL][VOTE] Apache Geode release - v1.2.1 RC1

[Anthony Baker]

This vote is cancelled due to an error an in the fix for GEODE-3249.

Anthony


On Wed, Aug 30, 2017 at 10:25 AM, Bruce Schuchardt
 wrote:
> We've found a problem with the fix for geode-3249 that should probably be
> corrected in the 1.2.1 release.
>
>
>
> On 8/29/17 12:07 PM, Anthony Baker wrote:
>>
>> I encourage the PMC members to review and vote so we can close out this
>> release.  Of course, all feedback is welcome.
>>
>> Thanks,
>> Anthony
>>
>>> On Aug 25, 2017, at 3:20 PM, Anthony Baker  wrote:
>>>
>>> This is the first release candidate for Apache Geode, version 1.2.1.
>>> Thanks to all the community members for their contributions to this
>>> release!
>>>
>>> *** Please download, test and vote by Wednesday, August 25, 0800 hrs
>>> US Pacific. ***
>>>
>>> It fixes the following issues:
>>>
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318420=12341124
>>>
>>> Note that we are voting upon the source tags:  rel/v1.2.1.RC1
>>>
>>> https://git-wip-us.apache.org/repos/asf?p=geode.git;a=commit;h=1bb1cae34814bdca298e476f8b88d19e4bc0dd51
>>>
>>> https://git-wip-us.apache.org/repos/asf?p=geode-examples.git;a=commit;h=5d034de588a43cdefb8fbb3a6259579785768340
>>>
>>> Commit ID:
>>>   1bb1cae34814bdca298e476f8b88d19e4bc0dd51 (geode)
>>>   5d034de588a43cdefb8fbb3a6259579785768340 (geode-examples)
>>>
>>> Source and binary files:
>>>   https://dist.apache.org/repos/dist/dev/geode/1.2.1.RC1
>>>
>>> Maven staging repo:
>>>   https://repository.apache.org/content/repositories/orgapachegeode-1021
>>>
>>> Geode's KEYS file containing PGP keys we use to sign the release:
>>>
>>> https://git-wip-us.apache.org/repos/asf?p=geode.git;a=blob_plain;f=KEYS;hb=HEAD
>>>
>>> pub  4096R/C72CFB64 2015-10-01
>>>   Fingerprint=948E 8234 14BE 693A 7F74  ABBE 19DB CAEE C72C FB64
>>>
>>> Anthony
>
>

[GitHub] geode pull request #750: GEODE-3330 Document modified CQ authorization permi...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/geode/pull/750


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [Discuss] Use of -1 as Infinite/All for retry related functions...

[Patrick Rhomberg]

Personally, I don't much like sentinel values, even if they have their
occasional use.

Do we need to provide an authentic infinite value?  64-bit MAXINT is nearly
10 quintillion.  At 10GHz, that still takes almost three years.  If each
retry takes as much as 10ms, we're still looking at "retry for as long as
the earth has existed."  32-bit's is much more attainable, of course, but I
think the point stands -- if you need to retry that much, something else is
very wrong.

In the more general sense, I struggle to think of a context where an
authentic infinity is meaningfully distinct in application from a massive
finite like MAXINT.  But I could be wrong and would love to hear what other
people think.

On Wed, Aug 30, 2017 at 1:26 PM, Mark Hanson  wrote:

> Hi All,
>
>
> *Question: how should we deal in a very forward and clean fashion with the
> implicit ambiguity of -1 or all, or infinite, or forever?*
>
>
> *Background:*
>
>
> We are looking to get some feedback on the subject of infinite/all/forever
> in the geode/geode-native code.
>
>
> In looking at the code, we see an example function,
>
>
> setRetryAttempts
>  006df0e70eeb481ef5e9e821dba0050dee9c6893/cppcache/include/
> geode/PoolFactory.hpp#L327>()
> [1] currently -1 means try all servers before failing. 0 means try 1 server
> before failing, and a number greater than 0 means try number of servers +1
> before failing. In the case of setRetryAttempts, we don’t know how many
> servers there are. This means that -1 for "All" servers has no relation to
> the actual number of servers that we have. Perhaps setRetryAttempts could
> be renamed to setNumberOfAttempts to clarify as well, but the problem still
> stands...
>
>
> *Discussion:*
>
>
> In an attempt to provide the best code possible to the geode community,
> there has been some discussion of the use of infinite/all/forever as an
> overload of a count. Often -1 indicates infinite, while 0 indicates never,
> and 1 to MAXINT, inclusive, indicates a count.
>
>
> There are three obvious approaches to solve the problem of the overloading
> of -1. The first approach is do nothing… Status quo.
>
>
> The second approach to clarify things would be to create an enumeration
> that would be passed in as well as the number or an object..
>
>
> struct Retries
>
> {
>
>   typedef enum { eINFINITE, eCOUNT, eNONE} eCount;
>
>   eCount approach;
>
>   unsigned int count;
>
> };
>
>
>
> The third approach would be to pass a continue object of some sort such
> that it tells you if it is ok to continue through the use of an algorithm.
>
>
> An example would be
>
>
> class Continue
>
> {
>
> virtual bool Continue() = 0;
>
> }
>
>
> class InfiniteContinue : public Continue
>
> {
>
> bool Continue()
>
> {
>
> return true;
>
> }
>
> }
>
>
> Continue co = InfiniteContinue;
>
>
> while( co.Continue() )
>
> {
>
> //do a thing
>
> }
>
>
> Another example would be a Continue limited to 5 let’s say,
>
>
> class CountContinue : public Continue
>
> {
>
> private:
>
> int count;
>
>
> public:
>
> CountContinue(int count)
>
> {
>
> this.count = count;
>
> }
>
> bool Continue()
>
> {
>
>   return count— > 0;
>
> }
>
> }
>
>
> In both of these cases what is happening is that the algorithm is being
> outsourced.
>
>
> *Conclusion:*
>
>
> We are putting this out, to start a discussion on the best way to move this
> forward… *What do people think? What direction would be the best going
> forward?*
>
>
> [1]
> https://github.com/apache/geode-native/blob/006df0e70eeb481ef5e9e821dba005
> 0dee9c6893/cppcache/include/geode/PoolFactory.hpp#L327
>

[GitHub] geode pull request #750: GEODE-3330 Document modified CQ authorization permi...

[karensmolermiller]

GitHub user karensmolermiller opened a pull request:

https://github.com/apache/geode/pull/750

GEODE-3330 Document modified CQ authorization permissions

@joeymcallister @davebarnes97 @jinmeiliao @kirklund @jaredjstewart
Please review.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/karensmolermiller/geode feature/GEODE-3330

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/geode/pull/750.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #750


commit de50e433f8d381e85d9df311794bd0bdebfe0712
Author: Karen Miller 
Date:   2017-08-30T21:00:28Z

GEODE-3330 Document modified CQ authorization permissions




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Review Request 61978: GEODE-3059: LoadMonitor.connectionClosed incrementing statistics only for client-server connection

[Bruce Schuchardt]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/61978/
---

(Updated Aug. 30, 2017, 1:48 p.m.)


Review request for geode, Alexander Murmann, Galen O'Sullivan, Hitesh Khamesra, 
and Udo Kohlmeyer.


Changes
---

A couple of distributed tests failed due to the new check for a valid mode so 
I've added a try/catch and throw EOFException if the communication mode isn't 
known.  The tests that failed created SSL connections to a server that did not 
have SSL enabled.


Bugs: GEODE-3059
https://issues.apache.org/jira/browse/GEODE-3059


Repository: geode


Description
---

The stat should only be incremented/decremented for certain kinds of 
connections.  I've modified it to include protobuf connections.  All of the 
constant byte identifiers in Acceptor.java have been moved to an enum in 
CommunicationMode.java.  In that class I've added some "isa" checks to replace 
the many big "if" checks for different kinds of connection modes.

A new connection modes will henceforth need to be added to 
CommunicationMode.java where the appropriate "isa" methods can be updated to 
include the new mode.


Diffs (updated)
-

  
geode-core/src/main/java/org/apache/geode/cache/client/internal/ConnectionFactoryImpl.java
 dea8644bf6604a48b38e0f8a9fcfa48deb4b56c8 
  
geode-core/src/main/java/org/apache/geode/cache/client/internal/ConnectionImpl.java
 078844f7adc907761c8b0b1b5525874c8338144e 
  
geode-core/src/main/java/org/apache/geode/cache/server/internal/LoadMonitor.java
 1c571a924f5517f7ba1a04e216c3641f96f9ddc4 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/tcpserver/TcpServer.java
 83f87eebe3f7cbea628107078e1bafac478a0228 
  geode-core/src/main/java/org/apache/geode/internal/cache/tier/Acceptor.java 
e12a409bc556ab74718830ff8036edd6216ef53b 
  
geode-core/src/main/java/org/apache/geode/internal/cache/tier/ClientHandShake.java
 f7a39f3c86f261d76133b2bebb864f53be027f1a 
  
geode-core/src/main/java/org/apache/geode/internal/cache/tier/CommunicationMode.java
 PRE-CREATION 
  
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/AcceptorImpl.java
 2e33af897a852a2f397cf3c1d7f3b20ae3b1d69f 
  
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/CacheClientNotifier.java
 e2612fc45ccf59ee64654380b771835415780f9d 
  
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/ClientHealthMonitor.java
 e877852a42009c0cadeaa0e69516bdbcd84e6bd4 
  
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/ConnectionListener.java
 104d88abc99d3b329834f53d558b4684b6f9c226 
  
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/ConnectionListenerAdapter.java
 7476b4fba5def66c52b1fa26fb3f0f2e4c63fd17 
  
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/HandShake.java
 690fd83971d9ac9f8ecedf9b89acb7ade887f38e 
  
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/ServerConnection.java
 6f56e85382ded1668bc51f6c0f2cc4990a493750 
  
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/ServerConnectionFactory.java
 00e8b8880a5f336bb82c578f29acaf256187bb5c 
  
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/ServerHandShakeProcessor.java
 47e6f3d0bd9cab249e8f92398b116c6111b0e60e 
  
geode-core/src/test/java/org/apache/geode/cache/server/internal/LoadMonitorTest.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/internal/cache/tier/sockets/GenericProtocolServerConnectionTest.java
 ea0001867e5a22025f4dbca4ead172ff25f2af4d 
  
geode-core/src/test/java/org/apache/geode/internal/cache/tier/sockets/ServerConnectionFactoryTest.java
 cffa05fa49de58187eaab5bb10c7f2a6ed3bf0f5 
  
geode-core/src/test/java/org/apache/geode/internal/cache/tier/sockets/ServerConnectionTest.java
 2aa89954659594428ae3f6ed6d7146261d518203 
  
geode-core/src/test/resources/org/apache/geode/codeAnalysis/excludedClasses.txt 
fbd582a1fa3c0e7b0bce033924f38d45ba2c2a9e 
  
geode-protobuf/src/test/java/org/apache/geode/protocol/AuthenticationIntegrationTest.java
 122b8e3ba7ecab407fdedf6be35153a1def728ff 
  
geode-protobuf/src/test/java/org/apache/geode/protocol/RoundTripLocatorConnectionJUnitTest.java
 7ee307b4068247245fc02ab1ae7266c7e2e385c3 


Diff: https://reviews.apache.org/r/61978/diff/3/

Changes: https://reviews.apache.org/r/61978/diff/2-3/


Testing
---

precheckin is running now


Thanks,

Bruce Schuchardt

[Discuss] Use of -1 as Infinite/All for retry related functions...

[Mark Hanson]

Hi All,


*Question: how should we deal in a very forward and clean fashion with the
implicit ambiguity of -1 or all, or infinite, or forever?*


*Background:*


We are looking to get some feedback on the subject of infinite/all/forever
in the geode/geode-native code.


In looking at the code, we see an example function,


setRetryAttempts
()
[1] currently -1 means try all servers before failing. 0 means try 1 server
before failing, and a number greater than 0 means try number of servers +1
before failing. In the case of setRetryAttempts, we don’t know how many
servers there are. This means that -1 for "All" servers has no relation to
the actual number of servers that we have. Perhaps setRetryAttempts could
be renamed to setNumberOfAttempts to clarify as well, but the problem still
stands...


*Discussion:*


In an attempt to provide the best code possible to the geode community,
there has been some discussion of the use of infinite/all/forever as an
overload of a count. Often -1 indicates infinite, while 0 indicates never,
and 1 to MAXINT, inclusive, indicates a count.


There are three obvious approaches to solve the problem of the overloading
of -1. The first approach is do nothing… Status quo.


The second approach to clarify things would be to create an enumeration
that would be passed in as well as the number or an object..


struct Retries

{

  typedef enum { eINFINITE, eCOUNT, eNONE} eCount;

  eCount approach;

  unsigned int count;

};



The third approach would be to pass a continue object of some sort such
that it tells you if it is ok to continue through the use of an algorithm.


An example would be


class Continue

{

virtual bool Continue() = 0;

}


class InfiniteContinue : public Continue

{

bool Continue()

{

return true;

}

}


Continue co = InfiniteContinue;


while( co.Continue() )

{

//do a thing

}


Another example would be a Continue limited to 5 let’s say,


class CountContinue : public Continue

{

private:

int count;


public:

CountContinue(int count)

{

this.count = count;

}

bool Continue()

{

  return count— > 0;

}

}


In both of these cases what is happening is that the algorithm is being
outsourced.


*Conclusion:*


We are putting this out, to start a discussion on the best way to move this
forward… *What do people think? What direction would be the best going
forward?*


[1]
https://github.com/apache/geode-native/blob/006df0e70eeb481ef5e9e821dba0050dee9c6893/cppcache/include/geode/PoolFactory.hpp#L327

Re: Indxes and hints

[Jason Huynh]

You will probably have to step through debugger for this one.. it really
depends on the query.  For this query, I expect the query engine to pick
one index and run the rest of the criteria on the results of the first
index used.  My guess is you have created a CompactRangeIndex, and if so,
you can see in CompactRangeIndex.java around line 811:

if (ok && runtimeItr != null && iterOps != null) {

  ok = QueryUtils.applyCondition(iterOps, context);

}
This is where it would apply the older conditions (B and C or A and C
depending on which index was selected)
The query engine was modified to try to only use one index if it can.

The load from disk (again assuming CompactRangeIndex) is probably occurring
in MemoryIndexStore.getTargetObject.

On Wed, Aug 30, 2017 at 9:21 AM Roi Apelker  wrote:

> One more question:
>
> As I am trying to create a situation where the disk is accessed as least
> as possible
> (with a select distinct from X where a=1 and b>10 and c=true;
> In which a and b are indexes and c is not, and c is in the value which is
> evicted to disk)
>
> Did I get it right - that if I use a hint on a, or a hint on b, or a hint
> on both, it will first do a select on the hinted, and ONLY THEN the others?
>
> Can anyone refer me to the code (where the 2 phase search occurs)?
>
> Where is the value finally loaded from disk?
>
> Thank you
>
> Roi
> -Original Message-
> From: Roi Apelker
> Sent: Tuesday, August 29, 2017 4:02 PM
> To: dev@geode.apache.org
> Subject: RE: Indxes and hints
>
> Thank you Jason :-)
>
> -Original Message-
> From: Jason Huynh [mailto:jhu...@pivotal.io]
> Sent: Monday, August 28, 2017 7:24 PM
> To: dev@geode.apache.org
> Subject: Re: Indxes and hints
>
> Hi Roi,
>
> Answers are below the questions...
>
> Question 1. Is it true to say, that the query as it is will load all the
> data values from the file, since the field C is part of the value, which is
> already persisted to file?
>
> Depending on if an index is used or not, if an index is used, the values
> that are part of the results will need to be loaded to actually return a
> result.  If an index is not used, then the all the values would need to be
> loaded to actually have something to evaluate the filter criteria on.
>
> Question 2. If I add a hint on A and B, will it mean that there will be a
> "2 phase search", first the select on A and B, and then, only on the
> results, on the field C? (this way, not all records will be loaded from
> file, only those that suit the A and B condition)
>
> Depending on the  query, it could use one, or more.  If it's a query with
> only AND clauses, it should just choose one and then evaluate the other
> filters on the subset that is returned from the index.
>
> Question 3. Is it possible to define an index on a value field? (i.e. not
> from the key) - will it work exactly like defining one form the key or are
> three any limitations? (again, I am looking to overcome the situation,
> where as it seems, the records are loaded unnecessarily from disk)
>
> Yes, indexes can be defined on fields in the value.  It will work the same.
>
>
> If you are sure you are already using an index in the query and still
> loading every value for every execution of that query, there may be
> something weird going on...
>
> On Sun, Aug 27, 2017 at 2:55 AM Roi Apelker 
> wrote:
> This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement,
>
> you may review at https://www.amdocs.com/about/email-disclaimer <
> https://www.amdocs.com/about/email-disclaimer>
> This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement,
>
> you may review at https://www.amdocs.com/about/email-disclaimer <
> https://www.amdocs.com/about/email-disclaimer>
>

[GitHub] geode-examples pull request #15: GEODE-3195 Add querying example to the geod...

[karensmolermiller]

GitHub user karensmolermiller opened a pull request:

https://github.com/apache/geode-examples/pull/15

GEODE-3195 Add querying example to the geode-examples

Please review this revised example of querying two ways: programmatically 
and through gfsh.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/karensmolermiller/geode-examples 
feature/GEODE-3195-2

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/geode-examples/pull/15.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #15


commit cc7e23b63ca2c797399e42aa94b82623f9750e8f
Author: Karen Miller 
Date:   2017-07-12T20:00:07Z

GEODE-3195 Add querying example to the geode-examples




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] geode-examples issue #8: GEODE-3195 Add querying example to the geode-exampl...

[karensmolermiller]

Github user karensmolermiller commented on the issue:

https://github.com/apache/geode-examples/pull/8
  
Closing this PR.  Will resubmit a revised version of this example that 
addresses all review comments.



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] geode-examples pull request #8: GEODE-3195 Add querying example to the geode...

[karensmolermiller]

Github user karensmolermiller closed the pull request at:

https://github.com/apache/geode-examples/pull/8


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Review Request 61995: wip

[Jared Stewart]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/61995/#review184174
---


Ship it!




Ship It!

- Jared Stewart


On Aug. 30, 2017, 5:38 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/61995/
> ---
> 
> (Updated Aug. 30, 2017, 5:38 p.m.)
> 
> 
> Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
> Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-3539: add test for invalid command
> 
> * also rework GfshCommandIntegrationTest in assembly module
> 
> 
> Diffs
> -
> 
>   
> geode-assembly/src/test/java/org/apache/geode/management/internal/cli/commands/GfshCommandIntegrationTest.java
>  263b12cbdee2bc5637e64fdad0e34262ab5f25e7 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/GfshCommandIntegrationTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/StartMemberUtilsTest.java
>  PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/61995/diff/1/
> 
> 
> Testing
> ---
> 
> precheckin running
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

Review Request 61995: wip

[Jinmei Liao]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/61995/
---

Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
Patrick Rhomberg.


Repository: geode


Description
---

GEODE-3539: add test for invalid command

* also rework GfshCommandIntegrationTest in assembly module


Diffs
-

  
geode-assembly/src/test/java/org/apache/geode/management/internal/cli/commands/GfshCommandIntegrationTest.java
 263b12cbdee2bc5637e64fdad0e34262ab5f25e7 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/GfshCommandIntegrationTest.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/StartMemberUtilsTest.java
 PRE-CREATION 


Diff: https://reviews.apache.org/r/61995/diff/1/


Testing
---

precheckin running


Thanks,

Jinmei Liao

Re: [VOTE] Apache Geode release - v1.2.1 RC1

[Bruce Schuchardt]

We've found a problem with the fix for geode-3249 that should probably 
be corrected in the 1.2.1 release.



On 8/29/17 12:07 PM, Anthony Baker wrote:

I encourage the PMC members to review and vote so we can close out this 
release.  Of course, all feedback is welcome.

Thanks,
Anthony


On Aug 25, 2017, at 3:20 PM, Anthony Baker  wrote:

This is the first release candidate for Apache Geode, version 1.2.1.
Thanks to all the community members for their contributions to this
release!

*** Please download, test and vote by Wednesday, August 25, 0800 hrs
US Pacific. ***

It fixes the following issues:
  
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318420=12341124

Note that we are voting upon the source tags:  rel/v1.2.1.RC1
  
https://git-wip-us.apache.org/repos/asf?p=geode.git;a=commit;h=1bb1cae34814bdca298e476f8b88d19e4bc0dd51
  
https://git-wip-us.apache.org/repos/asf?p=geode-examples.git;a=commit;h=5d034de588a43cdefb8fbb3a6259579785768340

Commit ID:
  1bb1cae34814bdca298e476f8b88d19e4bc0dd51 (geode)
  5d034de588a43cdefb8fbb3a6259579785768340 (geode-examples)

Source and binary files:
  https://dist.apache.org/repos/dist/dev/geode/1.2.1.RC1

Maven staging repo:
  https://repository.apache.org/content/repositories/orgapachegeode-1021

Geode's KEYS file containing PGP keys we use to sign the release:
  
https://git-wip-us.apache.org/repos/asf?p=geode.git;a=blob_plain;f=KEYS;hb=HEAD

pub  4096R/C72CFB64 2015-10-01
  Fingerprint=948E 8234 14BE 693A 7F74  ABBE 19DB CAEE C72C FB64

Anthony

[GitHub] geode pull request #748: GEODE-3472: Remove a great deal of commented-out co...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/geode/pull/748


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] geode issue #748: GEODE-3472: Remove a great deal of commented-out code.

[PurelyApplied]

Github user PurelyApplied commented on the issue:

https://github.com/apache/geode/pull/748
  
Precheckin green.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

RE: Indxes and hints

[Roi Apelker]

One more question:

As I am trying to create a situation where the disk is accessed as least as 
possible 
(with a select distinct from X where a=1 and b>10 and c=true; 
In which a and b are indexes and c is not, and c is in the value which is 
evicted to disk)

Did I get it right - that if I use a hint on a, or a hint on b, or a hint on 
both, it will first do a select on the hinted, and ONLY THEN the others?

Can anyone refer me to the code (where the 2 phase search occurs)?

Where is the value finally loaded from disk?

Thank you

Roi
-Original Message-
From: Roi Apelker 
Sent: Tuesday, August 29, 2017 4:02 PM
To: dev@geode.apache.org
Subject: RE: Indxes and hints

Thank you Jason :-)

-Original Message-
From: Jason Huynh [mailto:jhu...@pivotal.io] 
Sent: Monday, August 28, 2017 7:24 PM
To: dev@geode.apache.org
Subject: Re: Indxes and hints

Hi Roi,

Answers are below the questions...

Question 1. Is it true to say, that the query as it is will load all the data 
values from the file, since the field C is part of the value, which is already 
persisted to file?

Depending on if an index is used or not, if an index is used, the values that 
are part of the results will need to be loaded to actually return a result.  If 
an index is not used, then the all the values would need to be loaded to 
actually have something to evaluate the filter criteria on.

Question 2. If I add a hint on A and B, will it mean that there will be a
"2 phase search", first the select on A and B, and then, only on the results, 
on the field C? (this way, not all records will be loaded from file, only those 
that suit the A and B condition)

Depending on the  query, it could use one, or more.  If it's a query with only 
AND clauses, it should just choose one and then evaluate the other filters on 
the subset that is returned from the index.

Question 3. Is it possible to define an index on a value field? (i.e. not from 
the key) - will it work exactly like defining one form the key or are three any 
limitations? (again, I am looking to overcome the situation, where as it seems, 
the records are loaded unnecessarily from disk)

Yes, indexes can be defined on fields in the value.  It will work the same.


If you are sure you are already using an index in the query and still loading 
every value for every execution of that query, there may be something weird 
going on...

On Sun, Aug 27, 2017 at 2:55 AM Roi Apelker  wrote:
This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at https://www.amdocs.com/about/email-disclaimer 

This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at https://www.amdocs.com/about/email-disclaimer 

Re: Review Request 61972: GEODE-3445: Convert connect acceptance test to DUnit test

[Ken Howe]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/61972/#review184156
---


Ship it!





geode-web/src/test/java/org/apache/geode/management/internal/cli/commands/ConnectCommandWithSSLTest.java
Line 267 (original), 264 (patched)


Spelling: "conect" corrected elsewhere, but missed this one.


- Ken Howe


On Aug. 29, 2017, 4:53 p.m., Jared Stewart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/61972/
> ---
> 
> (Updated Aug. 29, 2017, 4:53 p.m.)
> 
> 
> Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
> Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-3445: Convert connect w/ http & ssl acceptance test to DUnit test
> 
> 
> Diffs
> -
> 
>   
> geode-assembly/src/test/java/org/apache/geode/management/GfshConnectToLocatorWithSSLAcceptanceTest.java
>  75d60a32411582d75eb0f5cacce1536a6f724a26 
>   
> geode-web/src/test/java/org/apache/geode/management/internal/cli/commands/ConnectCommandWithSSLTest.java
>  7c4fb446ca4909c628010087b7c85aa121883894 
> 
> 
> Diff: https://reviews.apache.org/r/61972/diff/1/
> 
> 
> Testing
> ---
> 
> Precheckin passed
> 
> 
> Thanks,
> 
> Jared Stewart
> 
>

Re: Review Request 61974: GEODE-2859: Fix race condition in ShowDeadlockDUnitTest

[Ken Howe]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/61974/#review184151
---


Ship it!




Ship It!

- Ken Howe


On Aug. 29, 2017, 10:46 p.m., Jared Stewart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/61974/
> ---
> 
> (Updated Aug. 29, 2017, 10:46 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, Kirk Lund, 
> and Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2859: Fix race condition in ShowDeadlockDUnitTest
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ShowDeadlockDUnitTest.java
>  4df0b96 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/GfshShellConnectionRule.java
>  dc17d03 
>   geode-junit/build.gradle 7c533ad 
>   
> geode-junit/src/main/java/org/apache/geode/test/concurrent/FileBasedCountDownLatch.java
>  PRE-CREATION 
>   
> geode-junit/src/test/java/org/apache/geode/test/concurrent/FileBasedCountDownLatchTest.java
>  PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/61974/diff/2/
> 
> 
> Testing
> ---
> 
> Precheckin running
> 
> 
> Thanks,
> 
> Jared Stewart
> 
>