Re: [PROPOSAL] merge GEODE-8259 to support branches

...and there it is! On Tue, Jun 30, 2020 at 4:10 PM Dave Barnes wrote: > Strange -- I received the two votes 9 minutes before I got the original > message. > I'm heading out for the day, so Gester, if you get that third vote, go > ahead and merge. > Cheers, > Dave > > On Tue, Jun 30, 2020 at

Re: [PROPOSAL] merge GEODE-8259 to support branches

Strange -- I received the two votes 9 minutes before I got the original message. I'm heading out for the day, so Gester, if you get that third vote, go ahead and merge. Cheers, Dave On Tue, Jun 30, 2020 at 3:58 PM Jinmei Liao wrote: > +1 > > From: Owen Nichols

Re: [PROPOSAL] merge GEODE-8259 to support branches

+1 On Tue, Jun 30, 2020 at 3:58 PM Jinmei Liao wrote: > +1 > > From: Owen Nichols > Sent: Tuesday, June 30, 2020 3:56 PM > To: dev@geode.apache.org > Subject: Re: [PROPOSAL] merge GEODE-8259 to support branches > > +1 > > On 6/30/20, 3:51 PM, "Xiaojian Zhou"

[PROPOSAL] merge GEODE-8259 to support branches

Customer encountered a singlehop getAll failure due to SerializationException which is identified as socket error. The solution is to retry the getAll in this race condition (currently we did not retry). The fix is tested in both develop and support branches. The fix is conservative and very

PROPOSAL to bring GEODE-8259 to support branches

Customer encountered a singlehop getAll failure due to SerializationException which is identified as socket error. The solution is to retry the getAll in this race condition (currently we did not retry). The fix is tested in both develop and support branches. The fix is conservative and very

Re: [PROPOSAL] merge GEODE-8259 to support branches

+1 From: Owen Nichols Sent: Tuesday, June 30, 2020 3:56 PM To: dev@geode.apache.org Subject: Re: [PROPOSAL] merge GEODE-8259 to support branches +1 On 6/30/20, 3:51 PM, "Xiaojian Zhou" wrote: Customer encountered a singlehop getAll failure due to

Re: [PROPOSAL] merge GEODE-8259 to support branches

+1 On 6/30/20, 3:51 PM, "Xiaojian Zhou" wrote: Customer encountered a singlehop getAll failure due to SerializationException which is identified as socket error. The solution is to retry the getAll in this race condition (currently we did not retry). The fix is tested in both

Re: Proposal to bring GEODE-8315 (shiro upgrade) to support branches

Thanks for taking care of that, Owen. On Tue, Jun 30, 2020 at 9:38 AM Owen Nichols wrote: > Backported to support/1.13 and support/1.12 > > On 6/30/20, 9:37 AM, "Robert Houghton" wrote: > > +1 > > From: Dick Cavender > Date: Tuesday, June 30, 2020 at 9:14 AM > To:

[PROPOSAL] merge GEODE-8259 to support branches

Customer encountered a singlehop getAll failure due to SerializationException which is identified as socket error. The solution is to retry the getAll in this race condition (currently we did not retry). The fix is tested in both develop and support branches. The fix is conservative and very low

Re: This week's mass-test run results

Yes, I'm still working on JMXMBeanReconnectDUnitTest. The test fails intermittently due to a couple product bugs that the test found. I've filed separate tickets for these bugs and I expect the test's flakiness to be fixed when the bugs have been addressed. -Kirk On Tue, Jun 30, 2020 at 2:57 PM

This week's mass-test run results

Hi everyone, Just like Mark did two weeks ago, I'd like to bring some attention to our mass test runs. These now run in the pipeline once a week. The results should typically be available on Tuesdays.

Re: Us vs Docker vs Gradle vs JUnit

It feels like, first, we should choose right resources/tools that is suited for the task in hand and helps in achieving the expected result (Testing - easier to develop, run, monitor and report); and then invest in that once. Even if it means to add new tools/subroutines in the product. E.g.:

Re: Us vs Docker vs Gradle vs JUnit

> On Jun 30, 2020, at 2:10 PM, Anthony Baker wrote: > > When evaluating technical alternatives I think it’s helpful to look at data. > Has anyone recently tried to run the entire dunit test suite in parallel w/o > docker? How many tests need to be changed? IIRC, there would be non-trivial

