Re: [PROPOSAL] Relocate Geode Docs from code repo to seperate repo

I don’t see any downsides to this approach. We already do this for other assets like examples, native, site, and benchmarks. > On Jun 14, 2022, at 12:03 PM, Dave Barnes wrote: > > ⚠ External Email > > I'd like to move the doc sources for the Geode User Guide from the code > repo >

Re: [DISCUSS] Alignment of values disabling idleTimeout/loadConditioningInterval between Geode client APIs

I have raised this issue a few times. All over our API we are inconsistent with time. Either in the use of sentinel values or time units. Given the current API and breaking that is not an option until some major release the best thing you can do is not use the sentinel values. If you want

Re: [PROPOSAL] Remove warning logs from FunctionException

On Mar 30, 2022, at 9:45 AM, Alberto Gomez mailto:alberto.go...@est.tech>> wrote: The idea would not be to remove 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

Re: Commit message review opt-in

> On Mar 4, 2022, at 1:22 PM, Owen Nichols wrote: > > Unfortunately, I cannot add anyone to the opt-in list without a record of the > request on the dev list (much like wiki, jira, or similar requests). Source? Given this is not a request to gain access to any protected project assets I

Re: Commit message review opt-in

Can we please agree to send requests for inclusion directly to onich...@vmware.com rather than back to this thread. On Mar 4, 2022, at 1:09 PM, Owen Nichols mailto:onich...@vmware.com>> wrote: Thanks Udo, I have added kohlmu-pivotal as requested, for non-draft PRs

Re: Question about crossing NUMA boundary

The NUMA settings really only affects transient / non-shared objects. These are objects where the thread that allocated them is most likely to be the one to access them and in a short enough time span that the thread is not scheduled in a different NUMA zone core. Non-transient and shared

Changes to Public API Return Only Interfaces

Devs, First off, this is a very forward looking discussion around something that will affect upcoming major releases when deprecating public APIs. One of the issues I am finding when investigating a few deprecated APIs for removal is that the deprecation hasn’t cascaded through to all the

Re: [DISCUSS] proposal to pare down old-version testing

Yes! This! 100%! > On Dec 22, 2021, at 7:14 PM, Owen Nichols wrote: > > Since adopting our N-2 support policy, the list of released versions in > /settings.gradle has ballooned to over 30 entries [1]. > > CI tests use this list to confirm that we don’t break rolling upgrade ability > or

Re: [RFC] Versioning Extension

A revision was made based on feedback. The getDetails method now returns a map. See updated PR #7074 [1] for POC. [1] https://github.com/apache/geode/pull/7074 On Nov 2, 2021, at 12:45 PM, Jacob Barrett mailto:jabarr...@vmware.com>> wrote: Devs, Please review the new RFC for Vers

[RFC] Versioning Extension

Devs, Please review the new RFC for Versioning Extension [1]. For an example please find a POC of the RFC as PR #7071 [2]. Thanks, Jake [1] https://cwiki.apache.org/confluence/display/GEODE/Versioning+Extension [2] https://github.com/apache/geode/pull/7071

Re: Added Support for JUnit 5

This is amazing! > On Oct 12, 2021, at 3:37 PM, Dale Emery wrote: > > In September 2021, Geode added support for writing and running tests using > JUnit 5. > > Most Geode modules now support JUnit 5. For most Geode modules, you can now > write each test class using either JUnit 5's "Jupiter"

Apache Geode Community Meeting 10/7/2021

Devs, Sorry for the late notice but due to a family emergency I need to skip presenting the pitch for modularizing our feature work at the meeting tomorrow. It looks like I am the only item on the agenda then perhaps we should postpone this meeting until next week. -Jake

Re: [DISCUSS] Upgrading to Lucene 7.1.0

eadCommit(SegmentInfos.java:286) > [vm2_v1.2.0] at > org.apache.lucene.index.IndexWriter.(IndexWriter.java:938) > [vm2_v1.2.0] at > org.apache.geode.cache.lucene.internal.IndexRepositoryFactory.computeIndexRepository(IndexRepositoryFactory.java:84) > [vm2_v1.2.0] at > org.apache.geode.cache.lucene.internal.PartitionedRepositoryManager.computeRepos

Re: [DISCUSS] Upgrading to Lucene 7.1.0

