Re: [Proposal] Changes to the experimental cluster configuration API.

Perhaps org.apache.geode.DataSerializable or org.apache.geode.internal.DataSerializableFixedID instead of java.io.Serializable? Sarge > On 19 Apr, 2018, at 17:04, Patrick Rhomberg wrote: > > E) Every cluster configuration object should be Serializable so that the >

Re: [Proposal] Gfsh Command Feature Flag Annotation

I kind of like @Disabled instead. Sarge > On 19 Mar, 2018, at 11:58, Udo Kohlmeyer wrote: > > I wonder if this proposal could not be extended to the greater GEODE product. > As this feature flagging is also relevant to other parts of the system and > should maybe be

Re: Default branch for geode-examples repo

I vote for changing the default branch to develop. Sarge > On 2 Jan, 2018, at 10:05, Alexander Murmann wrote: > > I noticed that many recent commits in the geode-examples repo have been > merged to develop, but not master. Will those be merged to master at some > point or

Re: Discussion: Native PDX Reader/Writer std::string

Of those, #1 seems better than #2 and #3. Is there an elegant way to use a sentinel value of std::string to represent null, e.g., static const PdxReader::NULL_STRING = ? Sarge > On 19 Dec, 2017, at 13:34, Jacob Barrett wrote: > > Java String is an object and as such a

Re: DISCUSS: Deprecating and replacing current serializable string encodings

I think there is value in having a single string encoding. Sarge > On 1 Dec, 2017, at 17:35, Jacob Barrett wrote: > > On Fri, Dec 1, 2017 at 4:59 PM Dan Smith wrote: > >> I think I'm kinda with Mike on this one. The existing string format does >> seem

Re: Next release: 1.4.0

What sort of update? I know that GEODE-4010 has a PR that's awaiting review and merge. Sarge > On 28 Nov, 2017, at 10:03, Swapnil Bawaskar wrote: > > I would like to volunteer as a release manager. > Currently there are 14 issues that are marked for 1.4.0. If you are

Re: Permissions To View Builds?

s://builds.apache.org/job/Geode-nightly/ > > On Tue, Nov 7, 2017 at 12:35 PM, Michael William Dodge <mdo...@pivotal.io> > wrote: > >> I tried to check on the nightly builds via https://builds.apache.org/ >> jobs/Geode-nightly/ <https://builds.apache.org/jobs/Geod

Permissions To View Builds?

I tried to check on the nightly builds via https://builds.apache.org/jobs/Geode-nightly/ . I think that's the right URL but I get an error message that says "Invalid login information. Please try again.". If that's the right URL, may I have

Re: Consistent results from gfsh commands

+1 for consistency! Sarge > On 31 Oct, 2017, at 07:59, Jens Deppe wrote: > > Hi, > > I've noticed that various commands, that execute on multiple members, > return either tabulated results (one line per member - for example > CreateRegionCommand) or a single pass/fail

Re: [Discussion] Native - Should C++ client support wchar_t type?

I think support for wchar_t adds unnecessary complexity and should be removed. Sarge > On 26 Oct, 2017, at 13:05, Jacob Barrett wrote: > > I think we should get rid of it. There are plenty of discussions out there > around C++ strings and how they relate to Unicode. Wide

Re: [Discussion] Native - Dropping exceptions from Region::getAll

+1 for dropping the exceptions map for symmetry with the Java API Sarge > On 23 Oct, 2017, at 09:32, Jacob Barrett wrote: > > As part of our decision to replace all function out variables with return > values we ran into an interesting function with Region::getAll. That >

Re: [Discuss] CliStrings

+1 for removing it based on Dan's reasoning. Sarge > On 20 Oct, 2017, at 13:59, Dan Smith wrote: > > +1 for removing it. > > I do think it would be nice if we add localization in the future. But > I don't really like the idea of leaving stuff in our code just in case > we

Re: [VOTE] C++ standardize on return values only

I have seen the uint8_t *, uint32_t tuple mostly with C-style system level calls (e.g., reading from a resource). Perhaps these could be allowed to remain as part of lowering impedance with a legacy API. Sarge > On 18 Oct, 2017, at 15:08, Mark Hanson wrote: > > Sorry

