Jenkins build is back to normal : Geode-release #90

See

Re: [DISCUSS] Addition of isValid API to Index interface

Thanks you guys for the review. I will revert the GEODE-3520 ticket to reflect that invalidate should happen for both synchronous and asynchronous index maintenance. Also, I will resend the PR which reflects the changes mentioned in the ticket Regards Nabarun Nag On Thu, Sep 14, 2017 at 5:55

Re: [DISCUSS] geode-native c++ exceptions

Ok, I feel like we are all on the same page now, right? As reasonably possible throw library specific exceptions from all public methods. No exception should directly extend any non-library exception, like std exceptions. All Exceptions shall not use multi-inheritance. All exceptions should rea

Re: [Discuss] Investigation of C++ object return types

Y'all here is an attempt to get the best of both worlds. https://gist.github.com/pivotal-jbarrett/52ba9ec5de0b494368d1c5282ef188ef I thought I would try posting to Gist but so far not impressed, sorry. The Gist of it is that we can overcome the thirdpary or transient reference back to the public

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

--- Spring Data GemFire > Nightly-ApacheGeode > #678 was successful. --- Scheduled 2044 tests in total. https://build.spring.io/browse/SGF-NAG-678/ -- This

Re: [Discuss] Investigation of C++ object return types

Late to this party. Confession 1: I had to look up both RVO and copy-elision. Confession 2: I don't like using pointers at all. I used to, but I've evolved to just use C# and Java :) Without investing a lot more time, I don't have strong feelings about raw vs shared pointers. My only question is:

Re: [DISCUSS] Addition of isValid API to Index interface

Dan, you are right...Thanks to Jason, myself and Jason looked into the code to see if index is updated before the event/change is saved/injected into the region...It looks like the index update are happening after the region change/update is saved. Moving the index update before that is not an easy

Re: [Discuss] Investigation of C++ object return types

+0 shared pointer > On 14 Sep, 2017, at 14:09, Ernest Burghardt wrote: > > Calling a vote for: > > - Raw pointer > - shard pointer > > +1 raw Pointer, I had to look up RVO and am new to std::move(s) > > On Thu, Sep 14, 2017 at 3:02 PM, Michael William Dodge > wrote: > >> I generally dig ref

Re: [DISCUSS] geode-native c++ exceptions

+1 for avoiding multiple inheritance > On 14 Sep, 2017, at 14:23, Ernest Burghardt wrote: > > Sounds like the proposal currently stands to avoid the DiamondOfDeath or > TriangleOfLove that multiple inheritance brings us > and just have the base Exception class inherit std::exception and exte

Re: [DISCUSS] geode-native c++ exceptions

Sounds like the proposal currently stands to avoid the DiamondOfDeath or TriangleOfLove that multiple inheritance brings us and just have the base Exception class inherit std::exception and extend Exception class as appropriate within the library. +1 and thanks for the code examples, very ill

Re: [Discuss] Investigation of C++ object return types

Calling a vote for: - Raw pointer - shard pointer +1 raw Pointer, I had to look up RVO and am new to std::move(s) On Thu, Sep 14, 2017 at 3:02 PM, Michael William Dodge wrote: > I generally dig reference-counted pointers for avoiding lifetime issues > with objects allocated off the heap but I

Re: [DISCUSS] Change signature of Serializable::fromData on Geode-Native

+1 for the void return type > On 14 Sep, 2017, at 13:39, Ernest Burghardt wrote: > > +1 cleans up the public API and code using this as you can see in the > proposed changes on Jake's fork > > On Wed, Sep 13, 2017 at 3:30 PM, Jacob Barrett wrote: > >> I would like to propose a change: >>

Re: [Discuss] Investigation of C++ object return types

I generally dig reference-counted pointers for avoiding lifetime issues with objects allocated off the heap but I can live with bare pointers, too. Sarge > On 13 Sep, 2017, at 16:25, Mark Hanson wrote: > > Hi All, > > I favor the “pointer" approach that is identified in the code sample. There

Re: [DISCUSS] Change signature of Serializable::fromData on Geode-Native