> On Sep 27, 2021, at 11:48 AM, nabarun nag wrote: > > Recently, a commit was pushed to develop which upgraded the Lucene > version used in Apache Geode to 7.1.0. These new Lucene indexes are > not compatible with the previous versions hence it breaks the rolling > upgrade contract. We are no

Re: PROPOSAL: Remove WAN TX Batching Serialization Changes

lberto From: Jacob Barrett mailto:jabarr...@vmware.com>> Sent: Wednesday, September 22, 2021 7:44 PM To: dev@geode.apache.org<mailto:dev@geode.apache.org> mailto:dev@geode.apache.org>> Subject: Re: PROPOSAL: Remove WAN TX Batching Serialization Changes On Sep 22, 2021, at

Re: PROPOSAL: Remove WAN TX Batching Serialization Changes

> On Sep 22, 2021, at 12:31 AM, Alberto Gomez wrote: > > Hi, > > Jake, why do you say the feature is not complete in 1.14.0? In my view, it > works as it was designed and as documented. Sorry, I was misinformed and misjudge the state. I meant no disrespect. > I do not think it makes sense

Re: PROPOSAL: Remove WAN TX Batching Serialization Changes

> On Sep 21, 2021, at 2:32 PM, Anilkumar Gingade wrote: > Is the idea just creating the Jira tickets? It is not clear from here, if it > will be owned and completed by 1.15. I will create two tickets: 1) To address 1.14 and anyone can pick this up, but if nobody does I will. 2) To block 1.15

PROPOSAL: Remove WAN TX Batching Serialization Changes

Devs, In addition to my discussion regarding the modularization of the WAN TX batching implementation I would like to propose that we remove the serialization changes that went into 1.14 to support it. Since the feature is not complete in 1.14 this should only impact the associated tests in

Re: [DISCUSS] Modularizing new WAN TX Batching (and Modularization Efforts in General)

steps to follow in the right direction for >> this and future features. >> >> I would be interested in attending to a live walkthrough over the details of >> the changes. >> >> Thanks, >> >> Alberto >> >&

Re: [DISCUSS] Modularizing new WAN TX Batching (and Modularization Efforts in General)

> > @Jake, you want to discuss at the next Geode Community meeting in Oct? > > Anthony > > >> On Sep 20, 2021, at 1:48 PM, Jacob Barrett wrote: >> >> Devs, >> >> We need to be doing a better job with implementing new features in a modular >

[DISCUSS] Modularizing new WAN TX Batching (and Modularization Efforts in General)

Devs, We need to be doing a better job with implementing new features in a modular and plugable way. We have had discussions in the past but we haven’t been the best at sticking to it. Most recently we began work on a modified version of WAN that supports transactional batching. Rather than

Re: Proposal - unprotect develop branch of geode-native

It is actually worse than described right now. Even the combining of the PRs wouldn’t pass because they can’t affect the images themselves, which need patching to pass. The images are tainted by a previous merge too. So pinning back to an older image allows one of the fixes to pass but the

Re: [DISCUSS] Backporting to support branches

Why not a model where the release manager is a blocking review and let the author merge only when they blocking review is complete? That makes the process largely identical to that of the develop branch abs removes this ambiguity of who merges and when. > On Jun 29, 2021, at 4:19 PM, Nabarun

Re: [DISCUSS] Rebase and Squash Options on Github develop

> On Jun 28, 2021, at 12:38 PM, Nabarun Nag wrote: > > > I would like to propose to that we set the GitHub setting on develop PR to > rebase and squash buttons. Does this proposal remove the option to “Rebase and Merge?

Re: [DISCUSS] Remove stress-new-test-openjdk11 requirement from PRs

I think repeated tests shouldn’t be a blocker to merging for the reasons outlined below. A committer that is a good steward for the project should be allowed to make the judgement call when merging a PR. We have placed too many rigid processes in place that eliminated the good judgement of

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

> On May 28, 2021, at 3:45 PM, Kirk Lund wrote: > > Another thought I have is that if the "fix" for a bug will require any sort > of new User API or configuration properties (ie gemfire.properties), then > we should always treat that as a new feature that requires going through > our RFC

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

> On May 28, 2021, at 11:24 AM, Mark Hanson wrote: > > I think the key difference between what Bill and Jake are saying is that Bill > is saying a new feature needs approval in a more structured way. I think > Bill's process is open the jira, then it is "approved" or "won't do" then > work

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

