RE: [DISCUSS] Remove geode-dotnet-core-client repo

[Blake Bender]

Please do.  We created this repo early on, when we thought .net core made more 
sense in it's own repo rather than as part of the native client repo.  Since 
then, we've decided to put it in geode-native because we frequently have to 
update both C bindings and .net core pinvokes at the same time, and keeping the 
two repos in sync would be untenable or at least very difficult.  Thus 
geode-dotnet-core-client is not in use and never really was, actively.

Thanks,

Blake


-Original Message-
From: Dan Smith  
Sent: Thursday, September 2, 2021 9:18 AM
To: dev@geode.apache.org
Subject: [DISCUSS] Remove geode-dotnet-core-client repo

It looks like the geode-dotnet-core-client repository is stale, and the code 
has moved to the geode-native repository. Is it ok to go ahead and remove the 
geode-dotnet-core-client repository? If so, I'll figure out how to make that 
happen. At a minimum we could commit a change that deletes all the code and 
leaves a README pointing to the new location.

Old Location: 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-dotnet-core-client%2Fdata=04%7C01%7Cbblake%40vmware.com%7C017137ee0eb34a68a56208d96e2d3ed9%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637661962891665504%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=LpAJ6U1saE17e2ZwS9xYXYw2rV7uXqLIXuIJmoaKnJA%3Dreserved=0
New Location: 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Ftree%2Fdevelop%2Fnetcoredata=04%7C01%7Cbblake%40vmware.com%7C017137ee0eb34a68a56208d96e2d3ed9%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637661962891665504%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=yNtc6LGCqihWWh7jC1WNIpX8pdUMjfdfUWup8aEslu0%3Dreserved=0

-Dan

RE: Proposal - unprotect develop branch of geode-native

[Blake Bender]

Right, so I can keep my git history clean by:
* doing a rebase-squash for PR A
* (potentially) doing a rebase squash for PR B
* combining A & B
* resubmitting combined PR
* crossing my fingers and hoping everything gets applied in the proper order to 
pass CI gates

This work is all unnecessary, and still isn't 100% guaranteed to fix the 
problem.  There really ought to be a way to commit directly to develop, or at 
least bypass checkin gates, in special circumstances.


-Original Message-
From: Owen Nichols  
Sent: Tuesday, August 17, 2021 2:26 PM
To: dev@geode.apache.org
Subject: Re: Proposal - unprotect develop branch of geode-native

For this situation in Geode repo, in addition to Squash, we also allow Rebase.  
This would allow you to put both commits in the same PR to pass checks, but 
still apply them to develop as separate commits.

On 8/17/21, 2:20 PM, "Blake Bender"  wrote:

Hello everyone,

Today I once again find myself between a rock and a hard place managing 
incoming PRs into the geode-native project.  We merged a PR that passed checkin 
gates, then broke in the main CI pipeline.  Additionally, our code formatter 
took an update yesterday, and now disagrees with some of the code that is 
already on the develop branch.  I submitted a PR to fix the formatting, but it 
now won't pass checkin gates because of the first break, and said first break 
can't be reverted because it won't pass checkin gates due to formatting.  I 
could maybe solve this problem by combining the two PRs, but then I'd pollute 
my Git history, which IMO is a bigger problem than either of these issues.

Sadly, this happens much more often than you'd think, and every time it 
does it takes days to untangle this knot we've tied ourselves in, when it 
should take seconds or minute of my time at most.  I would like to propose that 
we either unprotect develop on geode-native, and allow direct checkins for 
specific circumstances like reverting PRs or fixing things like this formatting 
issue.  It's crazy to keep wasting my time trying to work around something with 
such a simple solution at hand.

Thanks,

Blake

Proposal - unprotect develop branch of geode-native

[Blake Bender]

Hello everyone,

Today I once again find myself between a rock and a hard place managing 
incoming PRs into the geode-native project.  We merged a PR that passed checkin 
gates, then broke in the main CI pipeline.  Additionally, our code formatter 
took an update yesterday, and now disagrees with some of the code that is 
already on the develop branch.  I submitted a PR to fix the formatting, but it 
now won't pass checkin gates because of the first break, and said first break 
can't be reverted because it won't pass checkin gates due to formatting.  I 
could maybe solve this problem by combining the two PRs, but then I'd pollute 
my Git history, which IMO is a bigger problem than either of these issues.

Sadly, this happens much more often than you'd think, and every time it does it 
takes days to untangle this knot we've tied ourselves in, when it should take 
seconds or minute of my time at most.  I would like to propose that we either 
unprotect develop on geode-native, and allow direct checkins for specific 
circumstances like reverting PRs or fixing things like this formatting issue.  
It's crazy to keep wasting my time trying to work around something with such a 
simple solution at hand.

Thanks,

Blake

RE: Fw: [DISCUSS] Rebase and Squash Options on Github develop

[Blake Bender]

+1, only because I only get one vote.  Merge commits in develop are a scourge, 
IMO, and should be avoided in almost all instances.

Blake


-Original Message-
From: Donal Evans  
Sent: Monday, June 28, 2021 2:22 PM
To: dev@geode.apache.org
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop

I definitely approve of this proposal. I accidentally merged (rather than 
squashed and merged) a PR a while back because my GitHub session had expired 
and refreshing the page after trying to squash and merge resulted in the 
default merge option being used, much to my frustration. I've yet to see any 
explanation of why we would need to merge PRs rather than squash and 
merge/rebase and merge, so removing it as an option just seems like a good idea.

From: Nabarun Nag 
Sent: Monday, June 28, 2021 1:06 PM
To: Owen Nichols ; dev@geode.apache.org 

Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop

Just a clarification.

The options I am proposing to be kept in the PRs are:

  *   Squash and merge
  *   Rebase and merge

Regards,
Nabarun

From: Owen Nichols 
Sent: Monday, June 28, 2021 1:03 PM
To: Nabarun Nag ; dev@geode.apache.org 
Subject: Re: Fw: [DISCUSS] Rebase and Squash Options on Github develop

Sounds like a good idea. I can't find any example of an intentional merge 
commit on develop...but plenty of accidental ones.

Upon releases we do a command line merge commit to the main trunk, which should 
still be fine as this proposal only applies to PRs.

I agree with still allowing rebase commits. I have seen several PRs use them to 
good effect.

You can disable merge commits through .asf.yaml, so changing the setting is as 
easy as opening a PR (and, if we don't like it, reverting is just as easy)


---
Sent from Workspace ONE 
Boxer

On June 28, 2021 at 12:38:50 PM PDT, Nabarun Nag  wrote:
Hi all,

Last year, we had a discussion on rebase and squash merge PRs to the develop 
branch,

  *   to have linear git history
  *   help with bisecting
  *   easier root cause analysis of failures
  *   easier to backport changes

However, many developers have reached out mentioning that sometimes they have 
clicked the merge button in hurry when they meant to rebase/squash. Once 
clicked there is no going back. All of them suggested that to have the GitHub 
setting on develop branch to rebase and squash merge option and hence there is 
no room for mistakes to occur.

I would like to propose to that we set the GitHub setting on develop PR to 
rebase and squash buttons.

Please do note that this is reversible and can be changed back, hence there is 
no harm in trying it out.


Regards
Nabarun Nag



From: Owen Nichols (Pivotal) 
Sent: Thursday, April 9, 2020 11:45 AM
To: dev@geode.apache.org 
Subject: Re: [REQUEST] Squash merge please

I've noticed quite a few PRs in the last week that were merged with "Merge" 
rather than "Squash and Merge".

While the community consensus was to continue to allow all merge options, 
please try to default to "Squash and Merge" whenever you can to keep history as 
linear as possible. GitHub will save the last method you used in a cookie, 
which helps, but then it's easy to miss when it resets itself back to the 
default of "Merge" some months later because you cleared cookies, changed 
browsers, etc.

> On Oct 22, 2019, at 5:12 PM, Nabarun Nag  wrote:
>
> Hi Geode Committers,
>
> A kind request for using squash commit instead of using merge.
> This will really help us in our bisect operations when a regression/flakiness 
> in the product is introduced. We can automate and go through fewer commits 
> faster, avoiding commits like "spotless fix" and "re-trigger precheck-in" or 
> other minor commits in the merged branch.
>
> Also, please use the commit format : (helps us to know who worked on it, what 
> is the history)
> GEODE-: 
>
> * explanation line 1
> * explanation line 2
>
> This is not a rule or anything, but a request to help out your fellow 
> committers in quickly detecting a problem.
>
> For inspiration, we can look into Apache Kafka / Spark where they have a 
> complete linear graph for their main branch HEAD [see attachment]
>
> Regards
> Naba.
>
>

RE: Reminder to use draft mode

[Blake Bender]

+1 for draft mode as default.  I'm forever switching to it in geode-native 
already, because the most convenient way for us to get feedback on build/test 
status for all platforms is to run a change through CI, and the only way to do 
that is to submit it as a PR.

Thanks,

Blake


-Original Message-
From: Alberto Bustamante Reyes  
Sent: Thursday, May 6, 2021 1:19 PM
To: dev@geode.apache.org
Subject: RE: Reminder to use draft mode

+1 to Mark's proposal of setting draft mode as default when creating PRs (Im 
wondering if a new VOTE thread is needed to approve it)

And also +1 to Donal's comments.


De: Darrel Schneider 
Enviado: jueves, 6 de mayo de 2021 21:43
Para: dev@geode.apache.org 
Asunto: Re: Reminder to use draft mode

+1 to Donal's comments

From: Donal Evans 
Sent: Thursday, May 6, 2021 11:44 AM
To: dev@geode.apache.org 
Subject: Re: Reminder to use draft mode

+1 to Naba's PR flow described above.

Creating PRs in draft mode is almost always the best choice, as it prevents 
people from being tagged to review a set of changes that may change 
significantly due to test failures and only requires a single click to convert 
to the "ready to review" state - hardly a major inconvenience.

However, the real tricky question here seems to be "When should you move a PR 
from "Ready to review" back into draft mode?" I tend to agree with Jens that a 
flaky test failure by itself isn't enough to warrant putting a PR back into 
draft mode, as it's often possible to identify the failure as being due to an 
existing known bug and merge the PR knowing that your changes aren't the cause. 
We don't require that all PR tests are green before merging, just some of them, 
so it's reasonable to assume that we don't require all PR tests to be green 
before a PR is considered ready for review either.

Minor edits due to review comments (like spelling mistakes or minor code 
quality/style changes) also don't feel like they should cause a PR to be put 
back into draft mode, as while the contents of the PR may change because of 
them, it won't invalidate other in-progress reviews if it does, or 
significantly alter the nature of the PR.

For me, the bar for whether a PR should be put back into draft mode is if you 
know that its current state is not reflective of the final state that will be 
merged into develop. In general, the only time that should happen is if you've 
received review feedback that will require a change of approach or significant 
refactoring/additional code. It's the difference between "needs a little 
polish" and "needs more work," I think. Obviously, what counts as "significant" 
is entirely subjective, so this isn't much use as a hard and fast rule, but a 
rough guide might be that if a reviewer has requested changes that would 
invalidate or render obsolete/redundant any additional reviews that come in 
before those changes are applied, moving back to draft mode would probably be a 
good idea.

Donal

From: Nabarun Nag 
Sent: Thursday, May 6, 2021 10:22 AM
To: dev@geode.apache.org 
Subject: Re: Reminder to use draft mode

I feel that Owen has a valid point and I myself feel that it is ok to start the 
PR in draft mode till the pre-check tests pass.

There has been this situation where,

  *   PR is created (reviewers are assigned)
  *   approved
  *   Tests fail
  *   code is changed
  *   no reviews
  *   code is merged

Hence code that is not reviewed has been merged

This way of doing work also has the following advantages:

  *   A reviewer does not have to review a code that causes tests to fail
  *   A reviewer does not have to review code twice before failure and then 
again after changing the code to fix the failure
  *   Unreviewed code post-test fixes do not get merged

I think this way of working saves a critical amount of time for engineers who 
review code.

This flow of PRs feels more efficient:


  *   Create PR in draft mode - no reviewers assigned
  *   PRechecks fail
  *   change/fix code
  *   tests pass - all green
  *   convert PR to ready for review - reviewers assigned
  *   reviewers review

Regards
Naba




From: Owen Nichols 
Sent: Thursday, May 6, 2021 9:59 AM
To: dev@geode.apache.org 
Subject: Re: Reminder to use draft mode

Given the lack of consensus, it sounds like it will not be possible to make any 
assumptions about a PR based on whether it is in Draft mode or not.  I will 
stop retriggering flaky checks or changing PRs to draft status.  My apologies 
for the inconvenience this has caused.

On 5/6/21, 9:47 AM, "Jens Deppe"  wrote:

I don’t think we can presume everyone has the same working style. For 
myself I’ll happily review a PR that has a failing check. I’m OK if it has some 
innocuous ‘housekeeping’ error or unrelated failure.

I don’t retrigger PR failures, for unrelated errors, just to ‘get to green’ 
– related, I 

RE: DISCUSSION: Geode Native C++ Style and Formatting Guide

[Blake Bender]

My $0.02 on these:

Things I'd like to see us conform to Google style on:
* I'd be happy to move to C++ 17
* Would also be happy to remove forward declarations.  "I'm not a critic, but I 
know what I hate," as it were, and I hate forward declarations.  
* I would also be happy with an 80-character line limit, though I don't feel 
strongly about it.  100 may be consistent with Geode, but it still feels 
arbitrary to me.  
* I would be very pleased to remove all the macros from our code.  I've been 
bitten more than once in the past while debugging or refactoring our code, 
because of ill-formed macros.

Google things I disagree with:
* I don't like exceptions, but I don't even want to think about the amount of 
effort required to remove them from the codebase is, IMO, unreasonably high.  
Keep the exceptions, most of the time they're used pretty judiciously.
* I really, really, *really* (really?  Yes, really!) hate anything resembling 
Hungarian prefix notation, and have permanent scars from decades of reading it 
in Windows code.  Please don't ask me to put a random 'k' in from of my enums - 
ick.

One other note: in the past, we've had conversations about "style only" pull 
requests to fix some of these things, and the guidance we ended up with has 
been to only fix this sort of thing while you're in the code working on a fix 
or a feature.  I, for one, would welcome some PRs that just, say, renamed a ton 
of member variables to replace "m_" prefix with a simple trailing "_", perhaps 
fixed some of the more egregious and weird abbreviations, etc.  My preference 
for bug fixes and feature work is that all of the code changes be focused on 
stuff that's relevant to the fix/feature, and mixing it with random style guide 
refactoring, I feel, muddies the waters for future maintainers.

Thanks,

Blake
  
-Original Message-
From: Jacob Barrett  
Sent: Saturday, May 1, 2021 9:21 AM
To: dev@geode.apache.org
Subject: Re: DISCUSSION: Geode Native C++ Style and Formatting Guide

Great call outs!

> On May 1, 2021, at 7:57 AM, Mario Salazar de Torres 
>  wrote:
> 
>  1.  Member variables names as of Google style guide requires a '_' char to 
> be added at the end so it can be identified. Should we also adopt that?
> For example, imagine you have a region mutex, so, should we name it as 
> 'regionMutex_' ?

I didn’t mention this one out in my review of differences because we are 
following it but I suppose with the combination of the camelCase difference we 
should probably call it out more specifically. Perhaps in our documentation we 
should show examples of both local and member variables. Do you think that will 
make it more clear?

>  2.  Also, I would like to point out that macros are dis-recommended but 
> every C++ committee member I know.
> What do you think about adding a notice saying: "Macros should be avoided and 
> only used when there is no alternative”?

I think that is called out in various ways in a few places in the Google guide 
but I am more than happy for us to include strong or clearer language around 
this. Between constexpr and templates there are very cases for macros anymore. 
We mostly use macros only to handle non-standard attributes. When we move to 
C++17 a lot of these will go away.

Thanks,
Jake

Very old geode-native PRs

[Blake Bender]

Good morning!

We are attempting to push through all of the most longstanding geode-native 
PRs, so if you're involved in one as an author or a reviewer your prompt 
attention would be much appreciated.  There are 4 outstanding that I consider 
"very old," all initially submitted prior to the first of the year.  Here they 
are, with the latest statuses as I understand them.


  1.  PR 678, for GEODE-8601: https://github.com/apache/geode-native/pull/678.  
This one had an outstanding "change requested" review, which has kindly been 
removed this morning to unblock progress.  All CI checks are passing, so I will 
request a review internally today to see if there's anything that really must 
be done prior to merging.
  2.  PR 699 for GEODE-8698: https://github.com/apache/geode-native/pull/699.  
This has an outstanding "change requested" review, so I will contact the author 
of that today to follow up.  CI tasks are in a strange "pending" state, so it 
looks like this one was originally submitted prior to our making the CI public, 
and the new CI hasn't been run.  If the author would be kind enough to push an 
empty commit, that should probably force a run and we can see what state the 
code is in.  A rebase onto the latest develop branch is in order here, as well.
  3.  PR 705, for GEODE-8543: https://github.com/apache/geode-native/pull/705.  
Again the "change requested" review has been removed, and I will follow up with 
the team to get a new review ASAP.  This one is also in a stuck state with 
respect to CI, so again a rebase and push to clear things up would be 
appreciated.
  4.  PR 713, for GEODE-8442: https://github.com/apache/geode-native/pull/713.  