Re: [VOTE] Apache Geode release - 1.3.0 RC2

If we are including geode-examples, there are six PRs outstanding for geode-examples. Sarge > On 15 Oct, 2017, at 20:51, Anthony Baker wrote: > > -1 > > The geode-examples source should be included in this release. > > The download task in the geode-examples build also

Re: [DISCUSS] C++ Returning null values

To me the question of a no-op region comes down to whether customers would need to do logic based on whether a region has a parent. If they do, perhaps a bool hasParent() along with getParent() returning a no-op region would be an elegant solution. If they do not, then shared_ptr is probably

Re: [VOTE] C++ standardize on return values only

+1 for the tuple > On 4 Oct, 2017, at 08:01, Ernest Burghardt wrote: > > +1 Tuple > > On Wed, Oct 4, 2017 at 7:58 AM, David Kimura wrote: > >> +1 >> >> On Tue, Oct 3, 2017 at 5:45 PM, Hitesh Khamesra >> >> wrote: >>

Re: New client/server protocol - seeking feedback

From my days using Win32 APIs, I think fixing Foo() with FooEx() is an anti-pattern. But that's not to say that "version 37 fixes the parameters to Foo() and in no other way changes anything" is any better. I see the version as useful for determining the structure of the protocol, not the

Re: [DISCUSS] Removal of "Submit an Issue" from Geode webpage

+1 to improving the signal-to-noise ratio > On 29 Sep, 2017, at 11:07, Jason Huynh wrote: > > GEODE-3280

Re: [DISCUSS] Using out parameters and its effects on function overload resolution

I like the idea of using non-const references for in-out parameters only and using tuples for the cases where there are multiple out parameters. Yes, the return type does not participate in overload resolution but I don't think there would be many cases where that would be an issue. (But I

Re: [Vote] Better type checking by moving PdxWrapper from a standard class to a template class.

+1 for type safety Sarge > On 21 Sep, 2017, at 10:21, Mark Hanson wrote: > > Here is a link to my branch in my fork that has the changes on it. > > https://github.com/mhansonp/geode-native/tree/wip/templatePdxWrapper > > Thanks, > Mark > > On Thu, Sep 21, 2017 at 10:19

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] Investigation of C++ object return types

+0 shared pointer > On 14 Sep, 2017, at 14:09, Ernest Burghardt <eburgha...@pivotal.io> 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

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

it is that >>>> the code can be as simple or as complex as it can be without unnecessary >>>> overhead e.g error => network error => tcp error. So, I may just care >> there >>>> is a network error and the being able to tell if something derives from >>>

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

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

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

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

I subscribe to Josh Gray's philosophy of only having another exception class if there is something different to be done when it's caught. For example, if the caller would do the exact same thing for NoPermissionsException and DiskFullException, just use an IOException and be done with it. I

Re: [Discuss] What type should C++ object creation functions return?

I like just returning the object as that removes the possibility of a null pointer. Sarge > On 6 Sep, 2017, at 12:27, David Kimura wrote: > > What type should C++ object creation functions return (e.g. pointer, smart > pointer, reference, etc.)? Several of our C++ API's

Re: git repo is gone

Can non-committers use the ssh protocol, too? Sarge > On 1 Sep, 2017, at 14:37, Jens Deppe wrote: > > TL;DR - Remove references to > https://git-wip-us.apache.org/repos/asf/geode.git and replace/add ssh:// > g...@github.com/apache/geode.git > > In my environment this is

Re: [DISCUSS] authorizing function execution

What about an annotation for read-only functions or a subinterface off org.apache.geode.cache.execute.Function? Sarge > On 17 Aug, 2017, at 01:42, Swapnil Bawaskar wrote: > > Discuss fix for GEODE-2817 > > > Currently

Re: ACTION REQUIRED: geode-native has moved

Does this affect a pre-existing fork? Sarge > On 16 Aug, 2017, at 07:24, Jacob Barrett wrote: > > Devs, > > The geode-native repo has moved to GitHub utilizing the Apache GitBox > service. > > For contributors nothing really changes, the repo is still at >