> On May 28, 2021, at 10:48 AM, Bill Burcham wrote: > > A google search for "most successful open source project" lists Apache > Cassandra at the top. When a bug is submitted to the Cassandra Jira it > starts in the TRIAGE NEEDED state. Ostensibly after triage, it moves to the > OPEN state

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

Can you provide a more concrete example? I don’t understand why there would be a JIRA written without a reasonable belief it would be executed on. A JIRA that is later determined to not be worth the effort, not a bug, or whatever, should just closed as “won’t fix”. > On May 28, 2021, at 10:36

Re: Cleaning up the codebase - use curly braces everywhere

Thanks you!! I believe these targeted whole source tree changes like this are great. As long as it isn’t a mix of hand rolled and automated changes I think a reviewer can trust that the if heart of the change is correct there is no reason to review all 3000 lines changed. I think it gets harder

Re: DISCUSSION: Geode Native C++ Style and Formatting Guide

be > focused on stuff that's relevant to the fix/feature, and mixing it with > random style guide refactoring, I feel, muddies the waters for future > maintainers. > >Thanks, > >Blake > >-Original Message- >From: Jacob Barrett >Sent: Saturda

Re: DISCUSSION: Geode Native C++ 17 adoption

On May 4, 2021, at 12:33 PM, Charlie Black mailto:cbl...@vmware.com>> wrote: Another viewpoint is this is a library and that library can be used by older applications. So being cutting edge on the complier on the library does not increase the adoption of Geode. The public API can’t change

Re: DISCUSSION: Geode Native C++ Style and Formatting Guide

> On May 4, 2021, at 7:59 AM, Mario Salazar de Torres > wrote: > > Sure, gladly . Let me put up the info and I will open the discussion. > And sorry for polluting this topic regarding Style and Formatting :S No apologies! I just think this topic has a much bigger scope than documenting our

Re: DISCUSSION: Geode Native C++ Style and Formatting Guide

> preference for bug fixes and feature work is that all of the code changes be > focused on stuff that's relevant to the fix/feature, and mixing it with > random style guide refactoring, I feel, muddies the waters for future > maintainers. > > Thanks, > > Bla

Re: DISCUSSION: Geode Native C++ Style and Formatting Guide

> On May 3, 2021, at 11:23 AM, Blake Bender wrote: > > My $0.02 on these: > > Things I'd like to see us conform to Google style on: > * I'd be happy to move to C++ 17 This is likely an ABI change and certainly moves the minimum runtime library. The latter might be hard in a minor release.

Re: DISCUSSION: Geode Native C++ Style and Formatting Guide

evant to the fix/feature, and mixing it with > random style guide refactoring, I feel, muddies the waters for future > maintainers. > > Thanks, > > Blake > > -Original Message- > From: Jacob Barrett > Sent: Saturday, May 1, 2021 9:21 AM > To: de

Re: DISCUSSION: Geode Native C++ Style and Formatting Guide

Great call outs! > On May 1, 2021, at 7:57 AM, Mario Salazar de Torres > wrote: > > 1. Member variables names as of Google style guide requires a '_' char to > be added at the end so it can be identified. Should we also adopt that? > For example, imagine you have a region mutex, so, should

DISCUSSION: Geode Native C++ Style and Formatting Guide

Team, We haven’t been good about documenting our style and formatting guidance. Like the Java sources are loosely styled after the Google Java Style Guide, the C++ sources are loosely styled after the Google C++ Style Guide. We deviate in some places from the Google C++ Style Guide. Without

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

> On Apr 15, 2021, at 7:49 PM, Udo Kohlmeyer wrote: > > @jake, you are correct, I did miss the LOCAL variable out of the subject. > :face_palm: > > Yes, adding "final" to LOCAL variables will be HUGELY beneficial in this > regard. Have we seen any performance improvement after having

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

> On Apr 14, 2021, at 7:46 PM, Udo Kohlmeyer wrote: > @Jake the idea of smaller methods is great and we should ALWAYS strive for > that. But that argument is completely irrelevant in this discussion. As > making method arguments final does not naturally guide a developer to > creating

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

If a method is longer than a handful of lines and I go in to refactor it I am going to start by making every variable I find final. Then I am going to figure out how to keep them final. By doing so you naturally produce smaller functional methods that are usually independently unit testable.

Re: Stats deprecations?