This one has had quite a bit of attention recently, and was rebased 10 days 
ago.  Review has been approved, and one integration test is failing in CI on 
all platforms.  Author has been notified.

Thanks,

Blake

RE: Concourse geode-native permissions

[Blake Bender]

I suspect it's this job you wished to re-run, yes?  
https://concourse.apachegeode-ci.info/builds/14598

As an immediate measure, I've restarted the job with the same inputs.

Thanks,

Blake


-Original Message-
From: Mario Salazar de Torres  
Sent: Wednesday, March 17, 2021 9:57 AM
To: dev@geode.apache.org
Subject: Re: Concourse geode-native permissions

Hi,

Thanks for your answers. I am aware that I can push an empty commit to trigger 
CI. Thing is I wouldn't like to waste compute resources in case there is only 
one job failing.
If you say it's possible to request permissions, that'd be ideal. What should 
be the process to request them? If not possible, I'll retrigger the whole 
pipeline by pushing the empty commit.

BTW. In case there is a possibility to be granted permissions my username is 
gaussianrecurrence

BR,
Mario.

From: Jacob Barrett 
Sent: Wednesday, March 17, 2021 5:51 PM
To: dev@geode.apache.org 
Subject: Re: Concourse geode-native permissions

You can also request permission for yourself.

If it is a PR you can also push an empty commit, though this will trigger all 
jobs. Also, if this is a PR make sure you use the re-run with same inputs 
button, otherwise it will run the most recent PR and not necessarily yours.

> On Mar 17, 2021, at 9:48 AM, Owen Nichols  wrote:
>
> Yes, concourse permissions are needed to re-trigger a job.  Any past Release 
> Manager should have the necessary permissions, if you can share the job URL.
>
> On 3/17/21, 9:37 AM, "Mario Salazar de Torres" 
>  wrote:
>
>Hi everyone,
>
>I am trying to re-run a job that randomly failed in geode-native's 
> concourse. Thing is I am being answered a 403 when hitting re-run. Do I need 
> any permissions to be able to re-run jobs?
>
>Regards,
>Mario
>

RE: Question about closing of all connections towards an endpoint in C++ native client

[Blake Bender]

Just FWIW - we cut the 1.14 branch of native *prior to* merging the boost::asio 
change, so we would have some mileage on the change before releasing.  So, all 
other things being equal, this will be in native 1.15, not 1.14.

Thanks,

Blake

-Original Message-
From: Jacob Barrett  
Sent: Wednesday, February 24, 2021 7:38 AM
To: dev@geode.apache.org
Subject: Re: Question about closing of all connections towards an endpoint in 
C++ native client

Oh good! 1.14 is on its way, so problem solved! ;)

> On Feb 24, 2021, at 7:31 AM, Alberto Gomez  wrote:
> 
> Thanks Jake. I totally agree with you.
> 
> Interestingly, that logic has been recently removed from the C++ client when 
> we switched from ACE_SOCK to boost::asio so what I said in my previous e-mail 
> pertained to the C++ client 1.13 version and older.
> 
> Alberto
> 
> From: Jacob Barrett 
> Sent: Wednesday, February 24, 2021 4:24 PM
> To: dev@geode.apache.org 
> Subject: Re: Question about closing of all connections towards an endpoint in 
> C++ native client
> 
> The Java client does the same thing under certain conditions. Neither of the 
> clients should do this though. I think this model is way too overaggressive. 
> I think we should remove that logic entirely. If we think we want something 
> that proactively checks the other connections to that server we could have a 
> background thread go through and send a ping request on one the next in the 
> queue. If it doesn’t respond then terminate that connection. Continue until a 
> pong response is received.
> 
> -Jake
> 
>> On Feb 24, 2021, at 4:36 AM, Alberto Gomez  wrote:
>> 
>> Hi,
>> 
>> Running some tests with the C++ native client and looking at the code, I 
>> have observed that when an error in a connection towards an endpoint 
>> (timeout, IO error) is detected, not only the faulty connection is closed 
>> but the endpoint is set to "not connected" status which eventually provokes 
>> that all other open connections towards that endpoint are closed when used.
>> 
>> I have not seen that behavior in the Java client, i.e., the Java client, 
>> when it detects an error in a connection towards an endpoint, it closes that 
>> connection but does not act on other connections towards that endpoint.
>> 
>> Are my observations correct?
>> 
>> If so, shouldn't the C++ native client be aligned with the Java client?
>> 
>> Thanks,
>> 
>> Alberto G.
> 

Need Concourse access, please

[Blake Bender]

Hello, may I please have access to the Geode Concourse?

My GitHub username is pdxcodemonkey

Thanks,

Blake

RE: State of https://github.com/apache/geode-dotnet-core-client

[Blake Bender]

The dotnet-core-client repo is at best a placeholder at present, and is not 
suitable for any kind of use.  It requires a special build of geode-native that 
contains c-style exported API functions, that is only available on a branch on 
one of my forks IIRC.  It exists under the apache project because we 
desperately needed to get it under revision control to preserve WIP, and 
starting under apache avoided a potentially difficult future migration.

I can prioritize a PR to scrub proprietary names, but please understand we've 
been trying to get back to this repo for several _months_ now and been swamped 
with patch releases and customer bugs/support requests, so I don't wish to set 
expectations very high.

As far as tests for the code, yes they exist and cover the "supported" API thus 
far, which is not a lot.  If everything is set up correctly, however, creating 
a cache factory, cache, pool, region, and put/get of string key/value pairs 
works.

Thanks,

Blake


-Original Message-
From: John Hutchison  
Sent: Tuesday, December 29, 2020 11:24 AM
To: dev@geode.apache.org
Subject: Re: State of https://github.com/apache/geode-dotnet-core-client

Is there some kind linting that we could put into spotless (or a linting tool 
that's run before spotless)  to prevent this kind of thing  (check against 
known proprietary names and derivatives before being allowed through ci)?

From: Jacob Barrett 
Date: Tuesday, December 29, 2020 at 1:08 PM
To: dev@geode.apache.org 
Subject: Re: State of 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-dotnet-core-clientdata=04%7C01%7Cbblake%40vmware.com%7C35d72397c8b5436f342808d8ac2f562e%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C63744804574411%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=alFiaIqSZZBmtPVHNYIzfHJBqJT6rthLXIPccs%2BwTGU%3Dreserved=0
Wow, that's pretty bad that we put proprietary references into this repo from 
the start. If you have the bandwidth a cleanup PR would be appreciated.

I can't speak to the functionality but I would hope there are unit and 
integration tests that assert the supported behavior.

-Jake

> On Dec 21, 2020, at 4:48 PM, Michael Oleske  wrote:
>
> Hi Geode Dev Friends!
>
> I'm starting a personal little side project and was thinking of using Geode 
> as my backend (no real reason, certainly doesn't need the capabilities of 
> Geode, but thought it'd be fun.)  I'm writing my application in .NET 5 (which 
> is core based) and was going to try and use 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-dotnet-core-clientdata=04%7C01%7Cbblake%40vmware.com%7C35d72397c8b5436f342808d8ac2f562e%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C63744804574411%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=alFiaIqSZZBmtPVHNYIzfHJBqJT6rthLXIPccs%2BwTGU%3Dreserved=0
>
> I see no one has really made any changes to it for a while, and that it seems 
> to have some proprietary references in it.  Is it in a usable state for 
> simple puts/gets?
>
> -michael

Re: Review for "C++ native client Function.execute() with onServers does not throw exception if one of the servers goes down while executing the function."

[Blake Bender]

Hi Alberto,

I’m back from a week’s vacation this morning, and will have a look.

Thanks,

Blake


From: Alberto Gomez 
Date: Monday, November 16, 2020 at 7:11 AM
To: dev@geode.apache.org 
Subject: Review for "C++ native client Function.execute() with onServers does 
not throw exception if one of the servers goes down while executing the 
function."
Hi,

Could somebody review PR 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Fpull%2F690data=04%7C01%7Cbblake%40vmware.com%7C0d61027c99b94ee727a908d88a41d68d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637411362666288996%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=WRcP9qOVyDZub2NitRhtEh0ujxCZkm%2F4nx8OMl4cjg4%3Dreserved=0
  
(https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-8693%3Ffilter%3D-2data=04%7C01%7Cbblake%40vmware.com%7C0d61027c99b94ee727a908d88a41d68d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637411362666288996%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=9WFHdNc3p1A4hdnG3a0%2FxgM1YLR4BFQtyWX7Tzf90gc%3Dreserved=0).

Thanks,

/Alberto G.

Re: PR process and etiquette

[Blake Bender]

Oops, sorry for the confusion!  I’ve been working through Mario’s PRs a lot 
lately.


From: Alberto Gomez 
Date: Wednesday, October 28, 2020 at 7:10 AM
To: "dev@geode.apache.org" , Blake Bender 

Subject: Re: PR process and etiquette

+1 to draft PRs.

By the way @Blake Bender<mailto:bbl...@vmware.com>, it's me the one having the 
draft PR for GEODE-8318.

Alberto G.
________
From: Blake Bender 
Sent: Wednesday, October 28, 2020 2:28 PM
To: dev@geode.apache.org 
Subject: Re: PR process and etiquette

+1 for draft PRs.  Native has been using these for a few months now, and 
they're quite effective.  Right now, for example, we have 6 PRs up, 3 of which 
are draft.  They also turn out to be a convenient way to share work, in certain 
circumstances.  Mario, for instance, has a draft up for GEODE-8318 that is 
strictly WIP.  By having it up as a draft PR, I get notifications when changes 
are pushed, and can run internal tooling and let him know if I find issues.

Thanks,

Blake


On 10/28/20, 1:03 AM, "Udo Kohlmeyer"  wrote:

Great information Darrel. Thank you for sharing that.

--Udo

From: Darrel Schneider 
Date: Wednesday, October 28, 2020 at 3:32 PM
To: dev@geode.apache.org 
Subject: Re: PR process and etiquette
+1 to your idea of using "draft" mode until things are green. Something to 
be aware of is that if your pr branch has conflicts and it is in draft mode 
then your pr tests will not run and the pr page will not tell you that 
conflicts exist. If you see that the pr tests are not actually running and it 
is in draft mode then try merging develop to your pr branch and resolve the 
conflicts.

From: Owen Nichols 
Sent: Tuesday, October 27, 2020 6:03 PM
To: dev@geode.apache.org 
Subject: Re: PR process and etiquette

+1 for using GitHub's draft status to indicate work-in-progress.

Many great suggestions here, however I generally prefer that we don't 
squash commits at any point except the final Squash and Merge to develop.  I 
find it insightful to see how the work evolved.  I also find that review 
comments may start coming in even before you are "ready" for review, and a 
squash or force-push "loses" those comments.

One thing I would like to see more of is PR summaries that explain *why* 
the change is being made, not just *what* is being changed.

Thanks Udo for looking for ways to make the community process work even 
better!

On 10/27/20, 5:41 PM, "Udo Kohlmeyer"  wrote:

Dear Apache Geode Devs,
It is really great going through all the PRs that been submitted. As 
Josh Long is known to say: "I work for PRs".
Whilst going through some of the PRs I do see that there are many PRs 
that have multiple commits against the PR.
I know that the PR submission framework kicks off more testing than we 
do on our own local machines. It is extremely uncommon to submit a PR the first 
time and have all tests go green. Which means we invariably iterate over 
commits to make the build go green.
In this limbo time period, it is hard for any reviewer to know when the 
ticket is ready to be reviewed.
I want to propose that when submitting a PR, it is initially submitted 
as a DRAFT PR. This way, all test can still be run and work can be done to make 
sure "green" is achieved. Once "green" status has been achieved, the draft can 
then be upgraded to a final PR by pressing the "Ready For Review" button. At 
this point all commits on the branch can then once again be squashed into a 
single commit.
Now project committers will now know that the PR is in a state that it 
can be reviewed for completeness and functionality.
In addition, it will help tremendously helpful if anyone submitting a 
PR monitors their PR for activity. If there is no activity for a few days, 
please feel free to ping the Apache Geode Dev community for review. If review 
is request, please prioritize some time to address the feedback, as reviewers 
spend time reviewing code and getting an understanding what the code is doing. 
If too much time goes by, between review and addressing the review comments, 
not only does the reviewer lose context, possibly requiring them to spend time 
again to understand what the code was/is supposed to do, but also possibly lose 
interest, as the ticket has now become cold or dropped down the list of PRs.
There are currently many PRs that are in a cold state, where the time 
between review and response has been so long, that both parties (reviewer and 
submitter) have forgotten about the PR.
In the case that the reviews will take more time to address than 
expected, please downgrade the PR to draft status again. At this point, it does 
not mean that reviewers will not be able to help anymore, as you can reques

Re: PR process and etiquette

[Blake Bender]

+1 for draft PRs.  Native has been using these for a few months now, and 
they're quite effective.  Right now, for example, we have 6 PRs up, 3 of which 
are draft.  They also turn out to be a convenient way to share work, in certain 
circumstances.  Mario, for instance, has a draft up for GEODE-8318 that is 
strictly WIP.  By having it up as a draft PR, I get notifications when changes 
are pushed, and can run internal tooling and let him know if I find issues.

Thanks,

Blake


On 10/28/20, 1:03 AM, "Udo Kohlmeyer"  wrote:

Great information Darrel. Thank you for sharing that.

--Udo

From: Darrel Schneider 
Date: Wednesday, October 28, 2020 at 3:32 PM
To: dev@geode.apache.org 
Subject: Re: PR process and etiquette
+1 to your idea of using "draft" mode until things are green. Something to 
be aware of is that if your pr branch has conflicts and it is in draft mode 
then your pr tests will not run and the pr page will not tell you that 
conflicts exist. If you see that the pr tests are not actually running and it 
is in draft mode then try merging develop to your pr branch and resolve the 
conflicts.

From: Owen Nichols 
Sent: Tuesday, October 27, 2020 6:03 PM
To: dev@geode.apache.org 
Subject: Re: PR process and etiquette

+1 for using GitHub's draft status to indicate work-in-progress.

Many great suggestions here, however I generally prefer that we don't 
squash commits at any point except the final Squash and Merge to develop.  I 
find it insightful to see how the work evolved.  I also find that review 
comments may start coming in even before you are "ready" for review, and a 
squash or force-push "loses" those comments.

One thing I would like to see more of is PR summaries that explain *why* 
the change is being made, not just *what* is being changed.

Thanks Udo for looking for ways to make the community process work even 
better!

On 10/27/20, 5:41 PM, "Udo Kohlmeyer"  wrote:

Dear Apache Geode Devs,
It is really great going through all the PRs that been submitted. As 
Josh Long is known to say: "I work for PRs".
Whilst going through some of the PRs I do see that there are many PRs 
that have multiple commits against the PR.
I know that the PR submission framework kicks off more testing than we 
do on our own local machines. It is extremely uncommon to submit a PR the first 
time and have all tests go green. Which means we invariably iterate over 
commits to make the build go green.
In this limbo time period, it is hard for any reviewer to know when the 
ticket is ready to be reviewed.
I want to propose that when submitting a PR, it is initially submitted 
as a DRAFT PR. This way, all test can still be run and work can be done to make 
sure "green" is achieved. Once "green" status has been achieved, the draft can 
then be upgraded to a final PR by pressing the "Ready For Review" button. At 
this point all commits on the branch can then once again be squashed into a 
single commit.
Now project committers will now know that the PR is in a state that it 
can be reviewed for completeness and functionality.
In addition, it will help tremendously helpful if anyone submitting a 
PR monitors their PR for activity. If there is no activity for a few days, 
please feel free to ping the Apache Geode Dev community for review. If review 
is request, please prioritize some time to address the feedback, as reviewers 
spend time reviewing code and getting an understanding what the code is doing. 
If too much time goes by, between review and addressing the review comments, 
not only does the reviewer lose context, possibly requiring them to spend time 
again to understand what the code was/is supposed to do, but also possibly lose 
interest, as the ticket has now become cold or dropped down the list of PRs.
There are currently many PRs that are in a cold state, where the time 
between review and response has been so long, that both parties (reviewer and 
submitter) have forgotten about the PR.
In the case that the reviews will take more time to address than 
expected, please downgrade the PR to draft status again. At this point, it does 
not mean that reviewers will not be able to help anymore, as you can request a 
reviewer to help with feedback and comments, until one feels that the PR is 
back in a state of final submission.
So, what I'm really asking from the Dev Community:
If you submit a PR, it would be great if you can nudge the 
community if there is no review on the PR. If feedback is provided on a PR, 
please address it as soon as possible. This not only will help the PR progress 
faster, but it will shorten the feedback loop.
Finally, start with a DRAFT PR and then upgrade to a final PR 
when you feel it is in a "good" state. If more work is required, it is ok to 
downgrade back to a 

Re: PRs to review in geode-native

[Blake Bender]

I've asked mreddington to re-review today.  I think we're still hoping to have 
a test for this, though, right?  

On 10/27/20, 5:51 AM, "Mario Salazar de Torres" 
 wrote:

Hi everyone,

Thanks everyone involved for merging PR 
#659<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Fpull%2F659data=04%7C01%7Cbblake%40vmware.com%7C638426e25e644d6ad82508d87a76f590%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637393998640926274%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=%2F3gELhN0B2XBC5pngQv1A0WLhaCoenMZVnCFaUOM7oM%3Dreserved=0>.
Thing is that it has been a while since 
#660<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Fpull%2F660data=04%7C01%7Cbblake%40vmware.com%7C638426e25e644d6ad82508d87a76f590%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637393998640926274%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=59wr1HMHQhNOvMczV%2FNeq5yDo1n1jz6jDQOD%2BNlXCXI%3Dreserved=0>
 got any feedback.
Is there any chance you could reserve some time to give me some feedback on 
it?

Thanks for all.

BR,
Mario.

____
From: Blake Bender 
Sent: Wednesday, September 30, 2020 4:34 PM
To: dev@geode.apache.org 
Subject: Re: PRs to review in geode-native

We'll get on these today, no worries.

Thanks,

Blake


On 9/30/20, 2:08 AM, "Mario Salazar de Torres" 
 wrote:

Hi everyone,

I've created 2 PR in geode-native repository:

  *   
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Fpull%2F659data=04%7C01%7Cbblake%40vmware.com%7C638426e25e644d6ad82508d87a76f590%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637393998640926274%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=%2F3gELhN0B2XBC5pngQv1A0WLhaCoenMZVnCFaUOM7oM%3Dreserved=0
  *   
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Fpull%2F660data=04%7C01%7Cbblake%40vmware.com%7C638426e25e644d6ad82508d87a76f590%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637393998640926274%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=59wr1HMHQhNOvMczV%2FNeq5yDo1n1jz6jDQOD%2BNlXCXI%3Dreserved=0

If any of you could take some time to throw some comments on them, I 
would be so much appreciated.
PST. It's my first time contributing to the project, so please don't be 
too mean with me ha-ha 

Thanks!
BR/Mario

Re: PRs to review in geode-native

[Blake Bender]

We'll get on these today, no worries.

Thanks,

Blake


On 9/30/20, 2:08 AM, "Mario Salazar de Torres" 
 wrote:

Hi everyone,

I've created 2 PR in geode-native repository:

  *   
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Fpull%2F659data=02%7C01%7Cbblake%40vmware.com%7Cdc2d4126f8404c610e7f08d865206ef0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637370537265990061sdata=T7mRZ6%2B01yd6wOUmbE2s2Q%2FWAOM63E9ZE%2FSBbrB1wmk%3Dreserved=0
  *   
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Fpull%2F660data=02%7C01%7Cbblake%40vmware.com%7Cdc2d4126f8404c610e7f08d865206ef0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637370537265990061sdata=%2F0XPvKcup8OcgnG8bfvJ1b0ZTkJTb4IztbsooCsKto0%3Dreserved=0

If any of you could take some time to throw some comments on them, I would 
be so much appreciated.
PST. It's my first time contributing to the project, so please don't be too 
mean with me ha-ha 

Thanks!
BR/Mario

Re: Clean C++ client metadata in timeouts

[Blake Bender]

Given that attempts to retrieve metadata after the C++ cache is closed are a 
constant headache for Geode Native development, I am generally in favor of 
anything that potentially reduces the number of times/places this happens.  If 
we've failed the handshake, it's very unlikely things will correct themselves 
without outside intervention, so this fix is probably goodness.  I'd go ahead 
and submit a PR when you think it's solid.

Thanks,

Blake


On 9/17/20, 9:36 AM, "Dave Barnes"  wrote:

Alberto,
Are there cases in which one or two timeouts are followed by a successful
retry? Or does one timeout *always* end with more timeouts and, ultimately,
an IO error?
If timeouts can sometimes be followed by successful retries, and re-trying
is the current default behavior, then I agree that introducing a setting
that effectively eliminates re-tries should be the developer's choice.
In that case, I suggest that the option should not be a low-level choice of
"handle the metadata in a way that eliminates retries" but should be higher
level, like "when attempting to connect, try only once, instead of
re-trying (the default behavior)."
-Dave

On Thu, Sep 17, 2020 at 7:42 AM Alberto Bustamante Reyes
 wrote:

> Hi geode-dev,
>
> I have a question about the c++ client.
>
> Some months ago we merged GEODE-8231 to solve a problem we observed
> regarding the native client was trying to connect to stopped server.
> GEODE-8231 solution consists on remove the client metadata when an "IO
> error in handshake" exception is received. This fix solved most of our
> problems, but it has been observed that sometimes when a server is stopped
> the errors received in the client are not the same and this "IO error in
> handshake" takes up to a minute to appear. So during that time, the client
> is still trying to connect to the offline server.
>
> As the error received during that time is "timeout in handshake", we have
> tested modyfing the solution of GEODE-8213 to make the client to remove 
the
> metadata once a timeout error is received (here is a draft with the code:
> 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Fpull%2F651data=02%7C01%7Cbblake%40vmware.com%7Cee9cfd61173047c7247808d85b27c3c8%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637359573636742453sdata=FUhQIAalNs0PK4vFvgnVZPV55cLPykD2cvDRwgRrNj0%3Dreserved=0).
 With this change in
> place, the behavior is ok.
>
>
> But I would like to check your opinion about this check, because this will
> cause that a single timeout will cause the removal of the client metadata,
> which maybe its not the best solution. I thought about different
> alternatives:
>
> - Wait until a given number of timeouts in a row have been received from
> the same server to remove the metadata
> - Make this "remove-metadata-after-timeout" something optional that could
> be configured if needed
>
> As this will misalign the behavior of Java and C++ clients, making this an
> optional configuration will be more appropriate, to keep the default c++
> client behavior as the Java client.
>
> BR/
>
> Alberto B.
>

Re: Proper location for debugging tools

[Blake Bender]

Right - I'm aware of that directory in Geode, just not sure this belongs 
there... yet(?).  I'll submit a PR for the native repo, and if I or someone 
else eventually adapts it for the Java client (low probability IMO), it can be 
moved easily.

Thanks,

Blake

On 9/11/20, 2:11 PM, "Dan Smith"  wrote:

The main geode repo has a dev-tools directory, that’s a good spot for 
scripts. If it’s specific to native client I’d put it in geode-native but if 
not the geode repo seems fine.

-Dan

> On Sep 11, 2020, at 1:41 PM, Blake Bender  wrote:
> 
> Hi all,
> 
> I have a Python script I’ve used quite a bit for diagnosing/debugging 
issues in geode-native that can decode a whole lot of protocol information from 
a debug-level log file.  I think it comes in pretty handy, and would like to 
share.  Just a quick question, though – where’s the right place to put it?  
It’s currently in a private repo, so I could create a new OSS repo for it, or I 
could do something like create a /tools folder in the native tree and submit it 
there in a PR.  There’s also a sort-of shared tools area in the Geode repo 
proper, which isn’t as odd a choice as it first seems, because the script could 
be enhanced pretty readily to read Java client logs and decode the same info.  
Anyone have any strongly-held opinions?
> 
> Thanks,
> 
> Blake
> 

Proper location for debugging tools

[Blake Bender]

Hi all,

I have a Python script I’ve used quite a bit for diagnosing/debugging issues in 
geode-native that can decode a whole lot of protocol information from a 
debug-level log file.  I think it comes in pretty handy, and would like to 
share.  Just a quick question, though – where’s the right place to put it?  
It’s currently in a private repo, so I could create a new OSS repo for it, or I 
could do something like create a /tools folder in the native tree and submit it 
there in a PR.  There’s also a sort-of shared tools area in the Geode repo 
proper, which isn’t as odd a choice as it first seems, because the script could 
be enhanced pretty readily to read Java client logs and decode the same info.  
Anyone have any strongly-held opinions?

Thanks,

Blake

Re: JIRA issues for geode native developers

[Blake Bender]

Working now - thanks, Dan!

On 8/21/20, 12:14 PM, "Dan Smith"  wrote:

It looks like they weren’t listed as committers in JIRA. I added them, you 
should be able to assign them issues now!

-Dan

> On Aug 21, 2020, at 11:00 AM, Blake Bender  wrote:
> 
> Hello,
> 
> In the course of attempting to be a better Geode citizen yesterday, I 
attempted to assign a JIRA issue to one of the members of the geode native 
full-time dev team, and discovered that I couldn’t.  In fact, neither of them 
(Mike Martell, Matthew Reddington) can be assigned GEODE JIRA issues.  Does 
anyone know what setting/permission/etc is missing there, and how to fix?
> 
> Thanks,
> 
> Blake
> 

JIRA issues for geode native developers

[Blake Bender]

Hello,

In the course of attempting to be a better Geode citizen yesterday, I attempted 
to assign a JIRA issue to one of the members of the geode native full-time dev 
team, and discovered that I couldn’t.  In fact, neither of them (Mike Martell, 
Matthew Reddington) can be assigned GEODE JIRA issues.  Does anyone know what 
setting/permission/etc is missing there, and how to fix?

Thanks,

Blake

Re: [VOTE] change Default branch for geode-examples to 'develop'

[Blake Bender]

FWIW, Geode Native works around this by not keeping a separate examples repo at 
all.  To build our examples, you *must* build your own Geode Native 
"installation," which includes the examples tree, or download the desired 
tarball/zip file from our GitHub releases.

I’m pretty much agnostic as to which way we should go for any particular 
repository, which is why I wrote "remove or rename" in the title of GEODE-8335. 
 Let's do the right thing for each repo, but not expend a ton of brain power on 
it.  I brought this up as a *small* gesture we should make in the name of 
kindness, not a large effort.

Thanks,

Blake
 

On 7/18/20, 2:42 AM, "Owen Nichols"  wrote:

Voting Results:
+1: 5 votes 
 0: 0 votes 
-1: 1 vote

The voting is successful by majority vote.  INFRA has completed the 
requested change and git clone g...@github.com:apache/geode-examples.git now 
checks out develop, making geode-examples consistent with all other geode- 
projects, and clearing the way to eliminate master from all projects if @Blake 
or anyone else would like to move forward on that.

Although it didn't seem to sway anyone else, let's still attempt to 
discuss/address @Anthony's concern that develop doesn't pair well with released 
versions of Geode.

Maybe the brew install + git clone workflow is not how we want to introduce 
an application developer to Geode.  We could suggest: if cloning from git, 
clone everything from git; if using released artifacts, use release artifacts 
for everything.  If mix-n-match is necessary, the README.md could explain how 
to check out the correct branch or tag (or specify the Geode version parameter 
in the gradle command) to match the installed version of Geode.

It's important and fundamental for application developers to be aware that 
client version must be <= server version, so perhaps it's beneficial to 
document that from the beginning.

Another idea might be improving the error message when the client version 
is too new?

We could also modify the release scripts to substitute the latest release 
version into the README as part of the release process, to keep the 
out-of-the-box experience as simple as copy-and-pasting a gradle command from 
the README.

@Anthony I'd be happy to pair with you on updating the README or any other 
scripts/documentation.

If anyone else has thoughts or ideas, please chime in.

On 7/14/20, 7:16 AM, "Anthony Baker"  wrote:

Consider the use case of an application developer who wants to run 
geode-examples against the latest geode release:

1) brew install apache-geode
2) git clone geode-examples
3) Get some runtime errors because geode-examples won’t connect to a 
previous geode release