Re: []DISCUSS] Using package names to identify public API's

The user shouldn't need to access any of the protobuf classes directly. I'm in favor of making all of the protobuf-related packages internal, including any classes generated from .proto files. Sarge > On 11 Aug, 2017, at 11:30, Anthony Baker wrote: > > We have policies in

Re: New Committer And PMC Member: Joey McAllister

Welcome, Joey! Sarge > On 25 Jul, 2017, at 11:58, Mark Bretl wrote: > > The Apache Geode Project Management Committee has invited Joey McAllister to > be committer on the project and join the Geode PMC. We are pleased to > announce he has accepted. > > Please join me in

Re: PING message is "Mischief Managed"

+1 for "pong". > On 13 Jul, 2017, at 13:45, Kirk Lund wrote: > > I'm really boring... I would've just had it reply "PONG" ;) > > On Thu, Jul 13, 2017 at 11:57 AM, John Blum wrote: > >> Here you go... >> >>

Re: What to do with the geode-spark-connector

+1 for A > On 24 May, 2017, at 21:30, Jared Stewart wrote: > > +1 for A > > On May 24, 2017 6:48 PM, "Kirk Lund" wrote: > >> +1 for A >> >> On Wed, May 24, 2017 at 5:50 PM, Jianxia Chen wrote: >> >>> I prefer option A: Move it into

Re: Simple Java Client

I like the idea of a separate code base (including repo) for separate problem domains. I think trying to fit a new API inside or parallel to the existing API has too high of a likelihood of confusion. Sarge > On 26 Apr, 2017, at 16:52, Bruce Schuchardt wrote: > > I

Re: Simple Java Client

Perhaps I'm picking nits, but I think a library that provides an API for interacting with Geode isn't a client. (I like to call it a driver.) The client is the application that someone write to use that API to interact with Geode. I recognize that in the past the C++ library for Geode has been

Re: Why we shouldn't use RPC Frameworks for the New Geode Protocol

MQTT is an interesting idea but from the wiki page it sounds like it depends on a broker. In that architecture, would the server be the broker as well as a publisher and subscriber? Would the locator be the broker? Or would we introduce a separate broker, either third-party or bespoke? Sarge

Re: Client Commands and SecurityService

+1 to modular and questioning non-constant use of static > On 3 Apr, 2017, at 09:27, Anthony Baker wrote: > > Using singletons leads to very monolithic systems that are hard to test and > hard to change. Instead we should prefer modular services like Udo proposed. > > I

Re: Wait on macOS 10.12.4 and Xcode 8.3

With Dave Barnes' help, we have determined that Xcode 8.3 is the problem. If you have already upgraded to Xcode 8.3, you can rollback to Xcode 8.2.1 to restore functionality. Sarge > On 29 Mar, 2017, at 15:25, Michael William Dodge <mdo...@pivotal.io> wrote: > > With the

Re: Wait on macOS 10.12.4 and Xcode 8.3

GEODE-2733 > On 29 Mar, 2017, at 19:44, Jacob Barrett <jbarr...@pivotal.io> wrote: > > Can you please open a JIRA so we can track this issue, should it require an > update to ACE or our own sources. > > Thanks, > Jake > > On Wed, Mar 29, 2017 at 3:25 PM Michael

Wait on macOS 10.12.4 and Xcode 8.3

With the recent upgrade to macOS 10.12.4 and Xcode 8.3, we're seeing a SIGSEGV/EXC_BAD_ACCESS with pthread_mutex_lock() which is part of the initialization of the ACE libraries. I haven't done enough debugging to know whether it's caused by an incompatibility between ACE and the 10.12.4

Re: Permission to Edit and Comment

Thanks! > On 29 Mar, 2017, at 12:16, William Markito Oliveira > <william.mark...@gmail.com> wrote: > > You should be good to go now Sarge... :) > > On Wed, Mar 29, 2017 at 1:19 PM, Michael William Dodge <mdo...@pivotal.io> > wrote: > >> May I have

Permission to Edit and Comment

May I have the necessary permissions such that I can edit and comment on wiki articles under https://cwiki.apache.org/confluence/display/GEODE/ ? Thanks. Sarge