The deprecated int methods are there for API compatibility but are backed by the LongAdder that backs the long stats. If you find any stats still using the int methods feel free to update them to use the long methods. See https://issues.apache.org/jira/browse/GEODE-6424 and related tickets.

Re: [RFC PROPOSAL] Geode Compatibility with Redis data sharding and cluster changes

This work is slated for post 1.14 release. This work is also a breaking change to the 1.14 version. Are we going to mark the 1.14 version of Compatibility with Redis as beta or something to indicate it’s not a stable feature and breaking changes are coming? > On Apr 9, 2021, at 8:10 AM, Jens

Re: [DISCUSS] Pull Request (PR) check list

I honestly ignore the checklist. > On Apr 8, 2021, at 2:24 PM, Anilkumar Gingade wrote: > > It is been some time we have been using a standard check-list for PRs. It > may be time to look back and see if any of them were obsolete; and add new > items based on the PR review experience. > >

Re: Deleting old references to ticket numbers and avoiding new ones

+1 I am pretty sure we had this discussion a long time ago and agreed to it. I can’t view the archives though since it appears markmail doesn’t like newer versions of Chrome or Safari. -Jake > On Mar 30, 2021, at 2:24 PM, Hale Bales wrote: > > Hi all, > > I have noticed in the past that

Re: [DISCUSS] removal of experimental Protobuf client/server interface

I say delete it so you can move forward. If someone wants it in a subproject repo bad enough they can pull it from the previous commit. It is source control after all so it never really goes away. -Jake > On Mar 30, 2021, at 8:01 AM, Bruce Schuchardt wrote: > > Does anyone want to take on

Re: Concourse geode-native permissions

You can also request permission for yourself. If it is a PR you can also push an empty commit, though this will trigger all jobs. Also, if this is a PR make sure you use the re-run with same inputs button, otherwise it will run the most recent PR and not necessarily yours. > On Mar 17, 2021,

Re: [DISCUSS] CODEOWNERS mechanism feedback

> On Mar 17, 2021, at 9:38 AM, Nabarun Nag wrote: > > "the review process is taking longer now. " > I agree that the review process is taking a bit longer, but that is the price > I believe needs to be paid to improve the probability of good quality code is > being merged to Geode. More

Re: Proposal: Add GEODE-8950 (performance degradation in P2pPartitionedPutLongBenchmark) to 1.14 blockers list

That 4.6% degradation is within our thresholds so it is possible this came in well before the first time it was detected. Some context on the benchmark for those unfamiliar: P2pPartitionedPutLongBenchmark performs a fire hose of puts with Long key and Long value directly from each of the two

Re: [Proposal] Geode Native Library Versioning

o work on > the testing approach. > > BR/ > Mario. > > From: Jacob Barrett > Sent: Monday, February 1, 2021 4:34 PM > To: dev@geode.apache.org > Subject: Re: [Proposal] Geode Native Library Versioning > > > On Jan 29, 2021, at 3:47 PM,

Re: Cached regions are not synchronized after restore

For clarification, does the a Java client show the same behavior in missing the events after restore or is this something you are saying is unique to the native clients? > On Feb 26, 2021, at 4:48 AM, Mario Salazar de Torres > wrote: > > Hi, > These months I have been tackling a series of

Re: Concourse access

I made the pipelines public. If you want more access than that let us know. Before that though can you give me a sense for the usability of the public access on the pipelines? Thanks, Jake > On Feb 25, 2021, at 8:31 AM, Mario Salazar de Torres > wrote: > > Hi everyone, > I am trying to

Re: Geode Native Tooling

veryone in the future. > However, today I was running one PR on Concourse and I noticed that Windows > 2019 job was failing. Could it be that there are some details to polish for > that pipeline? > > BR, > Mario. > ____ > From: Jacob Barrett > Sen

Geode Native Tooling

Hey Geode Native devs, You may have noticed this new CI that looks a lot like the Java CI. PRs will now be executed against this CI and several platforms. All unit and integration tests are executed on all the platforms as well. It also takes over the tasks of the old Travis CI of validating

Re: [DISCUSS] - RFC make key and trust stores reload automatically upon change

Looks good to me. Be aware that users can provide custom key/trust managers and that behavior should be preserved without them being wrapped with this new file watching manager. -Jake > On Feb 4, 2021, at 7:06 AM, Joris Melchior wrote: > > Hi Geode developers, > > I have published an RFC

Re: Question about closing of all connections towards an endpoint in C++ native client

