I think in this case it would be replacing the messages used to
replicate changes with ones that send the operation + parameters instead
of the modified entry's new value. That could be done by creating a new
subclass of BucketRegion. Stick the operation+params into the
EntryEventImpl that follows the operation through the system and in the
BucketRegion subclass pull out that data and send it instead of the
event's newValue.
Le 2/27/2017 à 11:13 AM, Real Wes a écrit :
I'm not following what a "simple operation replication framework" is and how it applies
to the Redis API. If you replicate operations, you still need to update the data at some point,
causing a synchronous replication event so as to provide HA. What is, in more detail, a
"simple operation replication framework"?
Regards,
Wes Williams
Sent from mobile phone
On Feb 27, 2017, at 2:07 PM, Bruce Schuchardt <bschucha...@pivotal.io> wrote:
What I like about using the existing delta-prop mechanism is it will also extend to
client subscriptions & WAN. It would take a lot of work to propagate Redis
commands through those paths.
Le 2/27/2017 à 10:35 AM, Hitesh Khamesra a écrit :
The simplicity of Redis API making this problem (delta update)most apparent.
But, I would imagine many Geode apps has a similar use case.
-Hitesh
From: Michael Stolz <mst...@pivotal.io>
To: dev@geode.apache.org
Sent: Monday, February 27, 2017 9:06 AM
Subject: Re: [DISCUSS] changes to Redis implementation
It does seem like the operations will often be much smaller than the data
they are operating on.
It is almost the classic "move the code to the data" pattern.
--
Mike Stolz
Principal Engineer, GemFire Product Manager
Mobile: +1-631-835-4771
On Mon, Feb 27, 2017 at 10:51 AM, Udo Kohlmeyer <ukohlme...@pivotal.io>
wrote:
Delta could provide us a mechanism to replicate only what is required.
I wonder if we could not create a simple operation replication framework.
Rather than writing a potential large amounts of code for delta, we
replicate only the operation.
On 2/27/17 07:18, Wes Williams wrote:
Replicating a whole collection because of 1 change does not really make
too much sense.<<
I agree but won't delta replication prevent sending the entire collection
across the wire?
*Wes Williams | Pivotal Advisory **Data Engineer*
781.606.0325
http://pivotal.io/big-data/pivotal-gemfire
On Mon, Feb 27, 2017 at 10:08 AM, Udo Kohlmeyer <ukohlme...@pivotal.io>
wrote:
I've quickly gone through the changes for the pull request.
The most significant change of this pull request is that the collections
that initially were regions are single collections (not distributed).
That
said, this is something that we've been discussing. The one thing that I
wonder about is, what will the performance look like when the collections
become really large? Replicating a whole collection because of 1 change
does not really make too much sense.
Maybe this implementation becomes the catalyst for future improvements.
--Udo
On 2/24/17 15:25, Bruce Schuchardt wrote:
Gregory Green has posted a pull request that warrants discussion. It
improves performance for Sets and Hashes by altering the storage format
for
these collections. As such it will not permit a rolling upgrade, though
the Redis adapter is labelled "experimental" so maybe that's okay.
https://github.com/apache/geode/pull/404
The PR also fixes GEODE-2469, inability to handle hash keys having
colons.
There was some discussion about altering the storage format that was
initiated by Hitesh. Personally I think Gregory's changes are better
than
the current implementation and we should accept them, though I haven't
gone
through the code changes extensively.
