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
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%
+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
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 mayb
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
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
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:0
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
>
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
> >
>
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 n
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
>
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
> S
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
+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
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
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&#
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/c932a1
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
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 Ma
-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 c
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
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
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
betw
e 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
>
>
> >
nd 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 grou
l 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
> > >
> > >
&g
rk 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
+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
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:
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
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/Ad
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
difficu
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
>
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?
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
gt; > 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 n
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 bei
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
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 notic
about the wiki tech
> > and more about making the content easily accessible and discoverable for
> > our users and contributors. Our current wiki has a lot of useful
> > information. I’d like to understand how we want to use repo-specific
> > wiki’s to augment or replace our c
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
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.
>>>> +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 ju
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.out
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
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 iss
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:
>
> Hel
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 pl
"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:
>
>
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 correc
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%2Fpu
.
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 i
+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-83
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&
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 t
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 bec
Hello, may I please have access to the Geode Concourse?
My GitHub username is pdxcodemonkey
Thanks,
Blake
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: W
Hello,
I need to be able to update tickets in Geode JIRA, can someone please set
me up with appropriate permissions?
Thanks,
Blake
+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
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,
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
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
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
+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 Me
+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 Optio
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 s
g
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, &quo
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,
69 matches
Mail list logo