what I said in my previous e-mail > pertained to the C++ client 1.13 version and older. > > Alberto > ________ > From: Jacob Barrett > Sent: Wednesday, February 24, 2021 4:24 PM > To: dev@geode.apache.org > Subject: Re: Question about closing of a

Re: Question about closing of all connections towards an endpoint in C++ native client

The Java client does the same thing under certain conditions. Neither of the clients should do this though. I think this model is way too overaggressive. I think we should remove that logic entirely. If we think we want something that proactively checks the other connections to that server we

Re: Need Access to apachegeode/geode-native-build on docker hub

espond to releases, maybe "latest-CI" or "1.14.0-dev" or something? On 2/22/21, 12:12 PM, "Jacob Barrett" mailto:jabarr...@vmware.com>> wrote: Wherever we want to put it, if not dockerhub anymore, it must be accessible by Travis and LGTM or we also stop using

Re: Need Access to apachegeode/geode-native-build on docker hub

t make sense to use the same repo across the board, the images > for geode-native and geode-site can be useful beyond just CI. I know I use > the geode-native-build image to vet releases. > > Anthony > > >> On Feb 22, 2021, at 8:12 AM, Jacob Barrett wrot

Re: Need Access to apachegeode/geode-native-build on docker hub

This docker image has been there for years and is not related to a release but to the LGTM and Travis builds. I have access and can bump the image for you Mike. -Jake > On Feb 17, 2021, at 1:35 PM, Owen Nichols wrote: > > apachegeode images on dockerhub correspond to releases. To make a

Concourse Access

May I please have my Concourse access restored. GitHub: pivotal-jbarrett Thanks, Jake

Re: [DISCUSS] RFC - Add option to allow newer Geode clients to connect to older Geode servers

Having just spent some time yanking out some of the really really old version support I think a naive version knocking approach would work. During the client handshake the server will reject and close the connection of any client with a newer version number than it supports. The client could

Re: [Proposal] Geode Native Library Versioning

On Jan 29, 2021, at 3:47 PM, Dan Smith mailto:dasm...@vmware.com>> wrote: I do think at least implementing some automated checking for whatever compatibility we intend to provide is a good idea. I have a branch with a test using Abigail [1]. This branch depends on merging of a CI branch. It

Re: [Proposal] Geode Native Library Versioning

** sorry for the trashed formatting originally ** I would appreciate some feedback on this proposal by the end of day Friday, February 5th, 2021. TLDR; The proposal is to formalize what has been effectively the status quo for Geode Native release in the current source form and any future

[Proposal] Geode Native Library Versioning

I would appreciate some feedback on this proposal by the end of day Friday, February 5th, 2021. TLDR; The proposal is to formalize what has been effectively the status quo for Geode Native release in the current source form and any future binary form. The Problem Geode Native, specifically

Re: [Proposal] - Cleanup Protocol Version Checks

On Jan 20, 2021, at 10:36 AM, Owen Nichols mailto:onich...@vmware.com>> wrote: Sounds like good cleanup, but I'm not sure I understand why you propose breaking up the work and sneaking it in through mostly-unrelated PRs? My first thought would be do it in one shot, start by deleting the old

Re: [Proposal] - Cleanup Protocol Version Checks

supported by Geode. This value covers the last proprietary release prior to Geode’s open sourcing. https://issues.apache.org/jira/browse/GEODE-8837 On Dec 8, 2020, at 2:38 PM, Jacob Barrett mailto:jabarr...@vmware.com>> wrote: We all do lots of cleanup as we go through areas of the

Re: [DISCUSS] Geode 1.14

> On Jan 4, 2021, at 3:42 PM, Owen Nichols wrote: > > How to tell whether develop is stable? Same way we tell if a release branch is stable. Listen, cutting a release branch from the develop branch shouldn’t result in weeks worth of stabilization of the release branch. That is a smell that

Re: [DISCUSS] Geode 1.14

Keep develop stable, cut when we want to release. If develop isn’t stable we don’t cut until it is. There is no reason we can’t keep develop stable. If develop is stable then there is no reason we can’t release when we want to, whether that is a date or after a feature. -Jake > On Jan 4,

Re: State of https://github.com/apache/geode-dotnet-core-client

Wow, that’s pretty bad that we put proprietary references into this repo from the start. If you have the bandwidth a cleanup PR would be appreciated. I can’t speak to the functionality but I would hope there are unit and integration tests that assert the supported behavior. -Jake > On Dec 21,

