GEODE-7593 fixes a memory leak where indexes could retain references to pdx
values when eviction should have released that memory.
This is not a new issue, but is critical because system stability is threatened
when eviction does not release memory as expected.
The SHA is 1beec9e3930a071031b960
+1
On Thu, Dec 19, 2019 at 10:05 AM Owen Nichols wrote:
> GEODE-7593 fixes a memory leak where indexes could retain references to
> pdx values when eviction should have released that memory.
>
> This is not a new issue, but is critical because system stability is
> threatened when eviction does
+1
On 12/19/19 10:05 AM, Owen Nichols wrote:
GEODE-7593 fixes a memory leak where indexes could retain references to pdx
values when eviction should have released that memory.
This is not a new issue, but is critical because system stability is threatened
when eviction does not release memory
+1
On Thu, Dec 19, 2019 at 11:27 AM Udo Kohlmeyer wrote:
> +1
>
> On 12/19/19 10:05 AM, Owen Nichols wrote:
> > GEODE-7593 fixes a memory leak where indexes could retain references to
> pdx values when eviction should have released that memory.
> >
> > This is not a new issue, but is critical be
Hi All,
I believe at this point, that all outstanding issues have been included in
1.11.0. I would like to do an RC build unless someone advises me otherwise, by
3pm PST. Everyone will still have a few days to try the release candidate, as
usual.
Thanks,
Mark
+1
On Thu, Dec 19, 2019 at 11:43 AM Dick Cavender wrote:
> +1
>
> On Thu, Dec 19, 2019 at 11:27 AM Udo Kohlmeyer wrote:
>
> > +1
> >
> > On 12/19/19 10:05 AM, Owen Nichols wrote:
> > > GEODE-7593 fixes a memory leak where indexes could retain references to
> > pdx values when eviction should ha
I have added the SHA to the branch.
Thanks,
Mark
> On Dec 19, 2019, at 12:25 PM, Ivan Godwin wrote:
>
> +1
>
> On Thu, Dec 19, 2019 at 11:43 AM Dick Cavender wrote:
>
>> +1
>>
>> On Thu, Dec 19, 2019 at 11:27 AM Udo Kohlmeyer wrote:
>>
>>> +1
>>>
>>> On 12/19/19 10:05 AM, Owen Nichols wr
I’d like to advance this topic from an informal request/discussion to a
discussion of a concrete proposal.
To recap, it sounds like there is general agreement that commit history on
develop should be linear (no merge commits), and that the biggest obstacle to
this is that the PR merge button in
+1
On Thu, Dec 19, 2019, 4:05 PM Owen Nichols wrote:
> I’d like to advance this topic from an informal request/discussion to a
> discussion of a concrete proposal.
>
> To recap, it sounds like there is general agreement that commit history on
> develop should be linear (no merge commits), and th
+1
> On Dec 19, 2019, at 4:27 PM, Jinmei Liao wrote:
>
> +1
>
> On Thu, Dec 19, 2019, 4:05 PM Owen Nichols wrote:
>
>> I’d like to advance this topic from an informal request/discussion to a
>> discussion of a concrete proposal.
>>
>> To recap, it sounds like there is general agreement that
-1 to (1) and (2).
I think merge commits are appropriate in certain circumstances, so I don't
think we should make a blanket restriction. In fact I think our release
process involves some merges.
I think setting standards on what is reasonable to be an individual commit
will do a lot more to clea
I’m in agreement with Dan. Changes to the infrastructure to flat out prevent
things that should be self policing is annoying. This PR review lock we have
had already cost us valuable time waiting for PR pipelines to pass that have no
relevance to the commit, like CI work: I’d hat to see yet anot
Dan, to address some of your concerns:
This proposal is to block merge commit on develop only. The release process
makes a merge commit to master only.
This proposal explicitly allows reasonably separate and well written commits in
a single PR. For this case simply choose Rebase & Merge, and
This proposal in no way prevents you from getting work done. Squash is always
enabled and always the most acceptable way to bring changes to develop.
Please start a separate thread if you would like to revisit the community
decision to require passing PR checks.
> On Dec 19, 2019, at 4:49 PM,
If the appropriate or necessary process is a merge then this proposal prevents
that. I am not interested in any hard restrictions like this. You proposal in
response to dan is not palatable by disabling merges via github but allowing it
manually.
> On Dec 19, 2019, at 4:54 PM, Owen Nichols wr
Hi all,
This is not a blanket restriction.
My suggestion, like last time, lets try it out and this time we don't even
need Apache Infra to step in. Feels like it has been requested in multiple
INFRA JIRAs by so many Apache projects to enable only the squash merge
button and disable the others, tha
So it seems that the situation is something like this where I'm able to
make the initial connection but then retrieving status fails:
gfsh>connect --security-properties-file=../security.properties
gfsh>status locator --name=locator1
Server version response invalid: This could be the result of try
that's a solution too. but since "status locator" can point to any locator
that's running, it may not be the one that the current gfsh is connected to.
On Thu, Dec 19, 2019 at 6:31 PM Jens Deppe wrote:
> So it seems that the situation is something like this where I'm able to
> make the initial c
18 matches
Mail list logo
