Hello devs,
I'd like to include the fix for GEODE-7820 [1] in release 1.12.0.
The change avoid unnecessary transformations between java collections and
primitive arrays for every message sent within a Geode cluster (see the
Geode tickets for further details).
The SHA is ca7ccbce73d436005fe027f31ee
+1, Keep the improvements coming...
On 2/28/20 3:48 AM, Ju@N wrote:
Hello devs,
I'd like to include the fix for GEODE-7820 [1] in release 1.12.0.
The change avoid unnecessary transformations between java collections and
primitive arrays for every message sent within a Geode cluster (see the
Geo
+1
On Fri, Feb 28, 2020 at 7:38 AM Udo Kohlmeyer wrote:
> +1, Keep the improvements coming...
>
> On 2/28/20 3:48 AM, Ju@N wrote:
> > Hello devs,
> >
> > I'd like to include the fix for GEODE-7820 [1] in release 1.12.0.
> > The change avoid unnecessary transformations between java collections an
+1
On Fri, Feb 28, 2020 at 7:40 AM Owen Nichols wrote:
> +1
>
> On Fri, Feb 28, 2020 at 7:38 AM Udo Kohlmeyer wrote:
>
> > +1, Keep the improvements coming...
> >
> > On 2/28/20 3:48 AM, Ju@N wrote:
> > > Hello devs,
> > >
> > > I'd like to include the fix for GEODE-7820 [1] in release 1.12.0.
There appears to be consensus that this is a critical fix.
The following commit has been brought into release/1.12 as the
critical fix for GEODE-7820:
git cherry-pick -x ca7ccbce73d436005fe027f31ee910ee9beeb769
GEODE-7820 has been marked as 'resolved in' 1.12.
Regards
EB
On Fri, Feb 28, 2020
If I run the japi-compliance-checker [1] against the 1.12 release branch and
develop this change pops up as a binary incompatibility. As Owen noted, this
would require recompilation to avoid NoSuchMethod errors.
One effect this could have is that a library built on top of Geode (e.g.
Spring) w
Another affect is code deployment onto/into the server, which
could/would reference a change (binary) API. Users generally don't
recompile the code they redeploy. The NoSuchMethod is now harder to
track down.
--Udo
On 2/28/20 8:59 AM, Anthony Baker wrote:
If I run the japi-compliance-checke
Hi All,
Proposal: Force StressNewTest to fail a change with 25 or more files rather
than pass it without running it.
Currently, the StressNewTest job in the pipeline will just pass a job that has
more than 25 files changed. It will be marked as green with no work done. There
are reasons, relat
-1 to making StressNew not required
+1 to eliminating the current loophole — StressNew should never give a free
pass.
Any time your PR is having trouble passing StressNew, please bring it up on the
dev list. We can review on a case-by-case basis and decide whether to try
increasing the timeo
+1 to what Owen said, I don't think disabling *StressNewTest* is a
good idea.
On Fri, 28 Feb 2020 at 18:35, Owen Nichols wrote:
> -1 to making StressNew not required
>
> +1 to eliminating the current loophole — StressNew should never give a
> free pass.
>
> Any time your PR is having trouble pas
Thanks Juan, this is fantastic work discovering 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,
Just to make sure we are clear, I am not suggesting that we disable
stressnewtest, but that we make it not required. It would still run and provide
feedback, but it would not give us an unwarranted green in my approach.
> On Feb 28, 2020, at 10:49 AM, Ju@N wrote:
>
> +1 to what Owen said, I do
Hello Owen,
Unfortunately I don't have the answer to that question... I
never worked through the Geode Benchmarks so I don't know exactly what
they're testing/validating.
Best regards.
On Fri, 28 Feb 2020 at 18:52, Owen Nichols wrote:
> Thanks Juan, this is fantastic work discovering and mitiga
-1 to limiting any tests... if there are issues with the tests let's fix
that. we have too many commits coming in with little or no testing over
new/changed code, so I can't see how removing any existing test coverage as
a good idea
Best,
EB
On Fri, Feb 28, 2020 at 10:58 AM Mark Hanson wrote:
During a refactor the default ack-wait-threshold was changed from 15 to 51.
This will affect any deployment that doesn’t set its own threshold.
The ack-wait-threshold determines how long we wait for a response to a message,
such as replication of a put(), before taking some action.
Alright, so basically it seems like people are not ok with the not requiring
stressnewtest approach. So I guess that means that we need to identify -1s
willing to help resolve this problem…
Who would like to help?
Thanks,
Mark
> On Feb 28, 2020, at 11:12 AM, Ernest Burghardt wrote:
>
> -1 to
I propose we deprecate Geode’s proprietary UDP message privacy algorithm
based on the Diffie-Hellman key exchange protocol. This would deprecate:
ConfigurationProperties.SECURITY_UDP_DHALGO
String DistributionConfig.getSecurityUDPDHAlgo()
void DistributionConfig.setSecurityUDPDHAlgo(String attVa
What help is needed in this effort?
Regards
Naba
On Fri, Feb 28, 2020 at 11:35 AM Mark Hanson wrote:
> Alright, so basically it seems like people are not ok with the not
> requiring stressnewtest approach. So I guess that means that we need to
> identify -1s willing to help resolve this problem
+1
We should have done this as soon as SSL/TLS was ready. Better late than never!
While we normally wait until a major release to remove deprecated stuff, there
is some precedent for removing insecure encryption algorithms sooner (Java has
done this even in patch releases). We should consider
Currently, StressNewTest will turn green WITHOUT RUNNING ANY TESTS if it thinks
(often wrongly) that more than 25 test files were touched.
This is both dishonest (it can give a false green) AND totally unnecessary
(concourse already applies a timeout to StressNewTest, currently set at 6
hours,
Hi!
I am planning on contributing and would like contributor access in Jira.
My username is deanderson
Thank you so much for your help
Welcome Derrick, you should have access to Geode Jira now
https://issues.apache.org/jira/projects/GEODE/issues
> On Feb 26, 2020, at 8:41 AM, Derrick Anderson
> wrote:
>
> Hi!
>
> I am planning on contributing and would like contributor access in Jira.
>
> My username is deanderson
>
> Tha
+1
seems reasonable to do this for 1.12 and be ahead of the game, @Owen would
you please spawn that as a separate release 1.12 thread? thanks, eB
On Fri, Feb 28, 2020 at 11:56 AM Owen Nichols wrote:
> +1
>
> We should have done this as soon as SSL/TLS was ready. Better late than
> never!
>
> W
+1
On 2/28/20, 11:43 AM, "Bill Burcham" wrote:
I propose we deprecate Geode’s proprietary UDP message privacy algorithm
based on the Diffie-Hellman key exchange protocol. This would deprecate:
ConfigurationProperties.SECURITY_UDP_DHALGO
String DistributionConfig.getSec
+1 to adding the deprecation. But I would prefer that we give users more
notice than 3 months.
maybe we deprecate it in 1.14
--Udo
On 2/28/20 1:00 PM, Ernest Burghardt wrote:
+1
seems reasonable to do this for 1.12 and be ahead of the game, @Owen would
you please spawn that as a separate rel
bumping this out to DevList as something went wrong in the mail system...
On 2020/02/28 19:27:42, Bruce Schuchardt wrote:
> During a refactor the default ack-wait-threshold was changed from 15 to 51.
> This will affect any deployment that doesn’t set its own threshold.
>
> The ack-wait-thresh
I’m switching to a new email account.
got it... domain still looks weird
On Fri, Feb 28, 2020 at 1:10 PM Bruce Schuchardt
wrote:
> I’m switching to a new email account.
>
Udo, are you proposing to deprecate in 1.12 and remove in 1.14?
> On Feb 28, 2020, at 1:03 PM, Udo Kohlmeyer wrote:
>
> +1 to adding the deprecation. But I would prefer that we give users more
> notice than 3 months.
>
> maybe we deprecate it in 1.14
>
> --Udo
>
> On 2/28/20 1:00 PM, Ernest
Hello devs,
I'd like to include the fix for GEODE-782 [1] in release 1.12.0.
During a refactor the default ack-wait-threshold was changed from 15
to 51. This will affect any deployment that doesn’t set its own
threshold.
The ack-wait-threshold determines how long we wait for a response to a
me
+1 for bringing this fix to 1.12 (assuming the change was unintentional?)
Any ideas how much performance improvement this is anticipated to restore?
> On Feb 28, 2020, at 1:06 PM, Ernest Burghardt wrote:
>
> bumping this out to DevList as something went wrong in the mail system...
>
> On 2020/
yes, it was just a transposition/typo when the defaults were
refactored/moved
On Fri, Feb 28, 2020 at 1:14 PM Owen Nichols wrote:
> +1 for bringing this fix to 1.12 (assuming the change was unintentional?)
>
> Any ideas how much performance improvement this is anticipated to restore?
>
> > On Fe
+1
On Fri, Feb 28, 2020 at 1:15 PM Ernest Burghardt
wrote:
> yes, it was just a transposition/typo when the defaults were
> refactored/moved
>
> On Fri, Feb 28, 2020 at 1:14 PM Owen Nichols wrote:
>
> > +1 for bringing this fix to 1.12 (assuming the change was unintentional?)
> >
> > Any ideas
Welcome Derrick! Please shout out if you need any help.
Anthony
> On Feb 28, 2020, at 12:53 PM, Owen Nichols wrote:
>
> Welcome Derrick, you should have access to Geode Jira now
>
> https://issues.apache.org/jira/projects/GEODE/issues
>
>
>> On Feb 26, 2020, at 8:41 AM, Derrick Anderson
There appears to be consensus that this is a critical fix.
The following commit has been brought into release/1.12 as the
critical fix for GEODE-7829:
git cherry-pick -x dfa3326e674278f38673c9508a13af752ae90e28
GEODE-7829 has been marked as 'resolved in' 1.12.
Regards
EB
On Fri, Feb 28, 2020
Ok, thanks! I've submitted https://github.com/apache/geode/pull/4748 to
revert the change. I'll be offline for a while so feel free to merge it if
it passes.
Thanks,
Kirk
On Thu, Feb 27, 2020 at 5:19 PM Owen Nichols wrote:
> While changing a void method to have a return type does not break sour
+1
If the original reason for the 25 file limit was to prevent StressNewTest
taking too long, then the concourse timeout renders the restriction
redundant. Also, I'd think that if anything, the more files a PR changed,
the more interested we would be in running StressNewTest. Allowing it to
just b
Yes, the proposal was deprecation notice in 1.12 and remove in 1.13..
That does not leave users much time to react. So if we remove in 1.14,
then users have at least 2 release cycles before we do it.
--Udo
On 2/28/20 1:11 PM, Owen Nichols wrote:
Udo, are you proposing to deprecate in 1.12 an
39 matches
Mail list logo
