Re: New client/server protocol - seeking feedback

You can find them in the code, but we'll be providing better documentation on the messages shortly. The proto files have the message definitions and they're pretty straightforward, but we'll have a more user-friendly write-up soon. On Sep 15, 2017 5:27 PM, "Dan Smith" wrote:

Re: New client/server protocol - seeking feedback

What's the best place to look for more details on the specific protocol for the v1.0 messages? The other pages on https://cwiki.apache.org/ confluence/display/GEODE/New+Client+Server+Protocol? Or directly in the code somewhere? -Dan On Fri, Sep 15, 2017 at 11:15 AM, Brian Baynes

Re: [DISCUSS] Framework for concurrency tests

+1 to Dan's Changes but also +1 to Galen's suggestion. JPF looks like it might take a bit to run all the different states even for a small interleaving of code (maybe we can tune/configure it though). Or we can mark these as a different category and not run as a "UnitTest" On Fri, Sep 15, 2017

Re: [DISCUSS] Framework for concurrency tests

What? You don’t think Travis can run these fast? > On Sep 15, 2017, at 2:07 PM, Galen O'Sullivan wrote: > > +1 This is great! I'll take a look at your PR when I get the time. > > We may want to think carefully about how often we run these tests, because > unlike regular

Re: [DISCUSS] Framework for concurrency tests

+1 This is great! I'll take a look at your PR when I get the time. We may want to think carefully about how often we run these tests, because unlike regular unit tests, they will take forever to run. On Fri, Sep 15, 2017 at 1:42 PM, Michael William Dodge wrote: > +1 for unit

Re: [DISCUSS] Framework for concurrency tests

+1 for unit tests for multithreaded code. High fives to Dan. Sarge > On 15 Sep, 2017, at 12:08, Dan Smith wrote: > > Hi Geode devs, > > I've been messing around with an open source tool called Java > Pathfinder for writing tests of multithreaded code. Java Pathfinder is >

Re: [DISCUSS] Clean build takes 10minutes to complete now

I think that the moving the old version out of the compilation step is paramount. Could the download of the artifact be made a dependency of the BackwardCompatibilityTest? --Udo On Fri, Sep 15, 2017 at 1:08 PM, Jason Huynh wrote: > For the original issue, where the old

Re: 1.3.0 release

I took preliminary look and tagged some issues for 1.3.0. Looks like we have 11 issues remaining: https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=92=GEODE=planning=GEODE-2788=visible=12340669 Please take a look at these issues to see which are not critical to fix in 1.3 and also

Re: [DISCUSS] Clean build takes 10minutes to complete now

For the original issue, where the old version is pulling down the old versions during compilation time, we have a pull request to use the maven repo: https://github.com/apache/geode/pull/790 The rest of the tests added for the session state are marked as @Category ({DistributedTest.class,

Re: [DISCUSS] Framework for concurrency tests

Love it! See my comments in your pull request. On Fri, Sep 15, 2017 at 12:08 PM Dan Smith wrote: > Hi Geode devs, > > I've been messing around with an open source tool called Java > Pathfinder for writing tests of multithreaded code. Java Pathfinder is > a special JVM which

[DISCUSS] Framework for concurrency tests

Hi Geode devs, I've been messing around with an open source tool called Java Pathfinder for writing tests of multithreaded code. Java Pathfinder is a special JVM which among other things tries to execute your code using all possible thread interleavings. I'd like to propose two things: 1) We

New client/server protocol - seeking feedback

Greetings, friends of Geode. Work has been progressing on the new client/server protocol for Geode and we're approaching a GA v1.0. Completed work/features include put/get, putAll, getAll, remove, one-way SSL, authentication and authorization, and support for primitive types and JSON documents

Re: [Vote] virtual void fromData(PdxReaderPtr input) to virtual void fromData(const PdxReaderPtr input);

PdxReader advances the cursor of the internal buffer on each call. If we consider that each call moves the cursor to the requested field position we could make the cursor mutable but we also need to specify that all accessor fields are const as well. If we do this then I could support the

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

+1 for: std::string toString() const noexcept; On Fri, Sep 15, 2017 at 10:52 AM Jacob Barrett wrote: > On Fri, Sep 15, 2017 at 10:50 AM Ernest Burghardt > wrote: > >> Not convinced or grok'g doing both... what is the benefit of adding the >>

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

okay so we have +1s on object.toString() any dissenting opinions? On Fri, Sep 15, 2017 at 11:52 AM, Jacob Barrett wrote: > On Fri, Sep 15, 2017 at 10:50 AM Ernest Burghardt > wrote: > > > Not convinced or grok'g doing both... what is the benefit of

Re: [Vote] virtual void fromData(PdxReaderPtr input) to virtual void fromData(const PdxReaderPtr input);

Readers do in fact hold state, but they do not appear to modify the state during normal reads. I could be wrong on that, but that is what I just read. Thanks, Mark > On Sep 15, 2017, at 10:51 AM, Jacob Barrett wrote: > > -1 > > PdxReader holds state. All calls to read

Re: [Vote] virtual void fromData(PdxReaderPtr input) to virtual void fromData(const PdxReaderPtr input);

+1 for const PdxReader - remember, vote early and vote often... On Fri, Sep 15, 2017 at 11:40 AM, Mark Hanson wrote: > Note the const on PdxReaderPtr virtual void fromData(const PdxReaderPtr > input); > > Hi All, > > So there is a question outstanding about whether or not