At this point, you have to do some detective work to either download 
the geode-examples from the corresponding source release or switch over to the 
appropriate git tag.

I think there’s value in maintaining a default branch of geode-examples 
that tracks the latest release.

Anthony


> On Jul 9, 2020, at 9:39 PM, Owen Nichols  wrote:
> 
> A fresh checkout of geode and all but one geode- 
repos checks out develop as the Default branch.
> 
> The lone exception is geode-examples.  Please vote +1 if you are in 
favor of changing its Default branch to develop for consistency with the other 
repos and other reasons as per recent discussion[1].
> 
> [1] 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fx%2Fthread.html%2Frfec15c0a7d5d6d57beed90868dbb53e3bfcaabca67589b28585556ee%40%253Cdev.geode.apache.org%253Edata=02%7C01%7Cbblake%40vmware.com%7Cb2eb424632174cd66c2408d82afee313%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637306621505139591sdata=DWUOSFvwEnJDJytU7qSjrzFEzR8gzjIm96pXAOqnxUQ%3Dreserved=0

Re: Review needed for c++ client ticket

[Blake Bender]

Hi Alberto,

I've reached out to Jake to approve his review, then I'll merge this for you.  
Sorry for the delay.

Thanks,

Blake


On 7/23/20, 3:08 AM, "Alberto Bustamante Reyes" 
 wrote:

Hi,

Could someone please take a look at this c++ client PR? 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode-native%2Fpull%2F628data=02%7C01%7Cbblake%40vmware.com%7C642d90cada944bd7e52508d82ef047da%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637310956821127150sdata=BTTTnQRvOyKZoYFSePHmVMJccTME1oq1KerC6V62DO0%3Dreserved=0

It solves a problem reported in the users list: 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmarkmail.org%2Fthread%2Fgajd4ok65w227fhldata=02%7C01%7Cbblake%40vmware.com%7C642d90cada944bd7e52508d82ef047da%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637310956821127150sdata=QNPJPFtP30SzadDoTgFCDteSqX4u8UGR%2BnuWMcX4OoU%3Dreserved=0

Thanks,

Alberto B.

Re: Fate of master branch

[Blake Bender]