Re: [Proposal] - Cleanup Protocol Version Checks

> On Dec 9, 2020, at 8:09 AM, Bruce Schuchardt wrote: > > We should also get rid of the old jump tables in CommandInitializer Would it make sense to do that in the same PR that tackles setting the min client version in the handshake or should that be a separate task? -Jake

[Proposal] - Cleanup Protocol Version Checks

We all do lots of cleanup as we go through areas of the source, like optimizing lambda expressions, renaming variables with more meaningful names and deleting commented out code, just to name a few. Littered throughout the network protocol sources are checks for older protocol versions. Lots of

Re: Requests taking too long if one member of the cluster fails

On the native side of things I would suggest trying the same test with a Java client and compare. It is very possible the C++ client is lacking in its ability to respond to failures as timely as the more heavily used Java client. -Jake On Nov 23, 2020, at 3:54 AM, Mario Salazar de Torres

Re: Committing broken javadocs to develop

I think we can make javadoc warnings an error in Gradle. I have fixed several modules to treat java warnings as errors already. Perhaps we can just extend that effort. > On Nov 20, 2020, at 10:39 AM, Kirk Lund wrote: > > Please remember to: > * fix all broken javadocs before submitting a PR >

Re: [PROPOSAL] Change the default value of conserve-sockets to false

I would argue that is doesn’t change the outward behavior of the product. It does change the internal workings of the product. It does improve the performance and reliability. As long as changes to the internals don’t have effect on the outward facing behavior of the product I see no problem

Re: apache-geode-1.13.0.tgz not found in LGTM analysis

One of my biggest beefs is that we have to hard code the current version all over the place. It's in the docker image used by native to run Travis jobs. It’s also in the benchmark job Gradle and shell scripts. Feels like there has got to be a better way. Ideally the develop branches of these

Re: [Discussion] RFC to make Geode's working directory configurable

Do we expect this to be used by production code or just test code? If this is going to be used by production code I am concerned with introducing another singleton class into the mix. We really want to be moving towards a non-singleton world where I can have more than one Cache in a JVM. For

Re: [Discussion] RFC to make Geode's working directory configurable

I look for that myself a while back and couldn’t find anything either. On Oct 6, 2020, at 4:10 PM, Dale Emery mailto:dem...@vmware.com>> wrote: Hi Dan, I spent more than a week scouring Gradle docs and code for any way to give the parallel forks their own working directories. I couldn't find

Re: Clean C++ client metadata in timeouts

+1 to what Anthony is asking. Rather the “fixing” the current behavior let’s just implement a behavior that better achieves the goal of single hop optimization. From what I recall for both the Java and C++ code is that we throw away all metadata on a region whenever there is any triggering

Re: Review needed for c++ client ticket

The PR needs tests. > On Jul 30, 2020, at 7:38 AM, Blake Bender wrote: > > Hi Alberto, > > I've reached out to Jake to approve his review, then I'll merge this for you. > Sorry for the delay. > > Thanks, > > Blake > > > On 7/23/20, 3:08 AM, "Alberto Bustamante Reyes" > wrote: > >

Re: Access to Geode GCP project

I have granted you access. > On Jul 27, 2020, at 12:10 PM, Dale Emery wrote: > > I would like to use the Geode GCP project. How can I get access to that? > > — > Dale Emery > dem...@vmware.com > >

Re: about Liberica JDK

> On Jul 8, 2020, at 10:25 AM, Robert Houghton wrote: > > Only partially tongue-in-cheek, but isn’t the promise of the JDK, that it is > the same everywhere, on all versions, builds, and platforms? No, only the JRE. -Jake

Re: API (Recommanded way) to get heap and disk usage for cluster nodes

Steve, Geode is in a transition from its on disk proprietary stats format to utilizing Micrometer.io. Some of what you are looking for may already be exposed via Micrometer. If so you can just use whatever registry of your choice to publish those stats. If the metric you

Re: Us vs Docker vs Gradle vs JUnit

> On Jul 1, 2020, at 12:16 PM, Udo Kohlmeyer wrote: > > To think a little more left field, with our continued investment in K8’s, > maybe we can look into that area? > Run tests in parallel using K8’s? It’s an interesting idea but even more complicated than the docker solution. Since k8s

