+1
I like this idea and Kirk's suggestion to use the CompletableFuture as a
standard for asynchronous operations.
On Mon, Mar 30, 2020 at 2:47 PM Donal Evans wrote:
> Hey everyone,
>
> An RFC for adding gfsh commands to allow users to restore redundancy to
> partitioned regions and to easily ch
Hi all,
We created a RFC for replacing our UDP messaging in Geode with a TCP based
solution. This will address the issues we have supporting our current udp
encryption solution, along with helping us move away from jgroups, which
currently can't be upgraded.
Please review and comment by 4/7/2020
Can we document the protocol this time?
Thanks,
Mark
> On Mar 31, 2020, at 10:17 AM, Dan Smith wrote:
>
> Hi all,
>
> We created a RFC for replacing our UDP messaging in Geode with a TCP based
> solution. This will address the issues we have supporting our current udp
> encryption solution, a
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
The Apache Geode community is pleased to announce the availability of
Apache Geode 1.12.0.
Apache Geode is a data management platform that provides a database-like
consistency model, reliable transaction processing and a shared-nothing
architecture to maintain very low latency performance with hig
With the release of Geode 1.12.0 (awesome!), we have a new branch naming
convention starting today:
release/1.12.0 is now support/1.12
As per this RFC, support/1.12 and an accompanying pipeline[1] will be
maintained until Dec 31 2020.
Critical fixes may be proposed at any time. The fix should
Build Update for apache/geode-examples
-
Build: #432
Status: Errored
Duration: 20 secs
Commit: 0b27ac9 (release/1.12.0)
Author: Ernie Burghardt
Message: Revert "temporarily point to staging repo for CI purposes"
View the changeset:
https://github.com/apache/g
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++ l
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?
Once we do have agreement on what new repositories we want, I think any pmc
member should be able to create them on gitbox.apache.org. Deleting them if
we decide we don't want them is harder :)
-Dan
On Tue, Mar 31, 2020, 12:26 PM Blake Bender wrote:
> Just want to make sure I understand what yo
A separate repo is our interpretation of the comments generated by this RFC.
It’s easier to combine repositories later than it is to take them apart. The
take away of this library is the ABI; that it will presently link against the
C++ library is an implementation detail. We consider these separ
> On Mar 31, 2020, at 12:25 PM, Blake Bender wrote:
>
> 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
> contai
> 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
c
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
> 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.
Echo’ing my comment here:
When we move from a reliable UDP implementation to one based on TCP, we need to
think about how to provide reliability on top of TCP. If you dig into TCP,
you’ll find that it tries really hard (sometimes up to 15 minutes!!) but
doesn’t guarantee message delivery. Doe
16 matches
Mail list logo