Re: Us vs Docker vs Gradle vs JUnit

When evaluating technical alternatives I think it’s helpful to look at data. Has anyone recently tried to run the entire dunit test suite in parallel w/o docker? How many tests need to be changed? IIRC, there would be non-trivial work in product code around statics and system properties as

Re: Us vs Docker vs Gradle vs JUnit

> On Jun 30, 2020, at 12:28 PM, Jinmei Liao wrote: > > I would vote for fixing the tests to use gradle's normal forking. If we are > going to invest time and effort, let's invest in an option that can reduce > our dependencies I agree wholeheartedly! Dale

Re: Us vs Docker vs Gradle vs JUnit

+1 for fixing the tests. It'll be a lot of work, but it'll only be a lot of work once, as opposed to taking on maintenance of our own custom Docker plugin, which will be an ongoing effort and not at all immune from getting broken again at some point in the future.

Re: Us vs Docker vs Gradle vs JUnit

I would vote for fixing the tests to use gradle's normal forking. If we are going to invest time and effort, let's invest in an option that can reduce our dependencies From: Jacob Barrett Sent: Tuesday, June 30, 2020 11:30 AM To: dev@geode.apache.org Subject:

Us vs Docker vs Gradle vs JUnit

All, We are in a bit of a pickle. As you recall from a few years back in an effort to both stabilize and parallelize integration, distributed and other integration/system like test we use Docker. Many of the tests reused the same ports for services which cause them to fail or interact with

Re: negative ActiveCQCount

I think *show metrics --categories=query* is showing you the query stats from DistributedSystemMXBean (see ShowMetricsCommand#writeSystemWideMetricValues). DistributedSystemMXBean aggregates values across all members in the cluster, so I would have expected activeCQCount to initially show a value

Re: Proposal to bring GEODE-8315 (shiro upgrade) to support branches

Backported to support/1.13 and support/1.12 On 6/30/20, 9:37 AM, "Robert Houghton" wrote: +1 From: Dick Cavender Date: Tuesday, June 30, 2020 at 9:14 AM To: dev@geode.apache.org Subject: RE: Proposal to bring GEODE-8315 (shiro upgrade) to support branches +1

Re: Proposal to bring GEODE-8315 (shiro upgrade) to support branches

+1 From: Dick Cavender Date: Tuesday, June 30, 2020 at 9:14 AM To: dev@geode.apache.org Subject: RE: Proposal to bring GEODE-8315 (shiro upgrade) to support branches +1 -Original Message- From: Ju@N Sent: Tuesday, June 30, 2020 9:12 AM To: dev@geode.apache.org Subject: Re: Proposal to

RE: Proposal to bring GEODE-8315 (shiro upgrade) to support branches

+1 -Original Message- From: Ju@N Sent: Tuesday, June 30, 2020 9:12 AM To: dev@geode.apache.org Subject: Re: Proposal to bring GEODE-8315 (shiro upgrade) to support branches +1 On Tue, 30 Jun 2020 at 17:03, Owen Nichols wrote: > Recently shiro-1.5.2.jar is getting flagged for

Re: Proposal to bring GEODE-8315 (shiro upgrade) to support branches

+1 On Tue, 30 Jun 2020 at 17:03, Owen Nichols wrote: > Recently shiro-1.5.2.jar is getting flagged for critical security > vulnerability CVE-2020-11989. > > Analysis shows that Geode does not use Shiro in a manner that would expose > this vulnerability. > > The risk of bringing GEODE-8315 is

Proposal to bring GEODE-8315 (shiro upgrade) to support branches

Recently shiro-1.5.2.jar is getting flagged for critical security vulnerability CVE-2020-11989. Analysis shows that Geode does not use Shiro in a manner that would expose this vulnerability. The risk of bringing GEODE-8315 is very low (difference between Shiro 1.5.2 and 1.5.3 is bugfix only).

negative ActiveCQCount

Hi geode-dev, I have a question about CQ(https://issues.apache.org/jira/browse/GEODE-8293). If we run CQ it register cq on one of the servers(setPoolSubscriptionRedundancy is 1) and increment activeCQCount. As I understand then it processInputBuffer to another server and there is