Re: Us vs Docker vs Gradle vs JUnit

> On Jul 1, 2020, at 11:14 AM, Kirk Lund wrote: > > I'm not a big fan of forking the Docker plugin and making it a new Geode > submodule. This approach kind of flies in the face of the intentions of OSS > in general. For example, we want folks contributing to Apache Geode rather > than

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

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: Docker on Windows

Rebase complete and draft PR is open. I see the same null pointer issue Dale reported. Its a problem with the crufty Gradle Docker plugin we are using. It is the very reason we were thinking about making this move towards JUnit 5. Here is what I think for next steps. 1) Disable test

Re: Docker on Windows

On Jun 29, 2020, at 11:20 AM, Robert Houghton mailto:rhough...@vmware.com>> wrote: @Jacob Barrett<mailto:jabarr...@vmware.com> @Dale Emery<mailto:dem...@vmware.com> I am excited to see progress on this. What I do not know, is what Junit5 buys us in terms of test isolati

Re: Docker on Windows

the PR CI pipeline becoming unusable… I don’t have any notes about what “unusable” means. I suspect it was unrelated to my PR, but I’m not sure. Cheers, Dale On Jun 29, 2020, at 10:51 AM, Jacob Barrett mailto:jabarr...@vmware.com><mailto:jabarr...@vmware.com>> wrote: Dale

Re: Docker on Windows

ing Geode to use JUnit 5. I know he ran > into some issues but I don't recall what they were. I'm definitely up for > helping on the JUnit 5 front! > > On Fri, Jun 26, 2020 at 11:30 AM Jacob Barrett wrote: > >> If the effort to do both is less than the sum of each indi

Re: Fate of master branch

> On Jun 26, 2020, at 9:40 AM, Anthony Baker wrote: > > For geode-examples, there is more impact since master is the default branch > and anyone who has accessed these examples would be affected. I think it’s > still worth it to make the switch. I wonder if it makes sense put current

Re: Docker on Windows

he benefit we would get on windows, we also are > blocked on getting to the next major version of Gradle with the current tool. > I really think it might be easier to write our own Gradle plugin at this > point. > > >From: Jacob Barrett >Date: Thursday, June 25, 2020

Re: Fate of master branch

I am 100% in favor or dropping the master branch completely. I felt like it was always a source of confusion. Was it the most recent release or the latest version number. I know we have had issues with even correctly merging the latest version back into it sometimes. I really can’t see any

Docker on Windows

> On Jun 25, 2020, at 12:23 PM, Jens Deppe wrote: > It's been a couple of years since Sai and I tried (but failed) to dockerize > the tests. I'm sure docker support has improved and it might be worth trying > that again. Docker on windows has improved a lot but wasn’t the major issue the

Re: [PROPOSAL] Add windows jobs to PR checks

> On Jun 25, 2020, at 10:01 AM, Jinmei Liao wrote: > > +1, what was the reason for it not being included the PR before? The Windows integration and acceptance tests take a very long time to run because we can’t dockerize and parallelize them. They have also be very flaky in the past.

Re: Odg: Certificate Based Authorization

19, 2020, at 2:53 PM, Jacob Barrett mailto:jabarr...@vmware.com>> wrote: > ... Personally I would be inclined to leave RMI out of the solution initially. Second I would use this private variable to compete the support in OpenJDK.. If I correctly understood and we leave RMI o

Re: Odg: Certificate Based Authorization

I went on a little journey to see if it was possible and it looks promising. I was able to get access to the SSLSocket and thus the SSLContext. Proof of concept patch attached. > On Jun 19, 2020, at 2:53 PM, Jacob Barrett wrote: > > So I can see why this research paper was so bl

Re: Odg: Certificate Based Authorization

. Personally I would be inclined to leave RMI out of the solution initially. Second I would use this private variable to compete the support in OpenJDK. -Jake > On Jun 19, 2020, at 11:14 AM, Jacob Barrett wrote: > > > >> >> On Jun 18, 2020, at 4:24 AM, Jakov Varenin

Re: Odg: Certificate Based Authorization

On Jun 19, 2020, at 12:20 PM, Anthony Baker mailto:bak...@vmware.com>> wrote: That’s fine, I just want to understand what happens when I use this API: createdAuthenticatedView(…) Does it throw an exception? Silently work but not switch to the new user? I would expect that first off we

  1   2   3   4   5   6   7   >