Just to follow up on this: I've filed GEODE-8335 
(https://issues.apache.org/jira/browse/GEODE-8335) to track, respectfully 
(cowardly __ ) deferring to individuals who regularly contribute to the various 
Geode repos to handle it as they see fit.  I'll take care of the several Geode 
Native associated repos.

Thanks,

Blake


On 6/26/20, 12:21 PM, "Dave Barnes"  wrote:

+1 if we can override git’s ‘master’ default and establish ‘develop’ in its 
place. Otherwise renaming to ‘main’ would solve the problem with the negative 
connotations.

NB: Mark, I think the 3-vote convention is just for back-ports to the 
release-branch. I don’t think of it as applying to a general discussion like 
this one.

> On Jun 26, 2020, at 9:42 AM, Anthony Baker  wrote:
> 
> By just do it, I assume you mean:
> 
> - Contact delete master where not needed
> - Rename master to main when needed
> - Contact INFRA to change the default branch
> - Update README and CI jobs as needed
> 
> Across *all* geode repos.
> 
> 
> Anthony
> 
> 
>> On Jun 26, 2020, at 9:38 AM, Mark Hanson  wrote:
>> 
>> +1 to delete. No good reason to keep it that I know of. I think I am the 
third +1 with no -1s so just do it.
>> 
>> Thanks,
>> Mark
>> 
>>> On Jun 26, 2020, at 9:13 AM, Alexander Murmann  
wrote:
>>> 
>>> +1 to deleting. Given we tag everything properly on the other branches, 
I
>>> don't see the need for it either.
>>> 
>>> On Fri, Jun 26, 2020 at 9:03 AM Alberto Bustamante Reyes
>>>  wrote:
>>> 
>>>> +1 for deleting master branch. An also for updating the wiki page about
>>>> branching that Alberto pointed out.
>>>> 
>>>> De: Bruce Schuchardt 
>>>> Enviado: viernes, 26 de junio de 2020 17:37
>>>> Para: dev@geode.apache.org 
>>>> Asunto: Re: Fate of master branch
>>>> 
>>>> Let's just delete it.  I need to do that in my own repos as well.
>>>> 
>>>> On 6/26/20, 8:05 AM, "Blake Bender"  wrote:
>>>> 
>>>>  Apologies if this has been addressed already and I missed it.  In
>>>> keeping with other OSS projects, I believe it’s time we did something 
about
>>>> removing the insensitive term master from Geode repositories.
>>>> 
>>>>  One choice a lot of projects appear to be going with is a simple
>>>> rename from master • main.  In our own case, however, master isn’t 
really
>>>> in use for anything vital.  We track releases with a tag and a branch 
to
>>>> backport fixes to, and the develop branch is the “source of truth”
>>>> latest-and-greatest version of the code.  We could thus simply delete
>>>> master with no loss I’m aware of.  Any opinions?
>>>> 
>>>>  Thanks,
>>>> 
>>>>  Blake
>>>> 
>>>> 
>>>> 
>> 
> 

Fate of master branch

[Blake Bender]

Apologies if this has been addressed already and I missed it.  In keeping with 
other OSS projects, I believe it’s time we did something about removing the 
insensitive term master from Geode repositories.

One choice a lot of projects appear to be going with is a simple rename from 
master • main.  In our own case, however, master isn’t really in use for 
anything vital.  We track releases with a tag and a branch to backport fixes 
to, and the develop branch is the “source of truth” latest-and-greatest version 
of the code.  We could thus simply delete master with no loss I’m aware of.  
Any opinions?

Thanks,

Blake

Re: [DISCUSSION] Stop using the Geode Repository for Feature/WIP Branches

[Blake Bender]

Sorry for a long delay, just catching up on a ton of dev mail this morning.  
FWIW, I agree that leaving feature/WIP branches in the main repository is bad 
practice.  The ease and flexibility of branching in Git leads to a strong 
tendency towards proliferation of these things, and we really ought to apply 
some discipline to the process to keep the repo history clean.

The detailed instructions on our Wiki re explicit re: use of forks for 
contributions.  All I see in the top-level "Contributing" page, however, is 
this:

>>> Use a pull request to submit a code patch to the github mirror. Any new 
>>> changes should be targeted at the "develop" branch.

Perhaps we should at least add a brief note here about forking?

Thanks,

Blake




On 6/11/20, 11:25 PM, "Jacob Barrett"  wrote:



> On Jun 11, 2020, at 8:41 PM, Owen Nichols  wrote:
> 
> -1 for “banning”

:facepalm: Sorry, poor choice of words. How about “strongly discouraged” 
because of the harm enumerated perviously. 

> 
> The Geode community has strong precedent for protecting developers’ 
freedom to choose what works best for them.

Not to the detriment of others in the community.

> Maybe check if your graphical git tool-of-choice allows a branch filter 
regex, or consider git clone --single-branch?

Whether someone filters or not the issues enumerated exist even if hidden 
away.

-Jake

Re: [VOTE] Using Github issues and wiki for geode-kafka-connector project

[Blake Bender]

GitHub Wiki supports Markdown, our current one does not.  This means GitHub
wins by default in my book.

Thanks,

Blake


On Thu, Apr 23, 2020 at 8:50 AM Anthony Baker  wrote:

> Naba, do you have any updates to share?  I’m curious if you have found
> this useful compared to JIRA.
>
> Also, I noticed that geode-kafka-connector also has a GitHub wiki.  How
> does that compare with centralizing our information in the ASF confluence
> wiki?
>
> Thanks,
> Anthony
>
>
> > On Mar 21, 2020, at 5:16 PM, Nabarun Nag  wrote:
> >
> > Hello team,
> >
> > We are planning to experiment with using Github issues and wiki for the
> > Apache project *Geode-Kafka-Connector. *(not Apache Geode project).
> Please
> > do give your vote on this as we need to send the vote link to infra to
> > activate it.
> >
> > *Why are we doing this ? / Advantages* :
> > 1. *Unified location* to have documentation, code and issue tracking.
> > 2. Leverage Github tools like Github pages to create websites hosting
> > information about the project.
> > 3. No separate JIRA accounts or permission required to create issues.
> > 4. This will have *no impact on the broader Geode community* as right now
> > only 3-4 developers involved in this project.
> > 5. *This is an experiment.* If things do not work out we can always
> revert
> > back to the traditional way of having separate JIRA, documentation,
> > websites etc.
> >
> > *Precedence*:
> > 1. Kubernetes uses the github issues
> > 2. RabbitMQ uses github issues.
> >
> >
> > *NOTE: *- Please be cordial and do not use any condescending language and
> > absolutely no bullying.
> > - Please treat this email as a professional business email and maintain
> > email etiquette while replying.
> >
> > Regards
> > Nabarun
>
>

Switching default branch in .net core repo

[Blake Bender]

Good morning,

We created a repo yesterday for the .net core client work, and the default
branch out of the gate is set to master.  I'd like to switch it to develop,
like the rest of the Geode repos, which apparently requires a quick
heads-up and a couple of +1s to go ahead with.  So... is everyone okay with
this change?

Thanks,

Blake

Re: RFC: Add C Bindings to Geode Native Client

[Blake Bender]

Hello everyone,

I neglected to put an end date on this RFC, but it's been open for 2+ weeks
now, and I believe we're close to (at?) consensus, so I would like to close
it out and move on ASAP.  If you still have anything urgent to add, please
reply here and let's hash it out.  All other things being equal, I'll
summarize anything left that needs it and move the RFC to 'Active' status
Monday morning (PDT).

Thanks,

Blake

Re: RFC: Add C Bindings to Geode Native Client

[Blake Bender]

Jake, to follow up on your previous comment re: consensus, after
face-to-face conversation I believe the following is our current status.

Agreed:
* Strong types with opaque struct pointers
* No complete structs in the API/ABI
* split shared libraries - one for C, one for C++, one mixed-mode assembly
for .net Framework
* We will prevent exceptions across the interface boundary.
* Namespacing/prefixing.  I've included an example of this in the updated
RFC.
* Pattern and naming conventions for 'new', 'delete', and class methods.
Also provided an example in RFC doc
* Strong types with opaque struct pointers
* No complete structs in the API/ABI

This leaves us with just the serialization left undefined.  I've added a
note about the general approach we intend to take, but a lot of the detail
will need to be determined when we get into the work itself, and I consider
it beyond the scope of this RFC.

Updated RFC is at
https://cwiki.apache.org/confluence/display/GEODE/Add+C+Bindings+to+Native+Client+Library
.

Thanks,

Blake


On Wed, Apr 1, 2020 at 7:06 PM Jacob Barrett  wrote:

> Agreed. It was sort of an inside joke. There used to be a ccache
> executable but that was deleted a long time ago. I am in no way advocating
> for ccache as the directory or library name.
>
> > On Apr 1, 2020, at 2:48 PM, Robert Houghton 
> wrote:
> >
> > Quick note: ccache is a C/C++ compiler cache. Examples using 'ccache' as
> > the name are confusing.
> >
> >> On Tue, Mar 31, 2020 at 3:56 PM Jacob Barrett 
> wrote:
> >>
> >>
> >>
> >>>> On Mar 31, 2020, at 3:06 PM, Blake Bender  wrote:
> >>>
> >>> We in this instance means the native client team.  As far as specific
> >>> comments, I'm going to suggest we not go down that road, because this
> >> feels
> >>> a little more adversarial to me than it needs to be already.
> >>
> >> Sorry it feels adversarial. From below I think there is a
> misunderstanding
> >> of my preferences.
> >>
> >>> Suffice to
> >>> say that from my own perspective, in both what you wrote and what I got
> >>> from our in-person conversation on Monday, your answer to the general
> >>> question "Should the C bindings be part of the native client?" appeared
> >> to
> >>> be no, thus a separate repository seemed a perfectly reasonable
> >>> assumption.  I had hoped to do this in the geode-native repo to begin
> >> with,
> >>> so your assent to this makes life easier.
> >>
> >> This may be the point of confusion because I have never intended to give
> >> the impression that the C-bindings should be separate from the
> geode-native
> >> repo. My examples even integrate it with the geode-native project. I do
> >> believe it should be separate sources and separate includes. I would not
> >> want to be doing a C++ project and have C functions clouding my IDE or
> >> vice versa. Perhaps that is where the confusion comes from.
> >>
> >>> As far as my concerns about inefficiency, what I meant is essentially
> yes
> >>> we have multiple copies of the same code in the release, and this
> always
> >>> makes me a little uneasy.  I've seen a lot of compatibility bugs in my
> >>> career having to do with different products having different versions
> of
> >>> the same code, so my natural inclination is to avoid it when possible.
> >>> Having both C++ and C-style functions exported from the same library
> >>> doesn't give me any heartburn at all, so simply compiling the C
> bindings
> >>> into the existing shared library just means one less copy of the code
> in
> >>> the installation.  I fear I am in the minority in this opinion,
> however,
> >>> and it's not something I'm really doctrinaire about, so I'll defer.
> >> I would really like to understand your concerns but I don’t understand
> how
> >> combining the symbols into a single file resolves the versioning issue?
> Can
> >> your help me understand what the different produces with different
> versions
> >> means and how it would apply to this case?
> >>
> >> If the C and C++ symbols are both exported from the same shared library
> >> would you have a common include directory as well or would you spit the
> >> includes? I could live with a combine library but not a combined include
> >> headers.
> >>
> >>> So are we good here?  I'd like to get the RFC wrapped up and move on to
> >>> building this.
> >>
> >> Do you feel th

Re: RFC: Add C Bindings to Geode Native Client

[Blake Bender]

We in this instance means the native client team.  As far as specific
comments, I'm going to suggest we not go down that road, because this feels
a little more adversarial to me than it needs to be already.  Suffice to
say that from my own perspective, in both what you wrote and what I got
from our in-person conversation on Monday, your answer to the general
question "Should the C bindings be part of the native client?" appeared to
be no, thus a separate repository seemed a perfectly reasonable
assumption.  I had hoped to do this in the geode-native repo to begin with,
so your assent to this makes life easier.

As far as my concerns about inefficiency, what I meant is essentially yes
we have multiple copies of the same code in the release, and this always
makes me a little uneasy.  I've seen a lot of compatibility bugs in my
career having to do with different products having different versions of
the same code, so my natural inclination is to avoid it when possible.
Having both C++ and C-style functions exported from the same library
doesn't give me any heartburn at all, so simply compiling the C bindings
into the existing shared library just means one less copy of the code in
the installation.  I fear I am in the minority in this opinion, however,
and it's not something I'm really doctrinaire about, so I'll defer.

So are we good here?  I'd like to get the RFC wrapped up and move on to
building this.

Thanks,

Blake


On Tue, Mar 31, 2020 at 2:03 PM Jacob Barrett  wrote:

>
>
> > On Mar 31, 2020, at 1:48 PM, Matthew Reddington 
> wrote:
> >
> > A separate repo is our interpretation of the comments generated by this
> RFC.
>
> Can you please quote specific statements that you interpreted to suggest
> separate repositories. I would like to understand where this interpretation
> comes from.
>
> > We consider these separate projects and that they should be organized as
> such.
>
> Who is we? Does the we reflect the owners of the comments you are
> referencing above?
>
> In the end Geode is a single project in the eyes of ASF.
>
> -Jake
>
>

Re: RFC: Add C Bindings to Geode Native Client

[Blake Bender]

Just want to make sure I understand what you're after here.  We should have
a "ccache" directory or similar in the geode-native repo, where we build C
bindings for the client, then we should compile them into a shared library
containing all of the code, and export/make visible only the C interface?
So the geode native installer will contain shared libraries representing 3
copies of all the code, with the static library in the build tree making a
total of 4?

I'm starting to be concerned with the overall inefficiency of this plan.
 Is this the best we can do?

Thanks,

Blake


On Tue, Mar 31, 2020 at 12:05 PM Jacob Barrett  wrote:

> Given that the C-binding will be tightly coupled with the C++ layer and
> written in C++ I don’t think it make sense to have its own repository. In
> order for the C-binding need to access internal, non-exported methods, for
> things like serialization it will need to be statically linked to the C++
> library. If we use separate repositories and builds then we need to build a
> static library for the dependency in the C-binding library. This seems
> overly complicated to me for little to no gain. Can you please elaborate on
> the the pros of having a separate repository for the C-binding?
>
> For sure agree on the .net core repo. Tough depending on the mixed mode
> binary support we still might run into the dependency issues on static
> library.
>
> -Jake
>
>
> > On Mar 31, 2020, at 11:23 AM, Matthew Reddington 
> wrote:
> >
> > I would like to request the addition of two new repositories under
> Apache in order to implement this RFC and to take advantage of it in
> practice. That would be Apache/geode-c-client and
> Apache/geode-dot-net-core-client.
> >
> >> On Mar 30, 2020, at 3:33 PM, Jacob Barrett  wrote:
> >>
> >>
> https://github.com/pivotal-jbarrett/geode-native/tree/ee34cfbb5bddb55f5f890bb013c75d7780a787ae/ccache
> <
> https://github.com/pivotal-jbarrett/geode-native/tree/ee34cfbb5bddb55f5f890bb013c75d7780a787ae/ccache
> >
> >>
> >> Quick stab at a POC for thread exception handling.
> >>
> >> -Jake
> >>
> >
>
>

Re: [VOTE] Apache Geode 1.12.0.RC4

[Blake Bender]

We’re a little late to the party, but FWIW native client is also a +1.
Mike Martell ran native tests on Windows, and Vince Ford validated it on
Mac.

Thanks,

Blake


On Mon, Mar 30, 2020 at 3:00 PM Ernest Burghardt 
wrote:

> It's past the announced deadline and we have enough votes to close the
> vote.
>
> Voting status
> ==
> +1: 4 binding votes
> * Anthony Baker (PMC member)
> * Dave Barnes (PMC member)
> * John Blum (PMC member)
> * Dan Smith (PMC member)
>
> +0: zero votes
>
> -0: zero votes
>
> -1: zero votes
>
> The voting meets the requirements of at least 3 PMC members with +1 votes
> and has the required majority of +1 votes.
> Apache Geode 1.12.0.RC4 passed the vote and we will finalize the release
> shortly.
>
> Thanks everyone for the great work!
>
> - EB
>
> On Mon, Mar 30, 2020 at 7:54 AM Dave Barnes  wrote:
>
> > +1
> > Successfully built User Guide with the provided Docker-based toolset.
> > Successfully built javadocs.
> >
> > On Fri, Mar 27, 2020 at 2:56 PM Dan Smith  wrote:
> >
> > > +1
> > >
> > > Ran my release check
> > > https://github.com/upthewaterspout/geode-release-check
> > >
> > > -Dan
> > >
> > > On Fri, Mar 27, 2020 at 1:33 PM John Blum  wrote:
> > >
> > > > SDG continues to build with the Apache Geode 1.12.0 RC4 bits.
> > > >
> > > > https://jenkins.spring.io/job/spring-data-geode/job/master-next/16/
> > > >
> > https://github.com/spring-projects/spring-data-geode/commits/master-next
> > > >
> > > > +1
> > > >
> > > >
> > > > On Fri, Mar 27, 2020 at 1:23 PM Anthony Baker 
> > wrote:
> > > >
> > > > > +1
> > > > >
> > > > > Things I checked:
> > > > > - expected files present
> > > > > - hashes and signatures present and valid
> > > > > - geode, geode-benchmarks, and geode-examples build from source
> > > > > - no binaries present in source distributions
> > > > > - verified that geode source and binary distributions have the
> > correct
> > > > > SHA's
> > > > > - able to create a cluster and do region operations using gfsh
> > > > > - brief license review, no Cat X dependencies found
> > > > >
> > > > > Nitpicking:
> > > > >
> > > > > 1) Let's be consistent with names of source distribution and
> > > extensions.
> > > > > 2) NOTICE file copyright date needs to be updated for -native,
> > > > > -benchmark, -examples.
> > > > > 3) Some of the version numbers in LICENSE need to updated to match,
> > > > > also need to add asm-5.0.4.jar
> > > > >
> > > > > Anthony
> > > > >
> > > > > On Fri, Mar 27, 2020 at 11:37 AM Ernest Burghardt <
> > > eburgha...@pivotal.io
> > > > >
> > > > > wrote:
> > > > > >
> > > > > > Hello Geode Dev Community,
> > > > > >
> > > > > > This is a release candidate for Apache Geode version 1.12.0.RC4.
> > > > > > Thanks to all the community members for their contributions to
> this
> > > > > release!
> > > > > >
> > > > > > Please do a review and give your feedback, including the checks
> you
> > > > > > performed.
> > > > > >
> > > > > > Voting deadline:
> > > > > > 3PM PST Mon, March 30, 2020.
> > > > > >
> > > > > > Please note that we are voting upon the source tag:
> > > > > > rel/v1.12.0.RC4
> > > > > >
> > > > > > Release notes:
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.12.0
> > > > > >
> > > > > > Source and binary distributions:
> > > > > > https://dist.apache.org/repos/dist/dev/geode/1.12.0.RC4/
> > > > > >
> > > > > > Maven staging repo:
> > > > > >
> > > https://repository.apache.org/content/repositories/orgapachegeode-1068
> > > > > >
> > > > > > GitHub:
> > > > > > https://github.com/apache/geode/tree/rel/v1.12.0.RC4
> > > > > > https://github.com/apache/geode-examples/tree/rel/v1.12.0.RC4
> > > > > > https://github.com/apache/geode-native/tree/rel/v1.12.0.RC4
> > > > > > https://github.com/apache/geode-benchmarks/tree/rel/v1.12.0.RC4
> > > > > >
> > > > > > Pipelines:
> > > > > >
> > > > >
> > > >
> > >
> >
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-12-0-main
> > > > > >
> > > > >
> > > >
> > >
> >
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-12-0-rc
> > > > > >
> > > > > > Geode's KEYS file containing PGP keys we use to sign the release:
> > > > > > https://github.com/apache/geode/blob/develop/KEYS
> > > > > >
> > > > > > Command to run geode-examples:
> > > > > > ./gradlew -PgeodeReleaseUrl=
> > > > > > https://dist.apache.org/repos/dist/dev/geode/1.12.0.RC4
> > > > > > -PgeodeRepositoryUrl=
> > > > > >
> > > https://repository.apache.org/content/repositories/orgapachegeode-1068
> > > > > > build runAll
> > > > > >
> > > > > > Regards
> > > > > > Ernie Burghardt
> > > > >
> > > >
> > > >
> > > > --
> > > > -John
> > > > Spring Data Team
> > > >
> > >
> >
>

Re: RFC: Add C Bindings to Geode Native Client

[Blake Bender]

Just want to +1 on the use of a dynamic library - this really has to be a
shared lib, interop with most other languages demands it.  On the other
hand, I'm not a huge fan of making this a separate library from the native
client itself, simply because proliferation of binary files makes life
difficult for our users.  native client on Windows already uses a
mixed-mode assembly to avoid having separate C++ and .net DLLs, *and* we're
potentially lugging around cryptoimpl with us if someone wishes to use
SSL.  Adding another library just for C bindings makes for a clean
separation of the APIs, but I'm not certain how much value this adds, and
it definitely adds complexity to any installation/setup.

I've experienced firsthand the problems of exceptions thrown (or attempting
to be thrown, anyway) across the interface boundary.  It doesn't work, to
put it mildly, so for sure we'll have to address the issue.

I've updated the doc to reflect the latest thinking based on this
conversation.  Let me know if you still think we need more.

Thanks,

Blake


On Mon, Mar 30, 2020 at 7:01 AM Jacob Barrett  wrote:

>
>
> > On Mar 27, 2020, at 4:04 PM, Matthew Reddington 
> wrote:
> > * C does not have namespaces or overloading, so we will need a naming
> convention to differentiate our types and methods from any other library or
> the application code. That means all types and functions should be
> prepended with “geode_” or something similar.
>
> Ha… I knew there was something on my list I forgot to mention. Yes, all
> methods need to be prefixed. I recall there being something around Apache
> branding that required us to use apache::geode:: as our base namespace
> rather than just geode::. Same would hold true for this prefix also then. I
> would suggest apache_geode_X. The method names get pretty long so it may be
> worth double checking that geode_ is sufficient.
>
> > * We must absolutely produce a dynamic library. Not all FFI’s support
> static linking.
>
> Yeah, I have changed my mind on that. Ideally we would produce both but
> dynamic only is fine for now. Given the source release nature of Apache
> anyway this doesn’t really matter. Anyone could pull the source and build a
> static lib as needed.
>
> > * I recommend we avoid introducing real types in the exported interface.
> In order to support future revision, we’d have to introduce version and
> size information into the struct a la THE WIN32 API. Remember that? Having
> to zero out the struct then setting the size and version members before the
> other members? This is why they did that.
>
> What is this in reference to? Using structs to hold the pointers? I
> already over that solution for just using opaque struct pointers.
>
> > * The implementation needs to guard against throwing exceptions across
> the library boundary.
>
> I was wondering about this. It feels like all these wrappers should catch
> exceptions and convert them to a known set of int error codes, which are
> either returned or passed by reference on the functions. None of that makes
> for really clean readable C code but then again its C.
>
> > * This library needs a thread safe means of error handling. There is not
> enough fleshed out in this RFC to have a meaningful conversation about this
> at this time.
>
> Can you elaborate on this? If the functions all returned some error code
> what thread safety issues are you thinking about? If we need to get more
> detail from the exception back to the caller we could use thread local
> storage for message string, stack, etc. Perhaps taking some lessons from
> JNI and having a few exception checking/clearing/description methods with
> thread safe storage.
>
> > * I would like to see an ability for the client to specify their own
> allocators. This would require an overhaul of the existing C++ ABI and may
> have an impact on our dependencies. This is another talk for a more
> complete RFC.
>
> I think this is out of scope for sure. As you state the current C++ API
> lacks this ability as well as all the internals. Future us issues.
>
> -Jake
>
>

RFC: Add C Bindings to Geode Native Client

[Blake Bender]

Hello everyone,

We'd like to add C bindings to the native client, in preparation for the
larger task of adding support for new languages, e.g. .net core.  Please
have a look at the proposal below and let me know what you think.

Thanks,

Blake


https://cwiki.apache.org/confluence/display/GEODE/Add+C+Bindings+to+Native+Client+Library

Need edit/add permissions on the Geode wiki

[Blake Bender]

Hello,

I am attempting to add an RFC to the wiki, and don't appear to have any
kind of write access.  Can someone help me out?

Thanks,

Blake

Re: PR Titles

[Blake Bender]

Don't we have a published checklist or guideline or something for this
already?  Including stuff like 'always prefix the PR title with a JIRA
ticket #,' etc?

On Mon, Mar 2, 2020 at 8:47 AM Owen Nichols  wrote:

> +1
>
> It’s easy to fix too!
>
> On Mon, Mar 2, 2020 at 8:34 AM Jacob Barrett  wrote:
>
> > Please use meaningful PR titles. When browsing the PRs or reading the
> > notifications, one shouldn’t have to decode your cryptic title. Consider
> > the title as the first line of you commit message.
> >
> > -Jake
> >
> >
>

Re: RFC - Logging to Standard Out

[Blake Bender]

+1 - this is also a todo item for the native client, I think.  NC has a bug
in logging which is in my top 3 for "most irritating," as well, which is
that logging actually starts *before* the logging system is initialized, so
even if you *do* configure a log file, if something happens in NC prior to
that it gets logged to stdout.  Similarly, logging can continue in NC
*after* the logger is shut down, and any logging after that also goes to
stdout.  I'm a big fan of making everything consistent, and this seems as
good a way as any.

Just FWIW, using the character '-' anywhere in a log file name for NC will
currently cause a segfault, so this will force us to fix that problem as
well.


On Wed, Jan 8, 2020 at 12:39 PM Jacob Barrett  wrote:

> Please see RFC for Logging to Standard Out.
>
> https://cwiki.apache.org/confluence/display/GEODE/Logging+to+Standard+Out
>  >
>
> Please comment by 1/21/2020.
>
> Thanks,
> Jake
>
>

Re: [DISCUSS] Proposal to require linear commit history on develop

[Blake Bender]

; > > trust
> > > > > >> rather
> > > > > >>> than unnecessary constraints...Being a committer enables you to
> > > more
> > > > > >> easily
> > > > > >>> make changes without needing to go through the patch submission
> > > > > process”.
> > > > > >>> I can see this as an argument against this proposal (perhaps
> even
> > > an
> > > > > >>> argument against any form of branch protection).
> > > > > >>>
> > > > > >>> In the scheme of things, this proposal makes very little
> > > difference.
> > > > > >> There
> > > > > >>> are still other ways to get non-compiling commits onto develop
> > > (e.g.
> > > > > >>> waiting a long time between running PR checks and merging to
> > > > develop).
> > > > > >>> What’s more important is working well together as a community.
> > So,
> > > > > >> perhaps
> > > > > >>> what’s best for the community is to encourage working on trust
> > > rather
> > > > > >> than
> > > > > >>> unnecessary constraints.
> > > > > >>>
> > > > > >>> -Owen
> > > > > >>>
> > > > > >>> On Dec 31, 2019, at 10:56 AM, Kirk Lund 
> > wrote:
> > > > > >>>
> > > > > >>> I'm happy to file multiple PRs when I need to merge multiple
> > > commits
> > > > to
> > > > > >>> develop.
> > > > > >>>
> > > > > >>> On Mon, Dec 30, 2019 at 5:45 PM Mark Hanson <
> mhan...@pivotal.io>
> > > > > wrote:
> > > > > >>>
> > > > > >>> This change to disable all but squash-merge would be really
> easy
> > to
> > > > > >>> revert. How about we try it for a while and see? If people
> decide
> > > it
> > > > is
> > > > > >>> really limiting them, we can change it back. Let’s do it for 1
> > > month
> > > > > and
> > > > > >>> see how it goes. Does that sound reasonable?
> > > > > >>>
> > > > > >>> Thanks,
> > > > > >>> Mark
> > > > > >>>
> > > > > >>> On Dec 30, 2019, at 5:25 PM, Owen Nichols  >
> > > > wrote:
> > > > > >>>
> > > > > >>> Given that we adopted <
> > > > > >>>
> > > > > >>>
> > > > > >>
> > > > >
> > > >
> > >
> >
> https://lists.apache.org/thread.html/c3eb5c028cb3a4d76024f928a7a33c0311228f5dbbcaa86287bf5826@%3Cdev.geode.apache.org%3E
> > > > > >>>>
> > > > > >>> and still wish to continue <
> > > > > >>>
> > > > > >>
> > > > >
> > > >
> > >
> >
> https://lists.apache.org/thread.html/8795697c1ad57068c053b48b4b1845005f3ade0be777e679eafe95db@%3Cdev.geode.apache.org%3E
> > > > > >>>>
> > > > > >>> having branch protection rules to ensure every commit landing
> in
> > > > > develop
> > > > > >>> has passed the required PR checks, it seems like that decision
> > > alone
> > > > > >>> mandates that we disable all merge mechanisms other than
> > > > > >> squash-and-merge.
> > > > > >>>
> > > > > >>>
> > > > > >>> Allowing merge commits or rebase merges bypasses branch
> > protection
> > > > for
> > > > > >>>
> > > > > >>> all commits other than the final one in the merge or rebase
> set.
> > > > Given
> > > > > >>> that we decided <
> > > > > >>>
> > > > > >>
> > > > >
> > > >
> > >
> >
> https://lists.apache.org/thread.html/1ba19d9aeb206148c922afdd182ba322d6f128bbb83983f2f72a108e@%3Cdev.geode.apache.org%3E
> > > > > >>>>
> > > > > >>> that bypassing PR checks should never be allowed, keeping this
> > > > loophole
> >

Re: [DISCUSS] Proposal to require linear commit history on develop

[Blake Bender]

Just FWIW, the situation described of having multiple commits in a single
PR with separate associated JIRA tickets is still kind of problematic.  It
could well be the case that the commits are interdependent, thus when
bisecting etc it's still not possible to revert the fix for a single
bug/feature/whatever atomically.  It's all good, though, I'm satisfied no
one's forcing me to adopt practice I'm opposed to.  Apologies for getting
my feathers a little ruffled, or if I ruffled anyone else's in return.

Thanks,

Blake


On Fri, Dec 20, 2019 at 12:18 PM Nabarun Nag  wrote:

> Hi Dan,
>
> When we do squash merge all the commit messages are preserved and also the
> co-authored tag works when we do squash merge.
> So the authorship and history are preserved.
>
> In my own personal experience and reverts and pinpointing regression
> failures are tough when the commits are spread out. Also, reverts are
> easier when it is just one commit while we are bisecting failures.
>
>
> Regards
> Naba
>
> On Fri, Dec 20, 2019 at 12:07 PM Dan Smith  wrote:
>
> > I'll change to -0.
> >
> > I think merge commits are a nice way to record history in some cases, and
> > can also be a way to avoid messy conflicts that come with rebase. Merge
> > commits also preserve authorship of commits (compared to squash-merge),
> > which I think is valuable as an open source community that is trying to
> > keep track of outside contributions.
> >
> > That said, if the rest of y'all feel it will help to disable the button,
> I
> > won't stand in the way.
> >
> > -Dan
> >
> > On Fri, Dec 20, 2019 at 11:50 AM Anthony Baker 
> wrote:
> >
> > > Whether we are talking about the geode/ repository or the geode-native/
> > > repository we are all one GEODE community.
> > >
> > > The idea of a native client team may matter in some contexts but in
> this
> > > space we are all GEODE contributors.
> > >
> > > Adopting a common approach across our repos will make it easier for new
> > > contributors to engage, learn our norms, and join our efforts.
> > >
> > > $0.02,
> > > Anthony
> > >
> > >
> > > > On Dec 20, 2019, at 11:32 AM, Blake Bender 
> wrote:
> > > >
> > > > Is this a policy the native client team must abide by, as well?  It
> > > varies
> > > > slightly with what we've been doing, and all other things being
> equal I
> > > see
> > > > no reason for us to change that.  If I am to have any measure of
> > control
> > > > over the nc repository, I will definitely enforce a 1:1
> correspondence
> > > > between commits to develop and JIRA tickets.  IMO, if your
> refactoring
> > > in a
> > > > PR is sufficiently large or complex that it's difficult to tease it
> out
> > > > from the bug you're fixing or feature you're implementing, it merits
> > its
> > > > own JIRA ticket and a separate PR.  If your "actual" fix then becomes
> > > > dependent on the refactored code, that's a price I'm willing to pay
> to
> > > keep
> > > > history clean.
> > > >
> > > > On the other hand, I see no real value in squashing to a single
> commit
> > > > prior to submitting a PR, since your view of the changes on GitHub is
> > > > essentially the same either way.  We haven't enforced this on the nc
> > > repo,
> > > > and I'd prefer to keep it that way.
> > > >
> > > > Thanks,
> > > >
> > > > Blake
> > > >
> > > >
> > > > On Fri, Dec 20, 2019 at 10:29 AM Jinmei Liao 
> > wrote:
> > > >
> > > >> Merge commit is the new contributor's default setting. When we are
> > > merging
> > > >> new contributor's PR, since we are so used to THINKING
> > > "squash-and-merge"
> > > >> is the default, we forgot to check what the button really says when
> we
> > > are
> > > >> merging other people's PR.
> > > >>
> > > >> On Fri, Dec 20, 2019 at 10:18 AM Ernest Burghardt <
> > > eburgha...@pivotal.io>
> > > >> wrote:
> > > >>
> > > >>> I'm a proponent of using squash-and-merge, and once a person has
> > chosen
> > > >>> this option once it comes up by default afterwards...
> > > >>>
> > > >>> Owen,  I don't think you have consensus to put forth this PR, there
> > are
> > > >&

Re: [DISCUSS] Proposal to require linear commit history on develop

[Blake Bender]

This was the part I was referring to, from the existing PR template:

> Update the PR template to change the text "Is your initial contribution
> a single, squashed commit” to “Is your initial contribution squashed for
> ease of review (e.g. a single commit, or a ‘refactoring’ commit plus a
> ‘fix’ commit)"

Either of these, while I guess not strictly required(?), is a change from
what SOP has been for native client.  We rebase onto the current develop
when submitting a PR, but don't pre-squash commits in any meaningful way,
because it's unnecessary.

The rest is fine - changing the default option to Squash & Merge is the
right thing to do IMO.

Thanks,

Blake


On Fri, Dec 20, 2019 at 12:00 PM Nabarun Nag  wrote:

> Just to reiterate. Nothing changes in the workflow of a developer. It's
> just in the end, when all the reviews are done and all the tests are
> passing, then the button to click in the Github web UI is "Squash and
> Merge". That's all.
>
> Regards
> Naba
>
>
>
> On Fri, Dec 20, 2019 at 11:55 AM Blake Bender  wrote:
>
> > Very well, then, I'll abide by the group consensus but am on the record
> as:
> > * strongly opposed to multi-commit PRs, because I believe it clutters
> > history, and
> > * also not a big fan of forcing devs to rebase and squash prior to
> > submitting a PR.  IMO this is busy work, and *may* in some small minority
> > of cases hide information that would be useful to reviewers.
> >
> > Thanks,
> >
> > Blake
> >
> >
> > On Fri, Dec 20, 2019 at 11:50 AM Anthony Baker 
> wrote:
> >
> > > Whether we are talking about the geode/ repository or the geode-native/
> > > repository we are all one GEODE community.
> > >
> > > The idea of a native client team may matter in some contexts but in
> this
> > > space we are all GEODE contributors.
> > >
> > > Adopting a common approach across our repos will make it easier for new
> > > contributors to engage, learn our norms, and join our efforts.
> > >
> > > $0.02,
> > > Anthony
> > >
> > >
> > > > On Dec 20, 2019, at 11:32 AM, Blake Bender 
> wrote:
> > > >
> > > > Is this a policy the native client team must abide by, as well?  It
> > > varies
> > > > slightly with what we've been doing, and all other things being
> equal I
> > > see
> > > > no reason for us to change that.  If I am to have any measure of
> > control
> > > > over the nc repository, I will definitely enforce a 1:1
> correspondence
> > > > between commits to develop and JIRA tickets.  IMO, if your
> refactoring
> > > in a
> > > > PR is sufficiently large or complex that it's difficult to tease it
> out
> > > > from the bug you're fixing or feature you're implementing, it merits
> > its
> > > > own JIRA ticket and a separate PR.  If your "actual" fix then becomes
> > > > dependent on the refactored code, that's a price I'm willing to pay
> to
> > > keep
> > > > history clean.
> > > >
> > > > On the other hand, I see no real value in squashing to a single
> commit
> > > > prior to submitting a PR, since your view of the changes on GitHub is
> > > > essentially the same either way.  We haven't enforced this on the nc
> > > repo,
> > > > and I'd prefer to keep it that way.
> > > >
> > > > Thanks,
> > > >
> > > > Blake
> > > >
> > > >
> > > > On Fri, Dec 20, 2019 at 10:29 AM Jinmei Liao 
> > wrote:
> > > >
> > > >> Merge commit is the new contributor's default setting. When we are
> > > merging
> > > >> new contributor's PR, since we are so used to THINKING
> > > "squash-and-merge"
> > > >> is the default, we forgot to check what the button really says when
> we
> > > are
> > > >> merging other people's PR.
> > > >>
> > > >> On Fri, Dec 20, 2019 at 10:18 AM Ernest Burghardt <
> > > eburgha...@pivotal.io>
> > > >> wrote:
> > > >>
> > > >>> I'm a proponent of using squash-and-merge, and once a person has
> > chosen
> > > >>> this option once it comes up by default afterwards...
> > > >>>
> > > >>> Owen,  I don't think you have consensus to put forth this PR, there
> > are
> > > >> -1s
> > > >>> above... (early voting)
> >

Re: [DISCUSS] Proposal to require linear commit history on develop

[Blake Bender]

Very well, then, I'll abide by the group consensus but am on the record as:
* strongly opposed to multi-commit PRs, because I believe it clutters
history, and
* also not a big fan of forcing devs to rebase and squash prior to
submitting a PR.  IMO this is busy work, and *may* in some small minority
of cases hide information that would be useful to reviewers.

Thanks,

Blake


On Fri, Dec 20, 2019 at 11:50 AM Anthony Baker  wrote:

> Whether we are talking about the geode/ repository or the geode-native/
> repository we are all one GEODE community.
>
> The idea of a native client team may matter in some contexts but in this
> space we are all GEODE contributors.
>
> Adopting a common approach across our repos will make it easier for new
> contributors to engage, learn our norms, and join our efforts.
>
> $0.02,
> Anthony
>
>
> > On Dec 20, 2019, at 11:32 AM, Blake Bender  wrote:
> >
> > Is this a policy the native client team must abide by, as well?  It
> varies
> > slightly with what we've been doing, and all other things being equal I
> see
> > no reason for us to change that.  If I am to have any measure of control
> > over the nc repository, I will definitely enforce a 1:1 correspondence
> > between commits to develop and JIRA tickets.  IMO, if your refactoring
> in a
> > PR is sufficiently large or complex that it's difficult to tease it out
> > from the bug you're fixing or feature you're implementing, it merits its
> > own JIRA ticket and a separate PR.  If your "actual" fix then becomes
> > dependent on the refactored code, that's a price I'm willing to pay to
> keep
> > history clean.
> >
> > On the other hand, I see no real value in squashing to a single commit
> > prior to submitting a PR, since your view of the changes on GitHub is
> > essentially the same either way.  We haven't enforced this on the nc
> repo,
> > and I'd prefer to keep it that way.
> >
> > Thanks,
> >
> > Blake
> >
> >
> > On Fri, Dec 20, 2019 at 10:29 AM Jinmei Liao  wrote:
> >
> >> Merge commit is the new contributor's default setting. When we are
> merging
> >> new contributor's PR, since we are so used to THINKING
> "squash-and-merge"
> >> is the default, we forgot to check what the button really says when we
> are
> >> merging other people's PR.
> >>
> >> On Fri, Dec 20, 2019 at 10:18 AM Ernest Burghardt <
> eburgha...@pivotal.io>
> >> wrote:
> >>
> >>> I'm a proponent of using squash-and-merge, and once a person has chosen
> >>> this option once it comes up by default afterwards...
> >>>
> >>> Owen,  I don't think you have consensus to put forth this PR, there are
> >> -1s
> >>> above... (early voting)
> >>>
> >>> maybe we'll be better off socializing the norm of squash-and-merge and
> >>> gaining a natural consensus that way...
> >>>
> >>> On Fri, Dec 20, 2019 at 10:07 AM Owen Nichols 
> >> wrote:
> >>>
> >>>> The proposed action manifests as a commit to the Geode git repository,
> >> so
> >>>> a PR is an acceptable vehicle for voting in this case.
> >>>>
> >>>>> On Dec 20, 2019, at 9:38 AM, Bruce Schuchardt <
> >> bschucha...@pivotal.io>
> >>>> wrote:
> >>>>>
> >>>>> I see a lot of plus-ones and a "voting deadline" on this DISCUSS
> >> thread
> >>>> and a request to "vote" using a PR.  This all seems out of order to
> me.
> >>>> Our votes are supposed to be on the email list, aren't they? and I
> >>> haven't
> >>>> seen a VOTE request.
> >>>>>
> >>>>> On 12/20/19 9:33 AM, Nabarun Nag wrote:
> >>>>>> +1
> >>>>>>
> >>>>>> On Fri, Dec 20, 2019 at 9:25 AM Owen Nichols 
> >>>> wrote:
> >>>>>>
> >>>>>>> Based on the feedback so far, I will amend the proposal to drop
> >> item
> >>>> 2).
> >>>>>>> Therefore, the current ability to create merge commits using
> >>>> command-line
> >>>>>>> git will remain available.
> >>>>>>>
> >>>>>>> The proposal as amended is now:
> >>>>>>>> Change GitHub settings to make "Squash and merge" the default
> >>>>>>>> (by removing “Create a merge commit” o

Re: [DISCUSS] Proposal to require linear commit history on develop

[Blake Bender]

Is this a policy the native client team must abide by, as well?  It varies
slightly with what we've been doing, and all other things being equal I see
no reason for us to change that.  If I am to have any measure of control
over the nc repository, I will definitely enforce a 1:1 correspondence
between commits to develop and JIRA tickets.  IMO, if your refactoring in a
PR is sufficiently large or complex that it's difficult to tease it out
from the bug you're fixing or feature you're implementing, it merits its
own JIRA ticket and a separate PR.  If your "actual" fix then becomes
dependent on the refactored code, that's a price I'm willing to pay to keep
history clean.

On the other hand, I see no real value in squashing to a single commit
prior to submitting a PR, since your view of the changes on GitHub is
essentially the same either way.  We haven't enforced this on the nc repo,
and I'd prefer to keep it that way.

Thanks,

Blake


On Fri, Dec 20, 2019 at 10:29 AM Jinmei Liao  wrote:

> Merge commit is the new contributor's default setting. When we are merging
> new contributor's PR, since we are so used to THINKING "squash-and-merge"
> is the default, we forgot to check what the button really says when we are
> merging other people's PR.
>
> On Fri, Dec 20, 2019 at 10:18 AM Ernest Burghardt 
> wrote:
>
> > I'm a proponent of using squash-and-merge, and once a person has chosen
> > this option once it comes up by default afterwards...
> >
> > Owen,  I don't think you have consensus to put forth this PR, there are
> -1s
> > above... (early voting)
> >
> > maybe we'll be better off socializing the norm of squash-and-merge and
> > gaining a natural consensus that way...
> >
> > On Fri, Dec 20, 2019 at 10:07 AM Owen Nichols 
> wrote:
> >
> > > The proposed action manifests as a commit to the Geode git repository,
> so
> > > a PR is an acceptable vehicle for voting in this case.
> > >
> > > > On Dec 20, 2019, at 9:38 AM, Bruce Schuchardt <
> bschucha...@pivotal.io>
> > > wrote:
> > > >
> > > > I see a lot of plus-ones and a "voting deadline" on this DISCUSS
> thread
> > > and a request to "vote" using a PR.  This all seems out of order to me.
> > > Our votes are supposed to be on the email list, aren't they? and I
> > haven't
> > > seen a VOTE request.
> > > >
> > > > On 12/20/19 9:33 AM, Nabarun Nag wrote:
> > > >> +1
> > > >>
> > > >> On Fri, Dec 20, 2019 at 9:25 AM Owen Nichols 
> > > wrote:
> > > >>
> > > >>> Based on the feedback so far, I will amend the proposal to drop
> item
> > > 2).
> > > >>> Therefore, the current ability to create merge commits using
> > > command-line
> > > >>> git will remain available.
> > > >>>
> > > >>> The proposal as amended is now:
> > >  Change GitHub settings to make "Squash and merge" the default
> > >  (by removing “Create a merge commit” option).
> > > 
> > >  Update the PR template to change the text "Is your initial
> > > contribution
> > >  a single, squashed commit” to “Is your initial contribution
> squashed
> > > for
> > >  ease of review (e.g. a single commit, or a ‘refactoring’ commit
> > plus a
> > >  ‘fix’ commit)"
> > > >>>
> > > >>> As Naba suggested, we can try it, and if we don’t like it, it’s
> > simple
> > > to
> > > >>> revert.
> > > >>>
> > > >>> I’ve create a PR for the proposed change here:
> > > >>> https://github.com/apache/geode/pull/4513
> > > >>>
> > > >>> Please use the PR to vote for against this proposal.  It will not
> be
> > > >>> merged before the VOTING DEADLINE of DEC 31 (if no -1’s at that
> time)
> > > >>>
> > >  On Dec 20, 2019, at 8:31 AM, Ju@N  wrote:
> > > 
> > >  +1
> > > 
> > >  On Fri 20 Dec 2019 at 16:18, Owen Nichols 
> > > wrote:
> > > 
> > > > Hi Bruce, this proposal will not waste a single second of your
> > > time.  It
> > > > just prevents people from accidentally pressing a button that we
> > have
> > > > already agreed should never be pressed, but because we never
> > > configured
> > > >>> our
> > > > GitHub to match our stated policy, is currently the default.
> > > >
> > > > However, it will save a lot of time and frustration for anyone
> > > needing
> > > >>> to
> > > > bisect failures, revert, or cherry-pick changes, which has merit
> > > even if
> > > > you personally never do any of those three things.
> > > >
> > > > Please start a separate thread if you would like to revisit the
> > > >>> community
> > > > decision to require passing PR checks.
> > > >
> > > >> On Dec 20, 2019, at 7:49 AM, Bruce Schuchardt <
> > > bschucha...@pivotal.io>
> > > > wrote:
> > > >> I agree with Jake.  I would go further by saying that I see very
> > > little
> > > > merit in this proposal.  I think we're getting more and more
> > > >>> bureaucratic
> > > > in our process and that it stifles productivity.  I was recently
> > > forced
> > > >>> to
> > > > spend three days fixing tests in which I had changed 

Re: Issues with TransactionIds managed by CacheTransactionManager in C++ native client

[Blake Bender]

Transactions are an area of the codebase I've never dealt with, so I'm sure
most/all of what you mention is true.  In particular, the only thing I know
about TransactionId is that it's always set to -1, so functionally it's
essentially useless.  I'm not certain what all of the implications will be
if suddenly we ascribe meaning to it, so I'll let some folks with more
native client history than I chime in.

Thanks,

Blake


On Fri, Dec 13, 2019 at 3:15 AM Alberto Gomez 
wrote:

> Hi,
>
> I have created a ticket with some issues I have found related to
> TransactionIds managed by CacheTransactionManager in the C++ native client.
>
> https://issues.apache.org/jira/browse/GEODE-7573
>
> In it, I also propose some solutions to the issues found.
>
> I'd appreciate if someone could review the analysis to see if I am in the
> right track or if I am missing something.
>
> Thanks in advance,
>
> Alberto
>

Importance of Diffie-Hellman support in native client?

[Blake Bender]

Please see https://issues.apache.org/jira/browse/GEODE-7302.  We have a
ticket to make a decision about whether or not to deprecate a couple of
properties here, and any knowledge of them has long since left the team.
Does anyone have a clue, or informed opinion, as to the importance of
keeping this support and the associated properties?

Thanks,

Blake

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

[Blake Bender]

-1 from native client as well, sorry.  RC3 mistakenly picked up an
unnecessary commit, and left out the crash fix I needed.  If you revert
commit 5d012199055a9a7657563727f6e26a406b287fc3 and
cherry-pick 55da853760c200c53568fe2e6549c912ec26cc27, "GEODE-7426: Fixes
segfault in log message.", native client should be good to go.

Thanks,

Blake



On Tue, Nov 26, 2019 at 11:35 AM Lynn Hughes-Godfrey <
lhughesgodf...@pivotal.io> wrote:

> -1: Analyzing a hang that looks similar to GEODE-5307: Hang with servers
> all in waitForPrimaryMember and one server in NO_PRIMARY_HOSTING state
> https://issues.apache.org/jira/browse/GEODE-5307
>
> On Mon, Nov 25, 2019 at 9:13 PM Mark Hanson  wrote:
>
> > Hello Geode Dev Community,
> >
> > This is a release candidate for Apache Geode version 1.11.0.RC3.
> > Thanks to all the community members for their contributions to this
> > release!
> >
> > Please do a review and give your feedback, including the checks you
> > performed.
> >
> > Voting deadline:
> > 11AM PST Monday December 2 2019.
> >
> > Please note that we are voting upon the source tag:
> > rel/v1.11.0.RC3
> >
> > Release notes:
> >
> >
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.11.0
> >
> > Source and binary distributions:
> > https://dist.apache.org/repos/dist/dev/geode/1.11.0.RC3/
> >
> > Maven staging repo:
> > https://repository.apache.org/content/repositories/orgapachegeode-1063
> >
> > GitHub:
> > https://github.com/apache/geode/tree/rel/v1.11.0.RC3
> > https://github.com/apache/geode-examples/tree/rel/v1.11.0.RC3
> > https://github.com/apache/geode-native/tree/rel/v1.11.0.RC3
> >
> > Pipelines:
> >
> >
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-11-0-main
> >
> >
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-11-0-rc
> >
> > Geode's KEYS file containing PGP keys we use to sign the release:
> > https://github.com/apache/geode/blob/develop/KEYS
> >
> > Command to run geode-examples:
> > ./gradlew -PgeodeReleaseUrl=
> > https://dist.apache.org/repos/dist/dev/geode/1.11.0.RC3
> > -PgeodeRepositoryUrl=
> > https://repository.apache.org/content/repositories/orgapachegeode-1063
> > build runAll
> >
> > Regards
> > Mark Hanson
>

Re: Help to reproduce GEODE-7060

[Blake Bender]

Hi Alberto,

I apologize for the mention of gemfire-node-client in OSS Geode JIRA, this
is a proprietary product that you don't have access to.  For the time
being, I believe, we have fixed all of the ACE leaks we've found, so
GEODE-7060 can be safely closed.

Just for context, we found that, on MacOS, if nativeclient items were
leaking at app shutdown and any of them contained an ACE object, certain of
these would leak an OS resource that couldn't be recovered.  Eventually
(typically after a number of test runs) this resource would run out, and
the only way to recover was to restart the OS.  We've since fixed a number
of "resource leak at shutdown" bugs in the native client, and haven't seen
GEODE-7060 in a couple of months or more.

Thanks,

Blake


On Mon, Nov 25, 2019 at 5:49 AM Alberto Bustamante Reyes
 wrote:

> Hi,
>
> I need some info to reproduce the issue described in GEODE-7060, about an
> ACE resource leak.
> The ticket says the problem was seen using a test called
> "gemfire-node-client putall.js", but I suppose that test is not part of
> Geode.
>
> Could someone with access to that test describe what it is doing? Any idea
> to reproduce the issue is welcome.
>
> Thanks in advance.
>
>
> Alberto B.
>

Re: [VOTE] Apache Geode 1.11.0.RC2

[Blake Bender]

We could also just tag the current NC develop branch.  I've run all my
integration tests from NC develop branch against 1.11.0.RC2, and it looks
good on Mac, Windows and Linux.


On Thu, Nov 21, 2019 at 11:25 AM Blake Bender  wrote:

> If it's a requirement that the native client runs properly, I'm a -1.
> There's a segfault bug in NC logging (see
> https://github.com/apache/geode-native/pull/545), and the release tag is
> prior to the fix.  I'd prefer to pick up NC from this commit:
> https://github.com/apache/geode-native/commit/c932a1d765809dcd8d7a0c0f14a3aa6c98e18a5c
> .
>
> Thanks,
>
> Blake
>
>
> On Wed, Nov 20, 2019 at 5:16 PM Mark Hanson  wrote:
>
>> Hello Geode Dev Community,
>>
>> This is a release candidate for Apache Geode version 1.11.0.RC2.
>> Thanks to all the community members for their contributions to this
>> release!
>>
>> Please do a review and give your feedback, including the checks you
>> performed.
>>
>> Voting deadline:
>> 3PM PST Mon, November 25 2019.
>>
>> Please note that we are voting upon the source tag:
>> rel/v1.11.0.RC2
>>
>> Release notes:
>>
>> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.11.0
>>
>> Source and binary distributions:
>> https://dist.apache.org/repos/dist/dev/geode/1.11.0.RC2/
>>
>> Maven staging repo:
>> https://repository.apache.org/content/repositories/orgapachegeode-1062
>>
>> GitHub:
>> https://github.com/apache/geode/tree/rel/v1.11.0.RC2
>> https://github.com/apache/geode-examples/tree/rel/v1.11.0.RC2
>> https://github.com/apache/geode-native/tree/rel/v1.11.0.RC2
>>
>> Pipelines:
>>
>> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-11-0-main
>>
>> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-11-0-rc
>>
>> Geode's KEYS file containing PGP keys we use to sign the release:
>> https://github.com/apache/geode/blob/develop/KEYS
>>
>> Command to run geode-examples:
>> ./gradlew -PgeodeReleaseUrl=
>> https://dist.apache.org/repos/dist/dev/geode/1.11.0.RC2
>> -PgeodeRepositoryUrl=
>> https://repository.apache.org/content/repositories/orgapachegeode-1062
>> build runAll
>>
>>
>>

Re: [VOTE] Apache Geode 1.11.0.RC2

[Blake Bender]

If it's a requirement that the native client runs properly, I'm a -1.
There's a segfault bug in NC logging (see
https://github.com/apache/geode-native/pull/545), and the release tag is
prior to the fix.  I'd prefer to pick up NC from this commit:
https://github.com/apache/geode-native/commit/c932a1d765809dcd8d7a0c0f14a3aa6c98e18a5c
.

Thanks,

Blake


On Wed, Nov 20, 2019 at 5:16 PM Mark Hanson  wrote:

> Hello Geode Dev Community,
>
> This is a release candidate for Apache Geode version 1.11.0.RC2.
> Thanks to all the community members for their contributions to this
> release!
>
> Please do a review and give your feedback, including the checks you
> performed.
>
> Voting deadline:
> 3PM PST Mon, November 25 2019.
>
> Please note that we are voting upon the source tag:
> rel/v1.11.0.RC2
>
> Release notes:
>
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.11.0
>
> Source and binary distributions:
> https://dist.apache.org/repos/dist/dev/geode/1.11.0.RC2/
>
> Maven staging repo:
> https://repository.apache.org/content/repositories/orgapachegeode-1062
>
> GitHub:
> https://github.com/apache/geode/tree/rel/v1.11.0.RC2
> https://github.com/apache/geode-examples/tree/rel/v1.11.0.RC2
> https://github.com/apache/geode-native/tree/rel/v1.11.0.RC2
>
> Pipelines:
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-11-0-main
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-11-0-rc
>
> Geode's KEYS file containing PGP keys we use to sign the release:
> https://github.com/apache/geode/blob/develop/KEYS
>
> Command to run geode-examples:
> ./gradlew -PgeodeReleaseUrl=
> https://dist.apache.org/repos/dist/dev/geode/1.11.0.RC2
> -PgeodeRepositoryUrl=
> https://repository.apache.org/content/repositories/orgapachegeode-1062
> build runAll
>
>
>

