Re: [VOTE] Apache Geode 1.15.0.RC1

+1 on macOS… downloaded examples and verified they all run and pass BUILD SUCCESSFUL in 18m 58s 267 actionable tasks: 267 executed Downloaded Geode tarball and verified SHA on https://dist.apache.org/repos/dist/dev/geode/1.15.0.RC1/apache-geode-1.15.0-src.tgz.sha256 matches checksum on

Re: [Discuss] New feature work approval state in Geode project?

We have an RFC process "to get to consensus faster and ultimately get to execution faster". But I think in general folks tend to only do an RFC for a "big" change. Bug tickets, and particularly feature tickets are left as a gray area. A google search for "most successful open source project"

Re: JDK 16 Support?

John, this doesn't speak to the general question of JDK version support. But the particular stack trace you showed makes me wonder if the fix for GEODE-9081 (landed on 3/30/21 on the develop branch) might get you a little bit further. That commit 7ac9d7e4f0d04c99298067ca0611d9326e96d9cf eliminated

Re: [VOTE] Requiring final keyword on every parameter and local variable

+1 I am 100% for putting final everywhere it is possible to put it. Call this the "hard final" position. What I've been advocating for, intermittently, in PRs (for example, in PR #6310 ) is more of a "soft final" position which I

Re: Question regarding VersionRequest/VersionResponse messages

Jakov, VersionRequest/VersionResponse is understood by the 8.1.x/GFE_81 product versions. I don't know what Geode's stance is on supporting old locator versions. I see the recent: GEODE-8837 - Establishes GFE_81 as the oldest supported client. Does that imply that GFE_81 is now the oldest

Re: geode docker question

Great (and timely) question Barry! And great answers from Mark and John. The question is timely because we recently addressed some similar needs in the development of the new Dockerized acceptance tests for the new TLS SNI features. I've taken a stab at a tutorial that leverages some of those

Back-Port GEODE-8240 to 1.12, 1.13

I'd like permission to back-port the fix for rolling upgrade bug GEODE-8240 to support/1.12 and support/1.13 -Bill

Re: Problem in rolling upgrade since 1.12

ption: Could > not create an instance of > org.apache.geode.management.internal.configuration.domain.Configuration . > > I have pushed another commit in the draft I sent before containing the new > test case. > > /Alberto G. > > From: Bill Burcham > Sent: Thursday, June 11, 2020 1:53 AM &g

Re: Problem in rolling upgrade since 1.12

Ernie made us a ticket for this issue: https://issues.apache.org/jira/browse/GEODE-8240 On Mon, Jun 8, 2020 at 12:59 PM Alberto Gomez wrote: > Hi Ernie, > > I have seen this problem in the support/1.13 branch and also on develop. > > Interestingly, the patch I sent is applied seamlessly in my

Re: geode-assembly fails with SIGABRT

Kirk: what happens when you run ./gradlew :geode-assembly:docker in your local dev environment? Does it break the same way? If not, then I surmise this may be due to a recent configuration change to the AWS AMI used for CI. This bug report on Docker credentials helper has some stack traces that

Re: [PROPOASAL] backport GEODE-8144

+1 On Thu, May 28, 2020 at 11:49 AM Ernie Burghardt wrote: > +1 > > On 5/27/20, 1:35 PM, "Bruce Schuchardt" wrote: > > This ticket has two PRs. One passed all normal CI runs but then we > hit a faulty test that failed on a Windows machine. There’s a new PR that > fixes that test & has

Re: RFC - Client side configuration for a SNI proxy

mplementation. > > -1 to Bill's approach. > > @Bill, could we amend the RFC to favor this approach? > > --Udo > > On 3/11/20 11:30 PM, Jacob Barrett wrote: > > -1 > > > > I hate to do this but I really feel like we went backwards on this > change. > &

Re: RFC - Client side configuration for a SNI proxy