+1 cleans up the public API and code using this as you can see in the proposed changes on Jake's fork On Wed, Sep 13, 2017 at 3:30 PM, Jacob Barrett wrote: > I would like to propose a change: > Serializable* Serializable::formData(DataInput& in) > to > void Serializable::formData(DataInput&

Re: [DISCUSS] Addition of isValid API to Index interface

I'm still going to push that we stick with Naba's original proposal. The current behavior is clearly broken. If one index update fails, an exception gets thrown to the user (nice!) but it leaves the put in a partially completed state - some other indexes may not have been updated, WAN/AEQs may not

Re: [Discuss] Moving away from virtual CacheableStringPtr toString() for Serializable objects in debug and logging to std::string and std::wstring

Don't use std::wstring EVER. The std::wstring has a platform dependent storage class. This means on Windows it is 32bits and Linux it is 16bits. None of the std::string types, and there are more than std::wstring, define an encoding, so would the wstring be UTF-16, UC-2, UTF-32, UC-4, or some other

Re: [Discuss] Moving away from virtual CacheableStringPtr toString() for Serializable objects in debug and logging to std::string and std::wstring

On Thu, Sep 14, 2017 at 11:10 AM Mark Hanson wrote: > if (pdxser->isWideString()) { >std::cout << " query idx “ << i << "pulled object ” << > pdxser->toWString() << std::endl; > } else { >std::cout << " query idx “ << i << "pulled object ” << > pdxser->toString() << std::endl; > } > How

Re: Review Request 62339: Will this preserve backwards compat?

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/62339/#review185442 --- geode-core/src/main/java/org/apache/geode/security/ResourcePermis

Re: [DISCUSS] GEODE-3617 Replace gemfire prefix with geode

There are plenty of places besides DistributionConfig that use "gemfire" prefixed system properties and there are now also places that use "geode" prefixed system properties.  I think the whole mess needs to be managed and allow either prefix, or even as someone suggested making it plug-able. 

Review Request 62339: Will this preserve backwards compat?

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/62339/ --- Review request for geode. Repository: geode Description --- Will this pr

Re: [Discuss] Moving away from virtual CacheableStringPtr toString() for Serializable objects in debug and logging to std::string and std::wstring

Seems like a good idea. Here's a quick thought - I think c++11 is not really an obj.toString() kind of language (like Java or C#). Would it make sense to add std::to_string() and std::to_wstring() equivalents for CacheableString? This might mean implementing following functions: std::string

Re: [DISCUSS] authorizing function execution

Indeed, the function author has a higher level of privilege than someone who is invoking a function, that is why the proposal here is to let the function author choose what level of permissions are required to invoke a function. On Thu, Sep 14, 2017 at 11:20 AM Anilkumar Gingade wrote: > >> from

Re: [DISCUSS] authorizing function execution

>> from reaching into internal classes If thats the case; one could do anything, even with read permission...Isn't it... On Thu, Sep 14, 2017 at 10:43 AM, Jared Stewart wrote: > There is nothing to prevent code in a function that's executing on a > server from reaching into internal classes an

Re: [Discuss] Moving away from virtual CacheableStringPtr toString() for Serializable objects in debug and logging to std::string and std::wstring

+1 for std::string and std::wstring. Sarge > On 14 Sep, 2017, at 11:10, Mark Hanson wrote: > > Hi All, > > I wanted to broach the subject of moving away from moving away from > CacheableStringPtrs for the toString representation of Serializable. It would > seem desirable to move to std::stri

[Discuss] Moving away from virtual CacheableStringPtr toString() for Serializable objects in debug and logging to std::string and std::wstring

Hi All, I wanted to broach the subject of moving away from moving away from CacheableStringPtrs for the toString representation of Serializable. It would seem desirable to move to std::string and std::wstring to use more basic types that would be faster to log and the code would be simpler for

Re: RestServersJUnitTest flickering tests

Please don't forget that we are NOT supposed to ignore failures in FlakyTest. That was never the intention of FlakyTest. The intention was this: 1) run the test under a testing target that ALWAYS forks (or forks every 30 distributed test cases) -- this was enough to stabilize many of these flicker

Re: [DISCUSS] authorizing function execution