Re: [VOTE] Apache Geode 1.9.2.RC1

[Blake Bender]

Okay I'm convinced we're okay, so switching to a +1.  Standard PEBKAC error
here, I managed to produce a native client build which was missing the jar
file we use for a whole bunch of tests, so all failed.

Thanks,

Blake


On Wed, Oct 16, 2019 at 1:03 PM Blake Bender  wrote:

> I'm a -1 on this one, for the time being, sorry.  I ran native client
> integration tests against it on my dev workstation and am seeing an
> inordinate number of failures.  It's gonna take me some time to understand
> what's going on, but I'll update everyone shortly as to whether I think we
> have a real issue.
>
> Thanks,
>
> Blake
>
>
> On Tue, Oct 15, 2019 at 3:29 PM Udo Kohlmeyer  wrote:
>
>> Hi there Owen,
>>
>> Whilst I share your concern of consistence, the Geode user community did
>> not notice that the artifacts changed from war -> jar (GEODE-7241). The
>> Spring Data Geode project is currently the only downstream project which
>> discovered this regression.
>>
>> As Spring Data Geode 2.2 will not be using any other version than 1.9.x,
>> there is no dependency on 1.10.
>>
>> In addition to this, 1.11 is not that far off, and upon discovery of
>> this regression from 1.9.2 -> 1.10, we most likely could be pointing
>> them at 1.11 to upgrade.
>>
>> As for Spring 5 (GEODE-7261), I might agree that we might want to be
>> adding that to 1.10.1 patch, but so far I have not seen/heard of any
>> users hitting this issue. Maybe it would also fall into the category of
>> "wait for 1.11".
>>
>> --Udo
>>
>> On 10/15/19 3:05 PM, Owen Nichols wrote:
>> > I am concerned that this 1.9.2 release contains features that are not
>> in 1.10:
>> > GEODE-7241 Publish war artifacts for geode-web , geode-web-api and
>> geode-web-management to Maven Central.
>> > GEODE-7261 Fix compatibility with launching geode-web (admin REST API)
>> when Spring 5.x jars are on the classpath.
>> >
>> > My concern is that users of these 1.9.2 fixes will be surprised to
>> experience a regression when they upgrade to 1.10.0.
>> >
>> > This could be addressed by planning a 1.10.1 patch release, or maybe
>> just by documenting this caveat as long as the Spring Data project can
>> agree to skip over 1.10, but my non-binding vote is -1 until some plan is
>> in place.
>> >
>> > -Owen
>> >
>> >> On Oct 15, 2019, at 10:47 AM, Jens Deppe  wrote:
>> >>
>> >> Hello Geode Dev Community,
>> >>
>> >> This is a release candidate for Apache Geode version 1.9.2.RC1.
>> >> Thanks to all the community members for their contributions to this
>> release!
>> >>
>> >> Please do a review and give your feedback, including the checks you
>> >> performed.
>> >>
>> >> Voting deadline:
>> >> 3PM PST Sun, October 20 2019.
>> >>
>> >> Please note that we are voting upon the source tag:
>> >> rel/v1.9.2.RC1
>> >>
>> >> Release notes:
>> >>
>> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.2
>> >>
>> >> Source and binary distributions:
>> >> https://dist.apache.org/repos/dist/dev/geode/1.9.2.RC1/
>> >>
>> >> Maven staging repo:
>> >> https://repository.apache.org/content/repositories/orgapachegeode-1060
>> >>
>> >> GitHub:
>> >> https://github.com/apache/geode/tree/rel/v1.9.2.RC1
>> >> https://github.com/apache/geode-examples/tree/rel/v1.9.2.RC1
>> >> https://github.com/apache/geode-native/tree/rel/v1.9.2.RC1
>> >>
>> >> Pipelines:
>> >>
>> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-9-2-main
>> >>
>> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-9-2-rc
>> >>
>> >> Geode's KEYS file containing PGP keys we use to sign the release:
>> >> https://github.com/apache/geode/blob/develop/KEYS
>> >>
>> >> Command to run geode-examples:
>> >> ./gradlew -PgeodeReleaseUrl=
>> >> https://dist.apache.org/repos/dist/dev/geode/1.9.2.RC1
>> -PgeodeRepositoryUrl=
>> >> https://repository.apache.org/content/repositories/orgapachegeode-1060
>> >> build runAll
>> >>
>> >> Regards
>> >> --Jens
>> >
>>
>

Re: [VOTE] Apache Geode 1.9.2.RC1

[Blake Bender]

I'm a -1 on this one, for the time being, sorry.  I ran native client
integration tests against it on my dev workstation and am seeing an
inordinate number of failures.  It's gonna take me some time to understand
what's going on, but I'll update everyone shortly as to whether I think we
have a real issue.

Thanks,

Blake


On Tue, Oct 15, 2019 at 3:29 PM Udo Kohlmeyer  wrote:

> Hi there Owen,
>
> Whilst I share your concern of consistence, the Geode user community did
> not notice that the artifacts changed from war -> jar (GEODE-7241). The
> Spring Data Geode project is currently the only downstream project which
> discovered this regression.
>
> As Spring Data Geode 2.2 will not be using any other version than 1.9.x,
> there is no dependency on 1.10.
>
> In addition to this, 1.11 is not that far off, and upon discovery of
> this regression from 1.9.2 -> 1.10, we most likely could be pointing
> them at 1.11 to upgrade.
>
> As for Spring 5 (GEODE-7261), I might agree that we might want to be
> adding that to 1.10.1 patch, but so far I have not seen/heard of any
> users hitting this issue. Maybe it would also fall into the category of
> "wait for 1.11".
>
> --Udo
>
> On 10/15/19 3:05 PM, Owen Nichols wrote:
> > I am concerned that this 1.9.2 release contains features that are not in
> 1.10:
> > GEODE-7241 Publish war artifacts for geode-web , geode-web-api and
> geode-web-management to Maven Central.
> > GEODE-7261 Fix compatibility with launching geode-web (admin REST API)
> when Spring 5.x jars are on the classpath.
> >
> > My concern is that users of these 1.9.2 fixes will be surprised to
> experience a regression when they upgrade to 1.10.0.
> >
> > This could be addressed by planning a 1.10.1 patch release, or maybe
> just by documenting this caveat as long as the Spring Data project can
> agree to skip over 1.10, but my non-binding vote is -1 until some plan is
> in place.
> >
> > -Owen
> >
> >> On Oct 15, 2019, at 10:47 AM, Jens Deppe  wrote:
> >>
> >> Hello Geode Dev Community,
> >>
> >> This is a release candidate for Apache Geode version 1.9.2.RC1.
> >> Thanks to all the community members for their contributions to this
> release!
> >>
> >> Please do a review and give your feedback, including the checks you
> >> performed.
> >>
> >> Voting deadline:
> >> 3PM PST Sun, October 20 2019.
> >>
> >> Please note that we are voting upon the source tag:
> >> rel/v1.9.2.RC1
> >>
> >> Release notes:
> >>
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes#ReleaseNotes-1.9.2
> >>
> >> Source and binary distributions:
> >> https://dist.apache.org/repos/dist/dev/geode/1.9.2.RC1/
> >>
> >> Maven staging repo:
> >> https://repository.apache.org/content/repositories/orgapachegeode-1060
> >>
> >> GitHub:
> >> https://github.com/apache/geode/tree/rel/v1.9.2.RC1
> >> https://github.com/apache/geode-examples/tree/rel/v1.9.2.RC1
> >> https://github.com/apache/geode-native/tree/rel/v1.9.2.RC1
> >>
> >> Pipelines:
> >>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-9-2-main
> >>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-9-2-rc
> >>
> >> Geode's KEYS file containing PGP keys we use to sign the release:
> >> https://github.com/apache/geode/blob/develop/KEYS
> >>
> >> Command to run geode-examples:
> >> ./gradlew -PgeodeReleaseUrl=
> >> https://dist.apache.org/repos/dist/dev/geode/1.9.2.RC1
> -PgeodeRepositoryUrl=
> >> https://repository.apache.org/content/repositories/orgapachegeode-1060
> >> build runAll
> >>
> >> Regards
> >> --Jens
> >
>

Re: Propose including GEODE-7178 in 1.10

[Blake Bender]

+1, IMO this really needs to go in.

Thanks,

Blake


On Thu, Sep 12, 2019 at 3:30 PM Anthony Baker  wrote:

> My understanding is that this portion of the protocol is determined by
> instanceof checks, not the ordinal version.  The messages from the java
> client went through a different code path than messages from the native
> client.  So java clients using ordinal 45 still work (that’s why our
> backwards compatibility tests don’t fail).
>
> Anthony
>
>
> > On Sep 12, 2019, at 2:34 PM, Dan Smith  wrote:
> >
> > +1 for getting this in 1.10.
> >
> > I am curious though - is the native client behaving like an older
> versions
> > of the java client, or is this totally unique behavior for the native
> > client? Is there some integration test that we are missing here?
> >
> > -Dan
> >
> > On Thu, Sep 12, 2019 at 11:52 AM Michael Oleske 
> wrote:
> >
> >> Here is the Pull Request for the cherry pick as requested
> >> https://github.com/apache/geode/pull/4049
> >>
> >> -michael
> >>
> >> On Thu, Sep 12, 2019 at 10:28 AM Dick Cavender 
> >> wrote:
> >>
> >>> Hi Michael, thank you for bringing your concern and fixing this issue.
> >>>
> >>> Geode's release process dictates a time-based schedule <
> >>> https://cwiki.apache.org/confluence/display/GEODE/Release+Schedule> to
> >> cut
> >>> release branches.  The “critical fixes” rule does allow critical fixes
> to
> >>> be brought to the release branch by proposal on the dev list, as you
> have
> >>> done here.
> >>>
> >>> If there is consensus from the Geode community that your proposed
> change
> >>> satisfies the “critical fixes” rule, I will be happy to bring it to the
> >>> 1.10.0 release branch.
> >>>
> >>> Due to the complexity of this change, could please open a PR against
> >>> release/1.10.0 containing the exact changes you want to merge?
> >>>
> >>> Regards
> >>>
> >>> -Dick
> >>>
> >>>
> >>> On Thu, Sep 12, 2019 at 10:23 AM Anthony Baker 
> >> wrote:
> >>>
>  +1 yes please!
> 
> > On Sep 12, 2019, at 10:11 AM, Michael Oleske 
> >>> wrote:
> >
> > Hi Geode Devs!
> >
> > I'd like to propose including the fix for GEODE-7178.  This resolves
> >> an
> > issue that Ivan (https://markmail.org/message/dwwac42xmpo4xb2e) ran
>  into in
> > 1.10 RC1.
> >
> > SHA: 91176d61df64bf1390cdba7b1cdc2b40cdfaba3a
> > Link to GitHub:
> >
> 
> >>>
> >>
> https://github.com/apache/geode/commit/91176d61df64bf1390cdba7b1cdc2b40cdfaba3a
> >
> > Thanks!
> > -michael
> 
> 
> >>>
> >>
>
>

Re: Failed: apache/geode-native#2064 (rel/v1.9.1.RC2 - add53da)

[Blake Bender]

Looks like this branch was cut prior to Apache updating the RAT version to
0.13.  Someone needs to cherry-pick this commit:
https://github.com/apache/geode-native/commit/a58a1d74f398e1acf8b127804d43ea987b8d225d,
and it should be all good.

Thanks,

Blake


On Thu, Aug 29, 2019 at 6:30 PM Travis CI  wrote:

> Build Update for apache/geode-native
> -
>
> Build: #2064
> Status: Failed
>
> Duration: 1 hr, 34 mins, and 0 secs
> Commit: add53da (rel/v1.9.1.RC2)
> Author: Dave Barnes
> Message: User Guide: Add a link to the official XSD declarative cache
> schema
>
> View the changeset:
> https://github.com/apache/geode-native/compare/rel/v1.9.1.RC2
>
> View the full build log and details:
> https://travis-ci.org/apache/geode-native/builds/578595286?utm_medium=notification_source=email
>
> --
>
> You can unsubscribe from build emails from the apache/geode-native
> repository going to
> https://travis-ci.org/account/preferences/unsubscribe?repository=11948127_medium=notification_source=email
> .
> Or unsubscribe from *all* email updating your settings at
> https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification_source=email
> .
> Or configure specific recipients for build notifications in your
> .travis.yml file. See https://docs.travis-ci.com/user/notifications.
>
>

Re: Failed: apache/geode-native#2059 (rel/v1.9.1.RC1 - add53da)

[Blake Bender]

This looks spurious - apparently a download issue with Apache Rat jar
file.  I just ran Rat locally at this Git tag and it passed.

Thanks,

Blake


On Thu, Aug 22, 2019 at 7:33 PM Travis CI  wrote:

> Build Update for apache/geode-native
> -
>
> Build: #2059
> Status: Failed
>
> Duration: 1 hr, 39 mins, and 48 secs
> Commit: add53da (rel/v1.9.1.RC1)
> Author: Dave Barnes
> Message: User Guide: Add a link to the official XSD declarative cache
> schema
>
> View the changeset:
> https://github.com/apache/geode-native/compare/rel/v1.9.1.RC1
>
> View the full build log and details:
> https://travis-ci.org/apache/geode-native/builds/575617339?utm_medium=notification_source=email
>
> --
>
> You can unsubscribe from build emails from the apache/geode-native
> repository going to
> https://travis-ci.org/account/preferences/unsubscribe?repository=11948127_medium=notification_source=email
> .
> Or unsubscribe from *all* email updating your settings at
> https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification_source=email
> .
> Or configure specific recipients for build notifications in your
> .travis.yml file. See https://docs.travis-ci.com/user/notifications.
>
>

Re: Reviewers wanted for GEODE-7019 and GEODE-7049

[Blake Bender]

It looks like:
* 7049 is a Java change, not actually native client, so not really in my
wheelhouse, but...
* Jake has approved this already, so if another committer on the dev list
wants to merge it I believe it's ready.  Either way someone on the Java
side of the house needs to take a look

Thanks,

Blake


On Fri, Aug 9, 2019 at 9:05 AM Blake Bender  wrote:

> Sorry for the delay on 7019, I'll get it shepherded through ASAP.  I'll
> have a look at 7049 today as well.
>
> Thanks,
>
> Blake
>
>
> On Fri, Aug 9, 2019 at 2:24 AM Alberto Gomez 
> wrote:
>
>> Hi,
>>
>> I would need some extra reviewers for the following PRs:
>>
>> GEODE-7019 Idle connections are never closed by native C++ client library
>>
>> GEODE-7049 Add timeout parameter to Java native client
>> Execution::execute() methods
>>
>> Any volunteers?
>>
>> Thanks,
>>
>> Alberto
>>
>>

Re: Reviewers wanted for GEODE-7019 and GEODE-7049

[Blake Bender]

Sorry for the delay on 7019, I'll get it shepherded through ASAP.  I'll
have a look at 7049 today as well.

Thanks,

Blake


On Fri, Aug 9, 2019 at 2:24 AM Alberto Gomez  wrote:

> Hi,
>
> I would need some extra reviewers for the following PRs:
>
> GEODE-7019 Idle connections are never closed by native C++ client library
>
> GEODE-7049 Add timeout parameter to Java native client
> Execution::execute() methods
>
> Any volunteers?
>
> Thanks,
>
> Alberto
>
>

Re: geode-native ipv6

[Blake Bender]

This chunk of code in the client handshake code leads me to believe it is
still IPv4 only.  Won't say it's definitive, cause I'm not 100% certain
hostaddr is used on the server side, but still...

// writing first 4 bytes of the address. This will be same until
// IPV6 support is added in the client
uint32_t temp;
memcpy(, hostAddr, 4);
m_memID.writeInt(static_cast(temp));


On Thu, Aug 8, 2019 at 1:18 PM Jacob Barrett  wrote:

> We are on the latest ACE.
>
> > On Aug 8, 2019, at 9:56 AM, Mark Hanson  wrote:
> >
> > The latest ACE framework seems to have support, but I don’t know how far
> off latest we are. I don’t think we test anything in an IPv6 context, so I
> would say no that we don’t officially support it in the client. Given some
> time, I could do some testing..
> >
> > Thanks,
> > Mark
> >
> >> On Aug 8, 2019, at 7:35 AM, Blake Bender  wrote:
> >>
> >> I'm sure someone will chime in with a more definitive answer, but I'm
> >> pretty certain the answer is no, sorry.
> >>
> >> Thanks,
> >>
> >> Blake
> >>
> >>
> >>> On Thu, Aug 8, 2019 at 4:28 AM Mario Ivanac 
> wrote:
> >>>
> >>> Hi,
> >>>
> >>>
> >>> can you tell me does geode-native client support ipv6?
> >>>
> >>>
> >>> BR,
> >>>
> >>> Mario
> >>>
> >
>

Re: geode-native ipv6

[Blake Bender]

I'm sure someone will chime in with a more definitive answer, but I'm
pretty certain the answer is no, sorry.

Thanks,

Blake


On Thu, Aug 8, 2019 at 4:28 AM Mario Ivanac  wrote:

> Hi,
>
>
> can you tell me does geode-native client support ipv6?
>
>
> BR,
>
> Mario
>

Re: Problem with LGTM on geode-native pull request

[Blake Bender]

FWIW, I pushed the fix yesterday afternoon, so if you rebase to pick it up
LGTM will pass.  Thanks for your patience.

Blake


On Thu, Aug 1, 2019 at 9:36 AM Alberto Gomez  wrote:

> Having put it this way, I agree with you guys ;-)
>
> Thanks,
>
> -Alberto
>
> On 1/8/19 18:02, Blake Bender wrote:
> > I agree with Jake on this one.  From a bookkeeping perspective, what I'd
> > like to see in the history is a single commit that fixes all the LGTM
> > issues, and your fix for this bug in a separate commit.  I have a copy of
> > your .yml changes on my "fix LGTM" branch already, please back that
> change
> > out and we can merge your PR without LGTM passing.
> >
> > Thanks,
> >
> > Blake
> >
> >
> > On Thu, Aug 1, 2019 at 12:55 AM Alberto Gomez 
> > wrote:
> >
> >> Hi,
> >>
> >> I would not back out the LGTM changes added in the PR as they are
> >> necessary.
> >>
> >> - Alberto
> >>
> >> On 31/7/19 23:46, Jacob Barrett wrote:
> >>> I would say for this PR, back out the LGTM changes and just move
> forward
> >> ignoring the LGTM results.
> >>
>

