Hello team,
Can I get permissions to assign Geode Tickets to myself in JIRA?.
Cheers.
--
Ju@N
Hello Geode devs,
Currently GEODE is "swallowing" all output sent to stdout and stderr by
default and there's no way of changing this behavior when starting members
through *gfsh*.
This, between other things, prevents users, between other things, from
playing around with *System.out.println()*
+in+OQL
Please have a look and provide your feedback on the proposal.
Best regards.
--
Ju@N
ke any sense at all...
The proposal is to make the flags portable-auto-serializable-classes and
auto-serializable-classes mandatory, mutually exclusive.
Please let me know your thoughts.
Best regards.
--
Ju@N
ther?.
Best regards.
--
Ju@N
, let me know if
you still think it should be fixed and I'll create a DISCUSS thread to move
forward.
Best regards.
[1]: https://github.com/apache/geode/pull/2604
[2]: https://issues.apache.org/jira/browse/GEODE-5739
On Mon, Oct 15, 2018 at 3:14 PM Ju@N wrote:
> Hello all,
>
> Workin
the problem?.
Cheers.
--
Ju@N
the same
issue?, is it just my user?.
Best regards.
--
Ju@N
on't) have access to that list, am I right?.
Sorry for the long email and the amount of questions, just trying to make
sure I get things right from the very beginning :-).
Best regards.
--
Ju@N
early
stages and some of the suggested implementations might not even be
possible, but please go ahead and submit any feedback and/or ideas you
might have about it, every contribution is welcome.
Best regards.
--
Ju@N
.
[1]:
https://github.com/apache/geode/commit/6f4bbbd96bcecdb82cf7753ce1dae9fa6baebf9b
[2]: https://issues.apache.org/jira/browse/GEODE-7079
--
Ju@N
this
> > is
> > > > adding busywork for people to reapprove minor changes (Fixing merge
> > > > conflicts, spotless, etc.)
> > > >
> > > > If you all agree I'll ask infra to uncheck "Dismiss stale pull
> request
> > > > approvals when new commits are pushed." in our branch protection
> rules.
> > > >
> > > > -Dan
> > >
> > >
> >
>
--
Ju@N
t;
> Regards
> Naba
>
>
> On Wed, Oct 30, 2019 at 6:27 AM Joris Melchior
> wrote:
>
> > +1
> >
> > On Wed, Oct 30, 2019 at 5:27 AM Ju@N wrote:
> >
> > > Question: this only applies for *approvals*, not for *refusals*,
> right?;
> > I
&g
GEODE/%5BDiscussion%5D+-+Upgrade+Spring+version+from+Spring+4+to+Spring+5.x
>
>
--
Ju@N
+10 to Naba's proposal, it seems the right thing to do and will help us to
prevent accidentally breaking *develop* while keeping focus on people
instead of processes.
I'd add, however, that the *Merge Pull Request* button should remain
disabled until *all CIs have finished*, and only enable it
> >>
> >>
> 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
> >>
>
--
Ju@N
Ignore this email, I've previously replied to a thread in the list and I'm
not seeing that reply anywhere, trying to see if it's a general issue or
just a problem with my account.
Cheers.
--
Ju@N
un Nag
> > > >>>
> > > >>> On Wed, Oct 30, 2019 at 11:32 AM Aaron Lindsey <
> alind...@pivotal.io>
> > > >>> wrote:
> > > >>>
> > > >>>> One case when it might be acceptable to overrule a PR check is
> > > >> reverting
> > > >>> a
> > > >>>> commit. Before the branch protection was enabled, a committer
> could
> > > >>> revert
> > > >>>> a commit without a PR. Now that PRs are mandatory, we have to wait
> > for
> > > >>> the
> > > >>>> checks to run in order to revert a commit. Usually we are
> reverting
> > a
> > > >>>> commit because it's causing problems, so I think overruling the PR
> > > >> checks
> > > >>>> may be acceptable in that case.
> > > >>>>
> > > >>>> - Aaron
> > > >>>>
> > > >>>>
> > > >>>> On Wed, Oct 30, 2019 at 11:11 AM Owen Nichols <
> onich...@pivotal.io>
> > > >>> wrote:
> > > >>>>
> > > >>>>> Our new branch-protection rules can sometimes lead to unexpected
> > > >>>> obstacles
> > > >>>>> when infrastructure issues impede the intended process. Should
> we
> > > >>>> discuss
> > > >>>>> such cases as they come up, and should overruling the result of a
> > PR
> > > >>>> check
> > > >>>>> ever be an option on the table?
> > > >>>>>
> > > >>>>> -Owen
> > > >>>>
> > > >>>
> > > >>
> > >
> > >
> >
>
--
Ju@N
t; description: we would be
> inserting client information instead of the targeted server name. Still,
> since this extension is otherwise of no use in Geode, and this approach
> doesn’t present a security risk (we would be sharing the distributed system
> ID, which doesn’t look dangerous), we see this as a potential way to go.
> >
> >
> >
>
>
--
Ju@N
cters from 50 to something
else?, should we add a hard check in order to automatically enforce the
rule?, should we delete the rule altogether?, thoughts?.
Best regards.
[1]: https://cwiki.apache.org/confluence/display/GEODE/Commit+Message+Format
--
Ju@N
ts, and (b) some PRs that
> should
> >>>>> be
> >>>>>>>>> merged with squash are not (by accident most likely).
> >>>>>>>>>
> >>>>>>>>> I can submit multiple PRs instead of one PR with multiple
> commits.
> >>>> So
> >>>>>>> I'll
> >>>>>>>>> change my response to -0 if that helps prevent commits to develop
> >>>> that
> >>>>>>>>> don't compile or pass tests. Without preventing rebase or merge
> >>>>> commits
> >>>>>>>>> from github, I'm not sure how we can really enforce this or
> prevent
> >>>>> (b)
> >>>>>>>>> above.
> >>>>>>>>>
> >>>>>>>>> On Fri, Dec 13, 2019 at 3:38 PM Alexander Murmann <
> >>>>> amurm...@pivotal.io>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> I wonder if Kirk's and Naba's statements are necessarily at
> odds.
> >>>>>>>>>>
> >>>>>>>>>> Make the change easy (warning: this may be hard), then make the
> >>>> easy
> >>>>>>>>>>> change."
> >>>>>>>>>> -Kent Beck
> >>>>>>>>>>
> >>>>>>>>>> Following Kent Beck's advise might reasonably split into two
> >>>> commits.
> >>>>>>> One
> >>>>>>>>>> refactor commit and a separate commit that introduces the actual
> >>>>>>> change.
> >>>>>>>>>> They should be individually revertible and might be easier
> >>>> understood
> >>>>>>> if
> >>>>>>>>>> split out. I vividly remember a change on our code base where
> >>>> someone
> >>>>>>>>> did a
> >>>>>>>>>> huge amount of refactoring that resulted than in one parameter
> >>>>> changing
> >>>>>>>>> in
> >>>>>>>>>> order to get the desired functionality change. If that was in
> one
> >>>>>>> commit,
> >>>>>>>>>> it would be hard to see the actual change. If split out, it's
> >>>>> beautiful
> >>>>>>>>> and
> >>>>>>>>>> crystal clear.
> >>>>>>>>>>
> >>>>>>>>>> I am unsure how that would be reflected in terms of JIRA ticket
> >>>>>>>>> references.
> >>>>>>>>>> Usually we assume that if there is a commit with the ticket
> number,
> >>>>> the
> >>>>>>>>>> issue is resolved. Maybe the key here is to create a separate
> >>>>>>> refactoring
> >>>>>>>>>> ticket.
> >>>>>>>>>>
> >>>>>>>>>> Would that allow us to have our cake and eat it too?
> >>>>>>>>>>
> >>>>>>>>>> On Fri, Dec 13, 2019 at 3:16 PM Nabarun Nag
> >>>> wrote:
> >>>>>>>>>>> It is to help with bisect operations when things start failing
> ...
> >>>>>>>>> helps
> >>>>>>>>>> us
> >>>>>>>>>>> it revert and build faster.
> >>>>>>>>>>> also with cherry picking features / fixes to previous versions
> .
> >>>>>>>>>>> And keeping the git history clean with no unnecessary “merge
> >>>>> commits”.
> >>>>>>>>>>> Regards
> >>>>>>>>>>> Naba
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On Fri, Dec 13, 2019 at 2:25 PM Kirk Lund
> >>>> wrote:
> >>>>>>>>>>>> -1 I really like to sometimes have more than 1 commit in a PR
> and
> >>>>>>>>> keep
> >>>>>>>>>>> them
> >>>>>>>>>>>> separate when they merge to develop
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Tue, 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.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>
>
> --
Ju@N
[2].
Best regards.
[1]: https://issues.apache.org/jira/browse/GEODE-7789
[2]:
https://github.com/apache/geode/commit/71e156a55228d89efafd048e1533debba606c064
--
Ju@N
CQs.
The SHA is 5dd7a8420bbe43657abc82e5b8d073eb01b51d8d [2].
Best regards.
[1]: https://issues.apache.org/jira/browse/GEODE-7756
[2]:
https://github.com/apache/geode/commit/5dd7a8420bbe43657abc82e5b8d073eb01b51d8d
--
Ju@N
]: https://issues.apache.org/jira/browse/GEODE-7814
[2]:
https://github.com/apache/geode/commit/db86faec699aca67c02325bca22dcd5b913ddfed
--
Ju@N
now).
Best regards.
[1]: https://issues.apache.org/jira/browse/GEODE-7820
[2]:
https://github.com/apache/geode/commit/ca7ccbce73d436005fe027f31ee910ee9beeb769
--
Ju@N
so to speak, but I don’t think as a community it is a big problem
> because we can still say that you should not merge if the StressNewTest
> fails because of your test.
> >
> > I personally find the false sense of security more troubling than
> anything. Hence the reason, I would like this to be
> >
> > Let me know what you think..
> >
> > Thanks,
> > Mark
>
>
--
Ju@N
ing and mitigating this!
>
> The Benchmarks tests in our pipeline are supposed to catch performance
> degradations exceeding 5%. We should all be concerned, how did a 7%
> degradation slip through?
>
> > On Feb 28, 2020, at 3:48 AM, Ju@N wrote:
> >
> > Hello devs,
> >
-7728
[2]:
https://github.com/apache/geode/commit/6e35c201ea605075433203d4e64ca887bafd8fcb
--
Ju@N
Standard Out.
>
> https://cwiki.apache.org/confluence/display/GEODE/Logging+to+Standard+Out
> <https://cwiki.apache.org/confluence/display/GEODE/Logging+to+Standard+Out
> >
>
> Please comment by 1/21/2020.
>
> Thanks,
> Jake
>
>
--
Ju@N
>>>
> >>>>>>>>> Hi Dan,
> >>>>>>>>>
> >>>>>>>>> When we do squash merge all the commit messages are preserved
> >> and
> >>>>> also
> >>>>>>>>>
> >>>>>>>>> the
velop since February via GEODE-7798.
>
> This fix is critical to avoid false positives in automated vulnerability
> scans.
>
> -Owen
--
Ju@N
end testing looks good to me
>
> +1
>
> > On Apr 17, 2020, at 3:26 PM, Robert Houghton
> wrote:
> >
> > Conditional +1 from me too, pending a few days on develop with happy
> > results :)
> >
> > Thanks Juan!
> >
> > On Fri, Apr 17, 2020
tps://issues.apache.org/jira/browse/INFRA-20156
> > > [2]
> >
> https://cwiki.apache.org/confluence/display/INFRA/.asf.yaml+features+for+git+repositories#id-.asf.yamlfeaturesforgitrepositories-Notificationsettingsforrepositories
> >
> >
>
--
Ju@N
uld like to
> see that it gets through all tests and spends a couple days on develop,
> then I will be happy to give this a +1 on Monday if no surprises turn up.
>
> > On Apr 17, 2020, at 1:41 AM, Ju@N wrote:
> >
> > Hello devs,
> >
> > I'd like to propose
into develop through commit *bfbb398 [2]*.
Best regards.
[1]: https://issues.apache.org/jira/browse/GEODE-7940
[2]:
https://github.com/apache/geode/commit/bfbb398891c5d96fa3a5975365b29d71bd849ad6
--
Ju@N
easygoing approach working just fine?
> >>>
> >>> [1]
> >>>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-develop-maindata=02%7C01%7Chansonm%40vmware.com%7C631cbe6f65c14bbb030108d7ec931267%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637237988725318710sdata=2ecuh535cj7G9i8STCT32zyunsnrcupg4c8dowrGwvo%3Dreserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-develop-maindata=02%7C01%7Chansonm%40vmware.com%7C631cbe6f65c14bbb030108d7ec931267%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637237988725318710sdata=2ecuh535cj7G9i8STCT32zyunsnrcupg4c8dowrGwvo%3Dreserved=0
> >
>
>
--
Ju@N
.
>
> Could anybody tell me why this check (the if) is necessary given that
> there is already a fromDataPre_GEODE_1_9_0 method in the class?
>
> Thanks in advance,
>
> -Alberto G.
>
--
Ju@N
+1
On Thu, 14 May 2020 at 22:19, Mark Hanson wrote:
> +1. The more we can automate this types of checks the better.
>
> Thanks,
> Mark
>
>
--
Ju@N
but it would be good to include these fixes into the
release anyways.
Best regards.
[1]: https://issues.apache.org/jira/browse/GEODE-7832
[2]: https://issues.apache.org/jira/browse/GEODE-7853
[3]: https://issues.apache.org/jira/browse/GEODE-7863
--
Ju@N
--
Ju@N
ll and really help all contributors not
> have to deal with multiple systems to get stuff done.
>
> +1
>
>
> -Jake
>
>
--
Ju@N
the rebalance is successful or
not).
The fix has been merged into develop through commit
d8e86cb720c054b154a16cc88fee88e73db709f3 [2].
Best regards.
[1]: https://issues.apache.org/jira/browse/GEODE-8071
[2:]
https://github.com/apache/geode/commit/d8e86cb720c054b154a16cc88fee88e73db709f3
--
Ju@N
t;
> >
> > On Thu, May 7, 2020 at 10:22 AM Jianxia Chen wrote:
> >
> > > +1
> > >
> > > On Thu, May 7, 2020 at 7:47 AM Ju@N wrote:
> > >
> > > > Hello devs,
> > > >
> > > > I'd like to propose bringing GEO
ding to what is described in the wiki, it should not
> be necessary to add any extra check to the `fromData/toData`methods. But
> there is this check I mentioned which is necessary according to some
> backward compatibility tests in Geode. So my question is why is it
> necessary?
>
> Thanks
>
>
>
> 18911098...@163.com
>
--
Ju@N
Analysis shows that this saml vulnerability is not applicable to Geode
> Pulse.
> >
> > It is low risk to bump the spring-security dependency to the latest
> version to avoid false positives in automated scans. This change is
> already on develop and all tests have passed. It w
, 2020, 8:12 AM -0700, Ju@N , wrote:
> Hello devs,
>
> I'd like to propose bringing *GEODE-8150 [1] *to the *support/1.13* branch.
> The ticket is basically to revert the upgrade of the *classgraph* [2]
> library, we found some performance issues that are not addressed even wh
cal to avoid false positives in automated vulnerability
> scans. It would be nice to bring to support branches before 1.13.0 is
> released.
>
> Please vote “+1” to approve including this in 1.13.0. If there are any -1
> votes, I’ll wait until after 1.13.0 is done to propose this again.
>
--
Ju@N
command line version hangs, probably waiting for input
>
> bin/gfsh -e "connect" -e "shutdown --include-locators=yes"
>
> Any clue how I can bypass this
>
> Thanks
> Avinash
>
--
Ju@N
fluence/display/GEODE/Introduction+of+ClassLoaderService+into+Geode
>
> All comments are please to be made in this mail thread.
>
> —Udo
>
--
Ju@N
pache%2Fgeode-kafka-connector%2Fwiki%2FDeploying-Kafka-connect-Geode-on-Confluent-Platform=04%7C01%7Cudo%40vmware.com%7C10f6699a9f4c4dd7912508d8713d8412%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637383856307862391%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=7VqsGxwEDN4tuFQa5%2FGQqcE6s2z%2FZrSFEU7DzdzT8ew%3D=0>
>
--
Ju@N
; > affected by a given issue becomes even more important.
> > >
> > > [1] https://i.imgur.com/oQ8CW87.png
> > > [2]
> > >
> >
> https://issues.apache.org/jira/projects/GEODE/issues/GEODE-8433?filter=allissues=cf%5B12310921%5D+ASC%2C+created+DESC
> > > [3]
> > >
> >
> https://issues.apache.org/jira/browse/GEODE-8433?jql=project%20%3D%20GEODE%20AND%20issuetype%20%3D%20Bug%20AND%20affectedVersion%20%3D%20EMPTY%20ORDER%20BY%20created%20DESC%2C%20affectedVersion%20ASC%2C%20cf%5B12310921%5D%20ASC
> > >
> >
>
--
Ju@N
/07bf3dd827f29a5deb8619f79203d94847a1a823
--
Ju@N
.2.1.RC3
> rel/v1.2.1.RC4
> rel/v1.2.1manualrev-2017-10-19
> rel/v1.3.0.RC1
> rel/v1.3.0.RC2
> rel/v1.3.0.RC3
> rel/v1.3.0.RC4
> rel/v1.4.0.RC1
> rel/v1.4.0.RC2
> rel/v1.5.0.RC1
> rel/v1.5.0.RC2
> rel/v1.6.0.RC1
> rel/v1.7.0.RC1
> rel/v1.7.0.RC2
> rel/v1.8.0.RC1
> rel/v1.8.0.RC2
> rel/v1.9.0.1
> rel/v1.9.0.1.RC1
> rel/v1.9.0.2
> rel/v1.9.0.RC1
> rel/v1.9.0.RC2
> rel/v1.9.0.RC3
> rel/v1.9.0.RC4
> rel/v1.9.1-nordix
> rel/v1.9.1.RC1
> rel/v1.9.1.RC2
> rel/v1.9.1.RC3
> rel/v1.9.2.RC1
> sga2-core
> v1.1.0manualrev-2017-10-19
> v9.0.0-beta.1
>
--
Ju@N
gt; Would it make sense for the gateway sender not to store the received
> > events in tmpDroppedEvents while it is stopped?
> >
> > Any suggestion on how to approach the problem of heap exhaustion due to
> > the growth of gateway sender queues in long lasting split brain
> situations?
> >
> > Thanks in advance,
> >
> > Alberto G.
> >
> >
> >
>
--
Ju@N
f bringing GEODE-8315 is very low (difference between Shiro
> 1.5.2 and 1.5.3 is bugfix only). GEODE-8315 has been on develop for 2 days
> and passed the pipeline.
>
> This fix is critical to avoid false positives in automated vulnerability
> scans, so it would be nice to bring before 1.13.0 release.
>
--
Ju@N
> support/1.13
>
> +1
>
> On 2020-07-03, 9:06 AM, "Ju@N" wrote:
>
> Hello devs,
>
> I'd like to propose bringing GEODE-8029 [1] to the support/1.12 and
> support/1.13 branches.
> No, you're not having deja vú (neither this is an error within the
&g
89b28585556ee%40%253Cdev.geode.apache.org%253Edata=02%7C01%7Cjmelchior%40vmware.com%7C458c4abf934b43480f2308d8248b403a%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637299527784977071sdata=7CRcXQYAkbVtQ5CMFZgKZCMtfyqHw2UxkNPA4KwSl8k%3Dreserved=0
>
>
--
Ju@N
nnections
> will not be formed and updates will not be transmitted between sites.
>
> https://github.com/apache/geode/pull/5306
>
>
--
Ju@N
--
Ju@N
Jun 2020 at 18:51, Dave Barnes wrote:
> Looks like the community approves, Ju@n. Go ahead and merge.
> Thanks,
> Dave
>
> On Wed, Jun 10, 2020 at 10:37 AM Joris Melchior
> wrote:
>
> > +1
> > ________
> > From: Ju@N
> > Sent: Ju
jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=dSxkBw04EOxr8vw1HP7u0oKMf%2FmNED6lVmaoV6FezGY%3Dreserved=0
> [2]
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgeode.apache.org%2Fdocs%2Fguide%2F113%2Fmanaging%2Fmonitor_tune%2Fsockets_and_gateways.htmldata=04%7C01%7Cjblum%40vmware.com%7C87fe2b03a77045e6335408d88c3037b3%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637413486010510705%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=3tOT2lJPdd%2B1xBf4km5iQR6pVYIZVwcA6MelXyTbQ%2Bc%3Dreserved=0
>
--
Ju@N
re/StatusRedundancy features introduced in 1.13.0. The fix is
> minimal and has passed all tests run against the develop pipeline.
>
> Thanks,
> Donal
>
--
Ju@N
of PERSISTENT regions makes things worse as
other joining members might get stuck waiting to recover the latest data -.
Best regards.
[1]: https://issues.apache.org/jira/browse/GEODE-9000
[2]:
https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12336052
--
Ju@N
e the logs but rather to change the level of
> these logs from warning to debug level.
>
> I agree, if any exception is expected as part user provided action it
> should not produce verbose logging.
>
> -Jake
>
>
--
Ju@N
64 matches
Mail list logo