Re: Building geode-native for release

Can we not just use http://geode.apache.org/schema/cache/cache-1.0.xsd which is already there? Sarge > On 6 Mar, 2017, at 09:56, Anthony Baker wrote: > > 2) Schema > > We need to move gfcpp-cache-9.0.xsd to

Re: [GitHub] geode-native issue #44: GEODE-2578: Remove 64 KiB limit on query strings.

They didn't for me before I committed the code. Let me try them again. > On 6 Mar, 2017, at 08:03, pivotal-jbarrett wrote: > > Github user pivotal-jbarrett commented on the issue: > >https://github.com/apache/geode-native/pull/44 > >@PivotalSarge looks like some

Re: C++ Style

* Variable Naming - I agree that lowercase-first camelCase is more readable and preferable for variable and data member names. Since class names are uppercase-first CamelCase, underscores should not be used. And alllowercase is unreadable. * Class Data Members - Any sort of Hungarian notation,

Re: [GitHub] geode-native pull request #13: GEODE-2476: Replace gfcpp with geode.

I've modified PR #13 to remove the vestigial executable and to elide the duplicate GEODE_ in the legacy include guards. Sarge > On 17 Feb, 2017, at 11:06, pivotal-jbarrett wrote: > > Github user pivotal-jbarrett commented on a diff in the pull request: > >

Re: Requesting more JIRA permission

+1 > On 15 Feb, 2017, at 16:17, Addison Huddy wrote: > > Hello Apache Geode Community, > > I'm writing to request a higher level of permission on JIRA tickets in an > effort to increase organization and clarity within our community. > > As we grow our community and focus

Re: Voting Process

+0.9 :) > On 15 Feb, 2017, at 14:48, Anthony Baker wrote: > >> >> On Feb 15, 2017, at 2:40 PM, Mark Bretl wrote: >> >> Hi, >> >> Now that we are a top-level project, we need to make sure votes are counted >> correctly, according to the Apache Voting

Re: PROXY and CACHING_PROXY regions on Client

I agree with Mike that whatever changes in behavior are made to the Java client library should also be made in the C++ and C# libraries. Sarge > On 15 Feb, 2017, at 08:02, Michael Stolz wrote: > > I have strong fears that if we make these wholesale changes to existing >

Re: [DISCUSS] JIRA guidelines

+1 > On 14 Feb, 2017, at 20:50, William Markito Oliveira > wrote: > > +1 > > Finally!! ;) > > Sent from my iPhone > >> On Feb 14, 2017, at 7:59 PM, Galen M O'Sullivan >> wrote: >> >> +1 to the article and removing the draft label >> >>>

Re: C++ client change history

I'm not sure exactly what happened as my git fu isn't that great but could it be as part of commit 4fa64db926f51d4b12d6e4040c703cc69a9832fe? In that commit I see a block under case TcrMessage::PING: being removed so that execution falls through to default: but I'm unsure that I've pieced the

Re: Automating docker builds for geode-native

I think this would be a good idea as configuring a machine for building can be a barrier to entry for people wishing to contribute. Sarge > On 10 Feb, 2017, at 12:29, Anthony Baker wrote: > > The geode-native build, like most c++ projects, requires a fairly specific >

Re: [GitHub] geode pull request #391: GEODE-2422: Switch remaining GemFire strings to Geo...

I filed a separate JIRA for this as there is no geode.jar and KillJavaProcesses() will not work correctly. > On 8 Feb, 2017, at 14:47, dgkimura wrote: > > Github user dgkimura commented on a diff in the pull request: > >

Re: Contributor Permissions in Jira

It could very well be pilot error but I could swear I'm seeing some of the buttons (like "Resolve Issue") come and go. But it's working for now. Thanks. Sarge > On 7 Feb, 2017, at 14:46, Michael William Dodge <mdo...@pivotal.io> wrote: > > As I'm working on th

Re: Contributor Permissions in Jira