Re: Problem with LGTM on geode-native pull request

[Blake Bender]

I agree with Jake on this one.  From a bookkeeping perspective, what I'd
like to see in the history is a single commit that fixes all the LGTM
issues, and your fix for this bug in a separate commit.  I have a copy of
your .yml changes on my "fix LGTM" branch already, please back that change
out and we can merge your PR without LGTM passing.

Thanks,

Blake


On Thu, Aug 1, 2019 at 12:55 AM Alberto Gomez 
wrote:

> Hi,
>
> I would not back out the LGTM changes added in the PR as they are
> necessary.
>
> - Alberto
>
> On 31/7/19 23:46, Jacob Barrett wrote:
> > I would say for this PR, back out the LGTM changes and just move forward
> ignoring the LGTM results.
>

Re: Problem with LGTM on geode-native pull request

[Blake Bender]

Still looking into this, don’t expect to have a resolution today
necessarily.  I turned off network support in our build of Xerces, since we
don’t use it, and that got rid of some, but not all, of the unresolved
references.  I’ll have to get hold of the LGTM Docker image to see what’s
going on with the rest of the issues.  I’m 100% convinced it’s not an issue
with this PR, though - develop branch has the same problem.

Thanks,

Blake


On Wed, Jul 31, 2019 at 7:08 AM Blake Bender  wrote:

> Linking errors look like (perhaps among other things) missing symbols for
> libcurl(?) needed by the Xerces library, which was recently added.  We
> build internally against RHEL 7, Ubuntu, Windows, and develop on MacBook
> Pros, but it appears LGTM is attempting to build on some other OS flavor
> and maybe missing some dependencies.  I'll investigate this morning.
>
> Thanks,
>
> Blake
>
>
> On Wed, Jul 31, 2019 at 5:38 AM Alberto Gomez 
> wrote:
>
>> Hi,
>>
>> I updated the .lgtm.yml file so that the right version of Apache Geode
>> is downloaded and now I get errors in the linking process about some
>> symbols not found.
>>
>> Could anybody help with this?
>>
>> Thanks,
>>
>> Alberto
>>
>> On 30/7/19 15:50, Jacob Barrett wrote:
>> > Yes, that seems to be the issue. Can you update the lgtm.yml and push
>> to your branch.
>> >
>> > Thanks,
>> > Jake
>> >
>> >
>> >> On Jul 30, 2019, at 5:09 AM, Alberto Gomez 
>> wrote:
>> >>
>> >> Hi,
>> >>
>> >> I am getting a failure on the C/C++ LGTM analysis over a recently
>> >> created pull request on geode-native:
>> >> https://github.com/apache/geode-native/pull/504
>> >>
>> >> I have noticed that this it the first PR on geode-native having LGTM
>> >> analysis.
>> >>
>> >> There is a .lgtm.yml on the repo that does not seem up to date as it
>> >> references Apache 1.7.0. This could be the source of the problem.
>> >>
>> >> Any ideas?
>> >>
>> >> Thanks in advance,
>> >>
>> >> -Alberto G.
>> >>
>>
>

Re: Problem with LGTM on geode-native pull request

[Blake Bender]

Linking errors look like (perhaps among other things) missing symbols for
libcurl(?) needed by the Xerces library, which was recently added.  We
build internally against RHEL 7, Ubuntu, Windows, and develop on MacBook
Pros, but it appears LGTM is attempting to build on some other OS flavor
and maybe missing some dependencies.  I'll investigate this morning.

Thanks,

Blake


On Wed, Jul 31, 2019 at 5:38 AM Alberto Gomez 
wrote:

> Hi,
>
> I updated the .lgtm.yml file so that the right version of Apache Geode
> is downloaded and now I get errors in the linking process about some
> symbols not found.
>
> Could anybody help with this?
>
> Thanks,
>
> Alberto
>
> On 30/7/19 15:50, Jacob Barrett wrote:
> > Yes, that seems to be the issue. Can you update the lgtm.yml and push to
> your branch.
> >
> > Thanks,
> > Jake
> >
> >
> >> On Jul 30, 2019, at 5:09 AM, Alberto Gomez 
> wrote:
> >>
> >> Hi,
> >>
> >> I am getting a failure on the C/C++ LGTM analysis over a recently
> >> created pull request on geode-native:
> >> https://github.com/apache/geode-native/pull/504
> >>
> >> I have noticed that this it the first PR on geode-native having LGTM
> >> analysis.
> >>
> >> There is a .lgtm.yml on the repo that does not seem up to date as it
> >> references Apache 1.7.0. This could be the source of the problem.
> >>
> >> Any ideas?
> >>
> >> Thanks in advance,
> >>
> >> -Alberto G.
> >>
>

Re: [DISCUSS] is it time to make Windows tests gating?

[Blake Bender]

+1 this needs to happen.  I hope that doesn't cause too much pain for the
dev team, but the native client team has a hard requirement that all our
stuff works properly on Windows at all times, and it can cause trouble if
random builds of the server can break us on Windows.

I would hesitate to run these per-commit if they're taking that long, but
daily is a thing that can easily happen.

On Thu, May 16, 2019 at 2:23 PM Bruce Schuchardt 
wrote:

> big +1, as long as artifacts of failed runs can be downloaded
>
> On 5/15/19 6:28 PM, Owen Nichols wrote:
> > For a very long time we’ve had Windows tests in the main pipeline
> (hidden away, not in the default view), but the pipeline proceeds to
> publish regardless of whether Windows tests fail or even run at all.
> >
> > Now seems like a good time to review whether to:
> > a) treat Windows tests as first-class tests and prevent the pipeline
> from proceeding if any test fails on Windows
> > b) keep as-is
> > c) change Windows tests to trigger only once a week rather than on every
> commit, if they are going to remain "informational only"
> >
> > One disadvantage to making Windows tests gating is that they currently
> take much longer to run (around 5 hours, vs 2 hours for Linux tests).
>

Re: Copying pdx types via client

[Blake Bender]

Okay, after a conversation here at the office with folks who know, I can
confirm the answer is "yes," NC has code to copy PDX types in the manner
you're asking after.

Thanks,

Blake


On Tue, Mar 26, 2019 at 8:43 AM Blake Bender  wrote:

> Hi Mike,
>
> I'm not 100% certain what you're referring to, but... PdxSerializable in
> NC has toData and fromData methods that allow you to copy objects via
> serialization.  That what you're looking for?
>
> Thanks,
>
> Blake
>
>
> On Mon, Mar 25, 2019 at 12:53 PM Michael Stolz  wrote:
>
>> Does this functionality exist in the Native Client as well as the Java
>> Client?
>>
>> --
>> Mike Stolz
>> Principal Engineer, GemFire Product Lead
>> Mobile: +1-631-835-4771
>>
>

Re: Copying pdx types via client

[Blake Bender]

Hi Mike,

I'm not 100% certain what you're referring to, but... PdxSerializable in NC
has toData and fromData methods that allow you to copy objects via
serialization.  That what you're looking for?

Thanks,

Blake


On Mon, Mar 25, 2019 at 12:53 PM Michael Stolz  wrote:

> Does this functionality exist in the Native Client as well as the Java
> Client?
>
> --
> Mike Stolz
> Principal Engineer, GemFire Product Lead
> Mobile: +1-631-835-4771
>

Re: [VOTE] Apache Geode 1.8.0 RC1

[Blake Bender]

I can look into the files missing license headers when I get home (probably
in an hour or so).  The cmake-build-debug directory is a thing left behind
by JetBrains products, so probably just developer cruft.  There’s
apparently a doc change I have to cherry-pick over to the release branch as
well, so I will coordinate with Dave on that.  Probably this works best if
I sit down briefly with Alexander in the morning and produce the new
archive, does that work?

Thanks,

Blake


On Mon, Dec 3, 2018 at 2:27 PM Dan Smith  wrote:

> -1 for the this RC based on these native source issues:
>
> * Missing license headers: native_shared_ptr.hpp and others listed by
> travis)
> * Binary executables in the source distribution: cmake-build-debug
> * The source distribution is somehow missing this directory:
> docs/geode-native-book/master_middleman/source/subnavs
>
> -Dan
>
>
> On Mon, Dec 3, 2018 at 1:43 PM Dan Smith  wrote:
>
> > I see some issues with the native source release that I think are a
> > problem.
> >
> > I looked into the travis for the native code - it looks like travis is
> > passing, but finding files with missing license headers? Eg
> > /geode-native/clicache/src/native_shared_ptr.hpp.
> > https://travis-ci.org/apache/geode-native/jobs/462048991
> >
> > I also see some binary executable files in the native source
> distribution,
> > which I don't even see in github.  Is this cruft from somone's build
> > workspace?
> > ./cmake-build-debug/CMakeFiles/3.12.3/CMakeDetermineCompilerABI_CXX.bin:
> > Mach-O 64-bit executable x86_64
> > ./cmake-build-debug/CMakeFiles/3.12.3/CMakeDetermineCompilerABI_C.bin:
> > Mach-O 64-bit executable x86_64
> > ./cmake-build-debug/CMakeFiles/3.12.3/CompilerIdC/a.out: Mach-O 64-bit
> > executable x86_64
> > ./cmake-build-debug/CMakeFiles/3.12.3/CompilerIdCXX/a.out: Mach-O 64-bit
> > executable x86_64
> > ./cmake-build-debug/CMakeFiles/feature_tests.bin: Mach-O 64-bit
> executable
> > x86_64
> >
> > Regarding the java parts of the release - I think the java bits look okay
> > now. I dug up the old email conversation and we did agree to remove the
> zip
> > distribution. The new signatures look good.
> >
> > -Dan
> >
> >
> >
> > On Mon, Dec 3, 2018 at 12:02 PM Alexander Murmann 
> > wrote:
> >
> >> Thanks again for all the input!
> >>
> >> Both Geode and Geode Native source distributions are now signed with an
> >> armored signature.
> >> Release manager docs are updated accordingly.
> >>
> >> I also added tickets to make the geode build also the sign source
> release
> >>  and increase the
> >> checksum to SHA 512 for core
> >>  and examples
> >> .
> >>
> >> If we agree on not having a ZIP file for core and native we should be
> >> consistent in the next release and remove the ZIPs form examples as
> well.
> >>
> >> On Mon, Dec 3, 2018 at 10:23 AM Robert Houghton 
> >> wrote:
> >>
> >> > +1. Thanks Owen
> >> >
> >> > On Mon, Dec 3, 2018, 10:07 Owen Nichols  >> >
> >> > > > 2. No zip file for the geode, just .tgz.
> >> > >
> >> > > I believe this was changed a few months ago to simplify our build
> and
> >> > > release process.  Distributing as both .zip and .tgz is a relic of a
> >> time
> >> > > before WinZip, WinRar, 7-Zip, and most other popular zip utilities
> >> gained
> >> > > native support for .tgz archives.  If there is still a segment of
> the
> >> > Geode
> >> > > user community that would suffer hardship due to lack of .zip
> >> packaging,
> >> > we
> >> > > should revisit this decision.
> >> > >
> >> > > -Owen
> >> > >
> >> > >
> >> > > > On Dec 3, 2018, at 9:52 AM, Dan Smith  wrote:
> >> > > >
> >> > > > I see a few things with the artifacts that I think should be
> tweaked
> >> > > > 1. No pgp signature for the sources!
> >> > > > 2. No zip file for the geode, just .tgz. Older releases on our
> >> website
> >> > > have
> >> > > > both zip and tgz. See the differences between [1] and [2]
> >> > > > 3. pgp signature for the native source is not ascii armored. See
> [3]
> >> > > >
> >> > > > Regarding SHA512 vs SHA256 - we should probably just move
> >> everything to
> >> > > > SHA512 in the future.
> >> > > >
> >> > > > [1] https://dist.apache.org/repos/dist/dev/geode/1.8.0.RC1/
> >> > > > [2] https://www.apache.org/dist/geode/1.7.0/
> >> > > > [3]
> https://www.apache.org/dev/release-signing.html#signing-basics
> >> > > >
> >> > > > On Mon, Dec 3, 2018 at 9:24 AM Alexander Murmann <
> >> amurm...@pivotal.io>
> >> > > > wrote:
> >> > > >
> >> > > >> Thanks for taking such a detailed a look, Nabarun! That's awesome
> >> > input.
> >> > > >>
> >> > > >> 1. Is there a reason why geode-native is signed with SHA512 while
> >> all
> >> > > the
> >> > > >>> rest are signed with SHA256?
> >> > > >>
> >> > > >> Not really. I used the defaults provided by the Gradle signing
> >> task in
> >> > > the
> >> > > >> case of the 

Re: [DISCUSS] Streamline return value from RemoteQuery

[Blake Bender]

+1 for always returning StructSet.  Just this change would have pretty
minimal impact.  We took a slightly more in-depth look at the code, and it
doesn't look like there's anything preventing us from converting most of
this stuff to standard library code.  StructSet could be replaced with
std::map >, and client developers
really wouldn't lose anything of value in the process.

On Wed, Aug 15, 2018 at 5:25 AM Jacob Barrett  wrote:

> Oh wouldn’t it be nice if it was asynchronous... :(
>
> > On Aug 14, 2018, at 8:56 PM, David Kimura  wrote:
> >
> > If this is a non-blocking function (and maybe even if it isn't), then it
> > might be worth considering a future/promise contract.   Perhaps something
> > like folly which provides a very rich interface.
> >
> > Thanks,
> > David
> >
> >> On Tue, Aug 14, 2018 at 12:57 PM, Jacob Barrett 
> wrote:
> >>
> >> If we are going to change it I wonder if we can’t do better or look for
> >> some other standard to adopt.
> >>
> >> For the C++ side could we adopt something that is maybe std::tuple or
> >> std::vector based? Tuple probably doesn’t work because it’s fixed at
> >> compile time but std::vector and StructSet are very similar in behavior.
> >>
> >> -Jake
> >>
> >>
> >>> On Aug 14, 2018, at 11:01 AM, Dan Smith  wrote:
> >>>
> >>> +1 for just having StructSet.
> >>>
> >>> Return types should always be strongly typed, the user shouldn't have
> to
> >>> introspect or guess based on their query what the return type actually
> >> will
> >>> be at runtime.
> >>>
> >>> If we think there is value in having separate ResultSet and StructSet
> >>> results, we could have a separate query::executeXXX method for each
> type.
> >>> But I think just returning StructSet seems reasonable.
> >>>
> >>> The Java API for query is even worse. I think the Java API actually
> >> returns
> >>> an Object, which the user has to cast into one of three things - an
> >>> individual value, SelectResult of values, or a SelectResults of
> structs.
> >> We
> >>> should fix that too!
> >>>
> >>> -Dan
> >>>
> >>> On Tue, Aug 14, 2018 at 10:47 AM, Anilkumar Gingade <
> aging...@pivotal.io
> >>>
> >>> wrote:
> >>>
>  In Java, they are separated so that the results can be managed
> >> effectively.
>  For example StructSet has its own implementation to manage the query
>  results that are structs (more than one projection attributes).
> 
>  -Anil
> 
> 
> 
> > On Tue, Aug 14, 2018 at 8:28 AM David Kimura 
> >> wrote:
> >
> > I have a couple questions:
> >
> > Do you have an idea or theories of what was the original intent
> behind
> > separating ResultSet and StructSet?
> >
> > Is execute a blocking or non-blocking call and does the interface
> have
>  any
> > guarantee of that?
> >
> > Thanks,
> > David
> >
> > On Mon, Aug 13, 2018 at 4:06 PM, Ernest Burghardt <
> >> eburgha...@pivotal.io
> >
> > wrote:
> >
> >> Currently, geode-native's query::execute returns a
> >> shared_ptr and
> >> that pointer can be either ResultSet or StructSet.
> >>
> >>
> >> RemoteQuery::execute contains logical code to determine with
>  QueryResults
> >> are greater than 0... We should look at removing this logic and only
> >> returning StructSets
> >> This allows removal of ResultSet which will streamline the API and
> >> associated code...
> >>
> >> This duality is unnecessary and should be removed.
> >> I am proposing that the results only return  StructSet
> >>
> >> Best,
> >> EB
> >>
> >
> 
> >>
>

Need permissions to Geode JIRA

[Blake Bender]

Hello,

I need to be able to update tickets in Geode JIRA, can someone please set
me up with appropriate permissions?

Thanks,

Blake