There is nothing to prevent code in a function that's executing on a server from reaching into internal classes and bypassing the public region APIs. I think a function's author should ultimately determine the permissions required to execute it. > On Sep 14, 2017, at 10:34 AM, Anilkumar Ging

Re: [DISCUSS] authorizing function execution

When a function is accessing/modifying region; the function will be doing so by region apis, don't we have credential check with region apis; if not can we add those checks here...instead of having it in the function... -Anil. On Wed, Sep 13, 2017 at 11:22 AM, Jared Stewart wrote: > After som

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

Cancelling due to problems in the source distributions (the official release bits). Anthony > On Sep 11, 2017, at 2:03 PM, Anthony Baker wrote: > > This is the third release candidate for Apache Geode, version 1.2.1. > Thanks to all the community members for their contributions to this > relea

Re: RestServersJUnitTest flickering tests

These problems stem from a dirty testing environment occupying the default port, which this test wants to use. I have a pull request open to ignore the test when the default port is not available. On the one hand, an ignored test is essentially dead code. If the test is consistently skipped and

Re: [DISCUSS] GEODE-3617 Replace gemfire prefix with geode

+1 to having DistributionConfig look for both the "gemfire." and "geode." prefixes. +1 to having DistributionConfig look for both a "gemfire.properties" and "geode.properties" file. Since the geode flavors are newer it should look for them first and only look for the old gemfire flavor if a geode o

Re: [DISCUSS] GEODE-3617 Replace gemfire prefix with geode

That's a bigger change and I'm not sure how you would handle backwards compatibility for users using gemfire.properties. On Thu, Sep 14, 2017 at 9:15 AM, Jacob Barrett wrote: > Or better yet, we stop using properties files already. > > On Thu, Sep 14, 2017 at 8:55 AM Dave Barnes wrote: > > > Is

Re: [DISCUSS] GEODE-3617 Replace gemfire prefix with geode

Or better yet, we stop using properties files already. On Thu, Sep 14, 2017 at 8:55 AM Dave Barnes wrote: > Is there a possibility that the code might find its way into additional > contexts with other names? If so, perhaps we should consider a more generic > identifier, such as PRODUCT_PREFIX.

Re: [DISCUSS] GEODE-3617 Replace gemfire prefix with geode

Whoever takes this work on will need to spend time figuring out a way to make it pluggable and support multiple prefixes possibly with pluggable order of preference. For example, we would need to support looking for geode.properties and gemfire.properties or it would break backwards compatibility f

Re: [DISCUSS] geode-native c++ exceptions

The problem stems from the fact that none of the std exceptions virtually inherit from std::exception so you end up in the inheritance triangle of love. I say we avoid the multiple inheritance issues with exceptions by avoiding multiple inheritance altogether in exceptions. See this example. http:/

Re: [DISCUSS] GEODE-3617 Replace gemfire prefix with geode

Is there a possibility that the code might find its way into additional contexts with other names? If so, perhaps we should consider a more generic identifier, such as PRODUCT_PREFIX. On Thu, Sep 14, 2017 at 4:42 AM, Dinesh Akhand wrote: > Hi, > > Why we are keeping gemfire in current geode 1.2

RestServersJUnitTest flickering tests

These tests have been failing intermittently in the integrationTest target for over a week. I'm going to add the category FlakyTest to these tests. See GEODE-3426. org.apache.geode.rest.internal.web.RestServersJUnitTest > testGet FAILED org.junit.ComparisonFailure: expected:<[200]> but was:<[4

Build failed in Jenkins: Geode-nightly #954

See Changes: [github] GEODE-3580: patch test to avoid the current failure. (#774) [github] GEODE-3579 Update gfsh stop locator docs (#765) [jstewart] GEODE-3544: Fix JSON parsing error [jstewart] Update javadoc fo

[DISCUSS] GEODE-3617 Replace gemfire prefix with geode

Hi, Why we are keeping gemfire in current geode 1.2 , Can we replace this with GEODE File : DistributionConfig.java Current code: String GEMFIRE_PREFIX = "gemfire."; Suggestion to change: String GEODE_PREFIX = "geode."; Why do you think ? Can we go ahead and change this ? It will impact lot