PivotalSarge > On 7 Feb, 2017, at 14:57, Dan Smith <dsm...@pivotal.io> wrote: > > Hi Sarge, > > What's your JIRA username? > > -Dan > > On Tue, Feb 7, 2017 at 2:46 PM, Michael William Dodge <mdo...@pivotal.io> > wrote: > >> As I'm working on

Contributor Permissions in Jira

As I'm working on the native code, may I have contributor permission in Jira so that I may resolve things that I've fixed. Thanks. Sarge

Re: gfsh over http & authentication

A rule I've heard for UX is that anything over 200 ms is noticeable and anything over 2 s is slow. Unless polling every 500 ms is causing problems, it might be best to leave it at 500 ms as a decent compromise between efficiency and responsiveness. Sarge > On 2 Feb, 2017, at 12:04, John Blum

Re: Wrapping up: repos and versions

+1 for "geode-native". > On 31 Jan, 2017, at 10:19, Jacob Barrett wrote: > > May I suggest the repo be "geode-native" please. > > On Tue, Jan 31, 2017 at 10:18 AM Anthony Baker wrote: > >> In a few recent email threads [1] [2] [3] we discussed repos

Re: Geode Native Library Filenames

t; Mobile: 631-835-4771 > On Jan 23, 2017 11:29 AM, "Michael William Dodge" <mdo...@pivotal.io> wrote: > >> +1 for apache-geode and Apache.Geode >> >>> On 22 Jan, 2017, at 19:08, Ernest Burghardt <eburgha...@pivotal.io> >> wrote: >>>

Re: Geode Native Library Filenames

+1 for apache-geode and Apache.Geode > On 22 Jan, 2017, at 19:08, Ernest Burghardt wrote: > > +1 for apache-geode (.dll, .so, .dylib) and Apache.Geode.dll > > On Sun, Jan 22, 2017 at 7:18 AM, Michael Martell > wrote: > >> +1 for apache-geode (.dll,

Re: Native client build fails linking shared library?

io > <mailto:jbarr...@pivotal.io>> wrote: > Dan, > > Add VERBOSE=1 to your make command. > > make -j8 VERBOSE=1 > > To see details of the compile commands. Some of the third party > dependencies won't show them but give it a try. > > -Jake > > > O

Re: Native client build fails linking shared library?

Do you see -lz in the link line? Sarge > On 17 Jan, 2017, at 16:24, Dan Smith wrote: > > I tried building the next-gen-native-client-software-grant branch on an > ubuntu 16.04 box. It gets about halfway through and then fails with these > errors. Any ideas? > > [ 49%]

Re: [GitHub] geode issue #341: GEODE-2306: Update native client BUILDING.md to reflect ch...

It's current in src/ on next-gen-native-client-software-grant. What do you mean by "down to the root directory"? Sarge > On 17 Jan, 2017, at 13:43, pivotal-jbarrett wrote: > > Github user pivotal-jbarrett commented on the issue: > >

Re: New Repo for Native Client

To me this seems related to the question of the degree to which the Geode community should be homogeneous. Who are we trying to attract with the non-Java clients: the existing, Java-centric community or new community members from other platforms? If the former, gradle makes it easy for them to

Re: Native Namespace

In my experience, it seems easier to have too many namespaces than it is to have too few. My instinct is to start with geode:: and Geode. and further subdivide when it becomes unwieldy and collisions arise. Sarge > On 16 Jan, 2017, at 21:10, Jacob Barrett wrote: > > An

Re: Native Client Directory Structure

currently have three options for programming language: Java, C++, and C#. Sarge > On 16 Jan, 2017, at 08:45, Jacob Barrett <jbarr...@pivotal.io> wrote: > > On Mon, Jan 16, 2017 at 8:35 AM Michael William Dodge <mdo...@pivotal.io> > wrote: > >> Given that the

Re: Native Client Directory Structure

Given that the current source structure uses cpp and cli prefixes for the C++ and .NET clients, respectively, what about using cpp and cli for the directories, allowing any new .NET development to go into a separate directory (perhaps cs or csharp) without any additional moves? Sarge > On 16

Permission to Create JIRA Issues

I'd like to create a JIRA issue regarding a problem I've discovered. May I please have permission added for username PivotalSarge? Thanks. Sarge