Re: [Vote] virtual void fromData(PdxReaderPtr input) to virtual void fromData(const PdxReaderPtr input);

-1 PdxReader holds state. All calls to read the state on PdxReader also result in a change in that state. On Fri, Sep 15, 2017 at 10:40 AM Mark Hanson wrote: > Note the const on PdxReaderPtr virtual void fromData(const PdxReaderPtr > input); > > Hi All, > > So there is a

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

Not convinced or grok'g doing both... what is the benefit of adding the std::to_string()'s? On Fri, Sep 15, 2017 at 11:46 AM, Jacob Barrett wrote: > On Fri, Sep 15, 2017 at 10:33 AM Mark Hanson wrote: > > > class blobject > > { > > bool blobBool; > >

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

My vote is unchanged… +1 for on the object. Thanks, Mark > On Sep 15, 2017, at 10:47 AM, Jacob Barrett wrote: > > On Fri, Sep 15, 2017 at 10:40 AM David Kimura wrote: > >> Actually, it looks like Jake is right. According to documentation it's >>

Re: [DISCUSS] authorizing function execution

Yeah that's the right level of authorization. The Function Author should get to decide. Listeners, Loaders and Writers should only require DATA:READ and DATA:WRITE as appropriate. It is up to the authors what they do inside of those. -- Mike Stolz Principal Engineer, GemFire Product Manager

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

On Fri, Sep 15, 2017 at 10:40 AM David Kimura wrote: > Actually, it looks like Jake is right. According to documentation it's > undefined behavior since it's not a template specialization. > > http://en.cppreference.com/w/cpp/language/extending_std > > Oh yeah, I know I

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

On Fri, Sep 15, 2017 at 10:33 AM Mark Hanson wrote: > class blobject > { > bool blobBool; > }; > > > namespace std { > std::string to_String(blobject * blob) > { > return std::string("works"); > } > } > > > int main() { > > blobject * blob = new

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

Actually, it looks like Jake is right. According to documentation it's undefined behavior since it's not a template specialization. http://en.cppreference.com/w/cpp/language/extending_std Thanks, David On Fri, Sep 15, 2017 at 10:37 AM, Ernest Burghardt wrote: > cool

[Vote] virtual void fromData(PdxReaderPtr input) to virtual void fromData(const PdxReaderPtr input);

Note the const on PdxReaderPtr virtual void fromData(const PdxReaderPtr input); Hi All, So there is a question outstanding about whether or not we want to add const to PdxReaderPtr for fromData calls. It seems reasonable and plausible. Proposal: Change to virtual void fromData(const

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

cool that we could export into the std namespace, but as a library I don't think it is a good idea as a user of our library might have done the same thing and that is a situation we can easily/pro-actively avoid +1 object::toString() On Fri, Sep 15, 2017 at 11:33 AM, Mark Hanson

Re: 1.3.0 release

Excellent! Can you review the open issues currently tagged for 1.3.0 (I think it’s probably not accurate) and gather consensus on any remaining changes needed? Anthony > On Sep 12, 2017, at 2:40 PM, Swapnil Bawaskar wrote: > > Sound good. > > I would like to volunteer

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

Comments inline…. > On Sep 15, 2017, at 10:25 AM, Jacob Barrett wrote: > > -1 to all, comments below. > > >> On Sep 15, 2017, at 10:18 AM, Mark Hanson wrote: >> >> So we have two approaches as their has been a veto on w_string, so it will >> not be

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

+1 for Approach 1 based on the fact that it will have a compile error if you don’t implement it, and it is more object oriented. Thanks, Mark > On Sep 15, 2017, at 10:18 AM, Mark Hanson wrote: > > So we have two approaches as their has been a veto on w_string, so it will >

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

+1 Approach 1) std::string str = object.to_string(); On Fri, Sep 15, 2017 at 11:18 AM, Mark Hanson wrote: > So we have two approaches as their has been a veto on w_string, so it will > not be used. > > Approach 1) std::string str = object.to_string(); > Approach 2)

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

So we have two approaches as their has been a veto on w_string, so it will not be used. Approach 1) std::string str = object.to_string(); Approach 2) std::string str = std::to_string(object); Please vote of your preferred. Thanks, Mark > On Sep 14, 2017, at 12:29 PM, Jacob Barrett

Re: [DISCUSS] Clean build takes 10minutes to complete now

The actual tests marked with UnitTest category are actually pretty good. They all run in just over one minute and almost all of them use Mockito to isolate one class. I remember seeing one newer Lucene UnitTest that touches File System which should be recategorized as IntegrationTest. If we could

Re: [DISCUSS] Clean build takes 10minutes to complete now

I fully agree with Udo here. The main build should be for Unit tests. Our "Unit Tests" are already exercising much more of the system than they should. Adding unit tests that not only too much or our current code but also old code is moving us in the wrong direction. Let's keep the tests, but

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

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

Build failed in Jenkins: Geode-nightly #955

See Changes: [lgallinat] GEODE-3185: Fixes CI failures in windows in [khowe] GEODE-3615: Added CleanupDUnitVMsRule to ConnectCommandWithSSLTest [bschuchardt] GEODE-3083: New protocol should record statistics