That's right, most/always no down-time requirement is managed by having
replicated cluster setups (Disaster-recovery/backup site). The data is
either pushed to both systems through the data ingesters or by using WAN
setup.
The clusters are upgraded one at a time. If there is a failure during
Anil, let me see if I understand your perspective by stating it this way:
If cases where 100% uptime is a requirement, users are almost always running a
disaster recovery site. It could be active/active or active/standby but there
are already at least 2 clusters with current copies of the
Geode is scheduled to cut support/1.13 on May 4, as per the quarterly release
schedule approved [1] in 2018 and affirmed in last month’s “Shipping patch
releases” RFC [2].
Please volunteer if you are interested in serving as Release Manager for Geode
1.13.0.
[1]
>> Rolling downgrade is a pretty important requirement for our customers
>> I'd love to hear what others think about whether this feature is worth
the overhead of making sure downgrades can always work.
I/We haven't seen users/customers requesting rolling downgrade as a
critical requirement for
Steve,
Have you looked at grouping your putAll() requests into groups that align to
Geode’s buckets? In your application code, you can determine the hash for each
data item and self-partition the entries. This allows you to send the requests
on separate threads in parallel while optimizing
Sorry for the delay, my day went very sideways yesterday. I’ve pushed changes
to master (and develop where needed) for the following repos:
geode
geode-benchmarks
geode-examples
geode-kafka-connector
geode-native
geode-site
I’m not entirely satisfied it’s doing everything we want (like linking
Build Update for apache/geode-examples
-
Build: #439
Status: Fixed
Duration: 22 mins and 7 secs
Commit: cc644fa (develop)
Author: Anthony Baker
Message: Updated notifications configuration file
View the changeset:
alb3rtobr commented on issue #4978:
URL: https://github.com/apache/geode/pull/4978#issuecomment-617861442
> One additional comment regarding the following waning message:
>
> ```
> [warn 2020/04/18 23:44:22.757 PDT tid=0x298] Unable to ping non-member
prettyClouds opened a new pull request #4984:
URL: https://github.com/apache/geode/pull/4984
Thank you for submitting a contribution to Apache Geode.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
### For all
jujoramos commented on issue #4978:
URL: https://github.com/apache/geode/pull/4978#issuecomment-617814149
One additional comment regarding the following waning message:
```
[warn 2020/04/18 23:44:22.757 PDT
tid=0x298] Unable to ping non-member
jdeppe-pivotal commented on issue #4861:
URL: https://github.com/apache/geode/pull/4861#issuecomment-617771032
Since we're actively working on various approaches to this, and it's
probably still going to take a while, I'm going to close this PR for now.
jujoramos commented on a change in pull request #4978:
URL: https://github.com/apache/geode/pull/4978#discussion_r412828019
##
File path:
geode-core/src/main/java/org/apache/geode/cache/client/internal/PingOp.java
##
@@ -43,12 +45,16 @@ private PingOp() {
static class
jujoramos commented on a change in pull request #4970:
URL: https://github.com/apache/geode/pull/4970#discussion_r412794182
##
File path:
geode-core/src/distributedTest/java/org/apache/geode/internal/cache/PartitionedRegionClearWithExpirationDUnitTest.java
##
@@ -0,0 +1,537
jujoramos commented on issue #4978:
URL: https://github.com/apache/geode/pull/4978#issuecomment-617642403
@bschuchardt @alb3rtobr : I'm still analysing the issue and seeing whether I
can reproduce it consistently, so far it's proving quite elusive as it only
fails once or twice in around
14 matches
Mail list logo