gt;>> return type != null && type.isSecure(); > >>>>> } > >>>>> } > >>>>> > >>>>> Then: > >>>>> > >>>>> StreamSupport.stream(..) > >>>>> *.filter(Prox

Re: RFC - Client side configuration for a SNI proxy

roxy types soon, and then > >> what's the value of having a single method (and multiple enums) versus > >> multiple methods (and no enum). If we thought the proxyAddress parameter > >> would carry different information across proxy types that might tilt us > >> towa

Re: RFC - Client side configuration for a SNI proxy

, 2020 at 10:54 AM Bill Burcham wrote: > By popular demand we are extending the RFC review period. I know Udo asked > for Friday (and Joris +1'd it), but since this is a small RFC, we'd like to > try to close it by Wednesday, March 11, ok? > > On Mon, Mar 9, 2020 at 10:39 AM Jacob

Re: RFC - Client side configuration for a SNI proxy

t is your thinking about using the enum vs specific named > API’s (e.g. setPoolProxyWithSNI). > > > > Currently the definition of the proxyAddress seems to be dependent of > the proxy type. Did you consider stronger typing using an URI parameter > type? > > &

RFC - Client side configuration for a SNI proxy

Please review the RFC for *Client side configuration for a SNI proxy*: https://cwiki.apache.org/confluence/display/GEODE/Client+side+configuration+for+a+SNI+proxy Please comment by Monday, March 9, 2020. Regards, Bill and Ernie

Let's Deprecate the SECURITY_UDP_DHALGO Configuration Property

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

Re: [DISCUSS] Move TcpServer and friends to new geode-tcp-server module

p modularization effort was > > >> started.. And maybe this is the time where we need to take a step > back, > > >> look at this from a higher perspective and decide if membership is > > >> really still the priority here with serialization and transport > >

[DISCUSS] Move TcpServer and friends to new geode-tcp-server module

Dear Geode, In support of the Membership modularization efforts https://cwiki.apache.org/confluence/display/GEODE/Move+membership+code+to+a+separate+gradle+sub-project, we would like to move the types in the org.apache.geode.distributed.internal.tcpserver package (i.e. the TcpServer class and

Re: Deprecate SystemFailure Class

at 8:26 AM Bruce Schuchardt wrote: > Bill, are you proposing to remove calls to > SystemFailure.initiateFailure() and remove all of the emergency-class > stuff or just add a Deprecated flag to SystemFailure? > > > On 10/28/19 12:01 PM, Bill Burcham wrote: > > The SystemFai

Deprecate SystemFailure Class

The SystemFailure class is a clearing house for detecting and attempting to mitigate SystemFailure exceptions e.g. VirtualMachineError and OutOfMemoryError. This class should not exist. SystemFailure exceptions should be allowed to percolate up and cause the JVM to terminate as soon as possible

Re: resource manager requirements & recommendations

ah like CMSInitiatingOccupancyFraction for CMS On Wed, Sep 18, 2019 at 8:02 AM Anthony Baker wrote: > I’m really interested to follow the ZGC engine and understand how well it > works for geode. The -XX:SoftMaxHeapSize option in JDK 13 (just released) > *might* be the key for us. > > Anthony >

Re: Unnecessary uses of final on local variables

-1 to the proposal as I understand it: Premise: a. Because the "final" modifier on local variables serves no function other than to inform compiler optimization and… b. because the compiler can tell if a variable is "effectively final" without an explicit "final" modifier in the source code

Re: Unnecessary uses of final on local variables

y may well be the enemy, but I don’t think this is the > >>> construct > >>>>> that gets us much/if any closer. > >>>>> > >>>>> In local variables and parameters final feels like noise to me, and > in > >>>>> fact

Re: Unnecessary uses of final on local variables

The final keyword is not redundant—quite the opposite—it's extremely valuable. Local variables are not, in general, final, unless you declare them as such. That being the case, it is not redundant to declare local variables "final". What the compiler will do for you, is _if_ it can ensure that a

need edit access to ciwiki

I need edit access to https://cwiki.apache.org for: bill.burc...@gmail.com The immediate need is to update some UML here: https://cwiki.apache.org/confluence/display/GEODE/HA+Client+Event+Queues Thanks!

Re: [DISCUSS] Static analysis of statics

On Wed, Feb 13, 2019 at 9:03 AM Dan Smith wrote: … > I can switch them to @MakeReferentImmutable if that makes more sense. > > -Dan I think you understand my concerns. I trust you to decide what's best.

Re: [DISCUSS] Static analysis of statics

I think the @Immutable anno in *Java Concurrency and Practice* is a class annotation—not a field one. Looking at that PR, it looks like this @Immutable anno is usable both on a type (class) and on a field. Is that an oversight? If not, then what does it mean? Does @Immutable on a field mean

Re: [DISCUSS] Replace @TestingOnly with @VisibleForTesting

+1. Annotation beats comment in this case, and @VisibleForTesting is more descriptive than our old anno. On Mon, Dec 17, 2018 at 3:43 PM Jinmei Liao wrote: > +1. Yes, the original intention was exactly as @VisibleForTesting. > > On Mon, Dec 17, 2018 at 2:45 PM Galen O'Sullivan > wrote: > > >

Re: Questions about Poms and Publishing

@Patrick Rhomberg I've never seen the dependencyManagement element survive in a published POM before. Since it sounds like you're asserting that you saw that element in a published POM (published by Gradle), I decided to verify that. I ran this from the Geode develop branch just now: ./gradlew

Re: [PROPOSAL] Add getCache and getLocator to Launchers

+1 for exposing getCache() on CacheLauncher instances. Death to all singletons! I'm less certain about the wisdom of exposing a getCache() on LocatorLauncher instances. Seems like it would be better to let clients call getLocator() on LocatorLauncher instances, then they can do the traversal to

Re: [Discuss] Transitive dependencies and internal .pom changes

lug-in documentation is here [ > > https://github.com/nebula-plugins/gradle-lint-plugin/ > > wiki/Unused-Dependency-Rule > > ] > > > > Thank you, > > -Robert Houghton > > > > On Fri, Sep 28, 2018 at 10:18 AM Bill Burcham > wrote: > > > > > From

Re: [Discuss] Transitive dependencies and internal .pom changes

>From the PR, Anthony, it seems to me that Patrick is proposing that each build.gradle be explicit about mentioning the "things" it depends on. For example: [image: image.png] Look at how geode-connectors goes from mentioning a few dependencies to mentioning many more. The value of this is that

please give me (bburcham) permission to assign himself Jira tickets

I made a ticket and would like to assign it to myself. Please let me. -Bill