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

Hi there Dave, I can understand the frustration that you face. I think the freezing of the code is different to that of the docs. I think each project member would agree if I stated that changes to the docs on ANY branch should be allowed regardless of where in the process of the release the pr

Re: [Proposal] Make "Affects Version" field mandatory for new tickets with "Bug" issue type in JIRA

oint about the Description field being necessary. Do you think that this field should also be mandatory for all issue types? Personally, I think there's a fairly strong argument to be made that a ticket should always have a description, so I'd be in favour of that change too. __

Re: [Proposal] Make "Affects Version" field mandatory for new tickets with "Bug" issue type in JIRA

I think it is reasonable to “reject” bug reports that don’t include simple things like “version” and “description”. I agree, a bug report with the initially effected version filled in should be marked as incomplete and the same should be said about the description field. If there is not enough i

Re: Commit message review opt-in

I’ll opt-in please. --Udo From: Owen Nichols Date: Saturday, February 26, 2022 at 10:44 AM To: geode Subject: Commit message review opt-in If you received an automated-looking PR review comment from onichols-pivotal in the past few weeks without consent, I apologize and have withdrawn it. If

Re: [Suspected Spam] [VOTE] Apache Geode 1.14.3.RC1

+1 – Ran basic acceptance tests. From: Dave Barnes Date: Tuesday, January 25, 2022 at 6:12 AM To: dev@geode.apache.org Subject: Re: [Suspected Spam] [VOTE] Apache Geode 1.14.3.RC1 +1 docs binary distribution contains API docs with correct version header source distribution provides working scrip

Re: Proposal: Cutting 1.15 Release branch Tuesday, 25 January

+1 on cutting a release on 25 Jan 2022… I implore all community members, that if you have a feature that has not met the 25 Jan 2022 deadline, to not try and add it post the deadline. This will help in the final stabilization phase of the release. --Udo From: Raymond Ingles Date: Friday, Janu

Re: [DISCUSS] batch patch release voting

Unknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ISRlc%2BXuR%2F9kNGbWoejBjx5stGD0wfAuoxDmaMj1tx4%3D&reserved=0> On December 2, 2021 at 3:25:03 PM PST, Udo Kohlmeyer wrote: I wonder if voting on patch versions makes sense. As we should never be breaking any existing features and essential

Re: [DISCUSS] batch patch release voting

I wonder if voting on patch versions makes sense. As we should never be breaking any existing features and essentially there should be sufficient testing on the fixes to confirm that they resolve the issues. There should also be no changes to APIs, as those changes should be included in a new mi

Re: Geode-9621: Spotless overstepping its boundary of formatter

specify multiple versions at once, and that tests would be out-of-sync with each other, and with the production code. So I would strongly vote against that. -Robert From: Udo Kohlmeyer Date: Monday, October 11, 2021 at 5:32 PM To: dev@geode.apache.org Subject: Re: Geode-9621: Spotless

Re: Geode-9621: Spotless overstepping its boundary of formatter

against that. -Robert From: Udo Kohlmeyer Date: Monday, October 11, 2021 at 5:32 PM To: dev@geode.apache.org Subject: Re: Geode-9621: Spotless overstepping its boundary of formatter Hi there Robert, Yes, you did work with me, but the solution to add my custom versions of jars that I want to test

Re: Geode-9621: Spotless overstepping its boundary of formatter

Hi there Robert, Yes, you did work with me, but the solution to add my custom versions of jars that I want to test with, into the `DependencyConstraints` file just feels like the wrong approach. The prior art you refer to, is a specific version of tomcat we want each module to use. It is no di

Geode-9621: Spotless overstepping its boundary of formatter

Hi there Geode Devs, Recently GEODE-9621 was introduced onto the develop branch. This new feature introduces a new bug where `spotlessApply` will remove all version dependencies out of gradle. I assume this is to combat the risin

Re: Region is not created on one of the servers

Hi Mario, I think your assessment of the problem is correct. Thinking about it, there is no simple (correct) way to easily solve this. Given that there are too many variables in play, users making configurational changes, whilst servers are coming up. Now, that said, I think we should address

Re: [DISCUSS] Upgrading to Lucene 7.1.0

Might I propose something here. There is currently a significant amount of work going into completing Geode-8705, which is the Classloader isolation. We are currently targeting to getting this release in Geode 1.16. My proposal is, that we use the capability that Patrick demo’d at the Community

[DISCUSS] - Creation of new Apache Geode Github repo for Gradle Plugin

Hi there Apache Dev. As part of Geode-8705, there has been some work done on creating a gradle plugin that will generate module.xml files that are consumed by JBoss Modules, based on the gradle build files. This plugin is intended to be not only used by the Geode project but also for customers

Re: Access to the CI pipelines using fly

Thank you From: Robert Houghton Date: Friday, July 2, 2021 at 7:03 AM To: dev@geode.apache.org Subject: Re: Access to the CI pipelines using fly Sure thing, Udo. I have updated the concourse instance with your github name. -Robert From: Udo Kohlmeyer Date: Thursday, July 1, 2021 at 1:44 PM

Access to the CI pipelines using fly

Hi there Apache Geode Infra, Would it be possible to please grant me access to fly access of a CI pipeline. I’m trying to root-cause a problem which I see happen only in the CI-pipeline. --Udo

Re: Cleaning up the codebase - use curly braces everywhere

+1, I trust the work that you’ve done @Donal. I think splitting this out by package or any other metric we could come up with, it an exercise in futility. So let’s get this merged in, set up a spotless rule to make sure we don’t introduce more and move on… --Udo From: Donal Evans Date: Frida

Re: Rescued Geode Protobuf

Thank you Michael, I’ll definitely be looking into this in the future… --Udo From: Michael Oleske Date: Thursday, May 6, 2021 at 9:22 AM To: dev@geode.apache.org Subject: Rescued Geode Protobuf Hi Geode Friends! Since I didn't see any movement on rescuing Geode Protobuf into another reposito

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

provements? --Udo On 4/15/21, 1:19 PM, "Jacob Barrett" wrote: > 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 mak

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

"+1" to ENCOURAGING developers to make "final" a requirement for method arguments. "-1" to making it a hard rule. If we want to enforce this rule on the basis of readability or performance, I fear that we might be beating the wrong horse here for the wrong reasons!! Short reasoning: If we rea

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

ware.com%7C7a18231640654f0546fc08d8f4651dc0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637528062421752074%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BO8%2BENOPc05J%2BlA4Wu4O9kIyVetnK4xihMfEMaQ%2FbBs%3D&reserved=0>

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

eserve their own dedicated discussion. I understand some of them are harder to remove from a technical perspective or neither experimental nor deprecated and would thus require a Geode 2.0. ________ From: Udo Kohlmeyer Sent: Tuesday, March 23, 2021 14:54 To: dev@geo

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

-1 Given that I was on the team that started this initiative, I will naturally have an inclination to say 'No'. I don't know if I would go as far as removing this project/initiative out of Geode. I understand that the way that was used to hook into Geode was less the perfect, and I fully supp

Re: errors from logging code in unit tests

What test(s) are you running? Version? --Udo On 2/25/21, 8:39 AM, "Ernie Burghardt" wrote: Its not just you Bruce, I get this... 2021-02-24 13:38:10,891 main ERROR Error processing element GeodeConsole ([Appenders: null]): CLASS_NOT_FOUND 2021-02-24 13:38:10,898 main ERROR Error p

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

@Anthony I cannot think of a single reason, why the server should not start up, even in a rolling upgrade. This setting should not have an effect on the cluster (other than potentially positive). Also, if the Geode were to enforce this setting across the cluster, then we have seriously broken ou

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

Hi there Donal, Thank you for raising this. It is not an uncommon request to change the default value of this field. This has been discussed many times in the past. I would LOVE to approve this change, but this would mean that users that don’t set this property might suddenly have this propert

Re: [PROPOSAL] Backport GEODE-8536 and GEODE-8686 to 1.13.1

+1 to backport. From: Alexander Murmann Date: Wednesday, November 11, 2020 at 10:52 AM To: dev@geode.apache.org Subject: Re: [PROPOSAL] Backport GEODE-8536 and GEODE-8686 to 1.13.1 +1 Thanks for fixing those, Donal! From: Donal Evans Sent: Tuesday, November 10,

Re: PR process and etiquette

put in a PR and > then add reviewers when you're ready for comments. Getting the stink-eye > for putting up a non-Draft PR is just going to make it more difficult to > attract and retain new contributors. > > On 10/27/20, 5:41 PM, "Udo Kohlmeyer" wrote: > >

Re: PR process and etiquette

thing I would like to see more of is PR summaries that explain *why* the change is being made, not just *what* is being changed. Thanks Udo for looking for ways to make the community process work even better! On 10/27/20, 5:41 PM, "Udo Kohlmeyer" wrote: Dear Apache Geode Devs

Re: PR process and etiquette

t; for review, and a squash or force-push "loses" those comments. One thing I would like to see more of is PR summaries that explain *why* the change is being made, not just *what* is being changed. Thanks Udo for looking for ways to make the community process work even better! On 10/

PR process and etiquette

Dear Apache Geode Devs, It is really great going through all the PRs that been submitted. As Josh Long is known to say: "I work for PRs". Whilst going through some of the PRs I do see that there are many PRs that have multiple commits against the PR. I know that the PR submission framework kicks

Re: [DISCUSS] ServiceRegistry RFC

require some kind of lifecycle management? If any of them require an instance of a Cache (and perhaps other components) they will need to be aware of the cache restarting (happens during reconnect). Is that going to be a problem? --Jens On 10/20/20, 1:12 PM, "Udo Kohlmeyer" wrot

Re: [DISCUSS] ServiceRegistry RFC

doing with the traditional service loading mechanism today? i.e. how we're loading everything that extends CacheService (for example HttpService, LuceneService, GeodeRedisService, etc.). Thanks --jens On 10/15/20, 7:25 PM, "Udo Kohlmeyer" wrote: Hi there Apache Geode Devs. P

Re: [DISCUSS] ServiceRegistry RFC

. how we're loading everything that extends CacheService (for example HttpService, LuceneService, GeodeRedisService, etc.). Thanks --jens On 10/15/20, 7:25 PM, "Udo Kohlmeyer" wrote: Hi there Apache Geode Devs. Please find attached an RFC for the introduction of a

Re: Geode Kafka Connector Verification and availability on Confluent Hub

Nice work everyone!! Good effort and even better result! --Udo From: Nabarun Nag Date: Friday, October 16, 2020 at 6:07 AM To: dev@geode.apache.org , u...@geode.apache.org Subject: Geode Kafka Connector Verification and availability on Confluent Hub Hello everyone, I would like to inform

[DISCUSS] ServiceRegistry RFC

Hi there Apache Geode Devs. Please find attached an RFC for the introduction of a ServiceRegistry into Apache Geode. https://cwiki.apache.org/confluence/display/GEODE/ServiceRegistry Please add all comments to the RFC to this email for tracking and discussion. --Udo

Re: [DISCUSS] Supported filename convention for Deploy Jars functionality

;no transition ability". @Udo, the work you are citing in conjunction with this appears to be related to classloader changes. Can you clarify whether your proposed restrictions on jar names are essential to implement your classloader changes, or just an unrelated thing you happened to notic

Re: [DISCUSS] Supported filename convention for Deploy Jars functionality

filenames. I believe we are probably concerned that user's jar name might contain "_" or "-" themselves, like common-logging.jar etc. So we had to resort to finding the first "." followed by a digit to determine where the version pattern begins. >

Re: [DISCUSS] Supported filename convention for Deploy Jars functionality

contain "_" or "-" themselves, like common-logging.jar etc. So we had to resort to finding the first "." followed by a digit to determine where the version pattern begins. > >On 10/7/20, 1:44 PM, "Udo Kohlmeyer" wrote: > >

Re: [DISCUSS] Supported filename convention for Deploy Jars functionality

uot;_" or "-" themselves, like common-logging.jar etc. So we had to resort to finding the first "." followed by a digit to determine where the version pattern begins. On 10/7/20, 1:44 PM, "Udo Kohlmeyer" wrote: Hi there Geode Dev List,

[DISCUSS] Supported filename convention for Deploy Jars functionality

Hi there Geode Dev List, Whilst doing work on GEODE-8466 and looking at the functionality that the ClassPathLoader.java, JarD

Re: [Discussion] - ClassLoaderService RFC proposal

ClassPathLoader mechanism then? How will one access the service; is there some static reference? Some code examples would be helpful to properly understand how one might work with this. --Jens On 9/14/20, 3:42 AM, "Udo Kohlmeyer" wrote: Hi there Apache Geode Devs, (try 2) Please find

Re: [Discussion] - ClassLoaderService RFC proposal

service; is there some static reference? Some code examples would be helpful to properly understand how one might work with this. --Jens On 9/14/20, 3:42 AM, "Udo Kohlmeyer" wrote: Hi there Apache Geode Devs, (try 2) Please find attached a proposal for a ClassLoaderService. Please

Re: [Discussion] - ClassLoaderService RFC proposal

, -Alberto G. From: Udo Kohlmeyer Sent: Monday, September 14, 2020 12:42 PM To: geode Subject: [Discussion] - ClassLoaderService RFC proposal Hi there Apache Geode Devs, (try 2) Please find attached a proposal for a ClassLoaderService. Please review and ponder

Re: [Discussion] - ClassLoaderService RFC proposal

easy it is to convert something into a persistent service vs creating it as one in the first place. If it's trivial, then no worries. ____ From: Udo Kohlmeyer Sent: Monday, September 14, 2020 3:42 AM To: geode Subject: [Discussion] - ClassLoaderService RFC proposal

[Discussion] - ClassLoaderService RFC proposal

Hi there Apache Geode Devs, (try 2) Please find attached a proposal for a ClassLoaderService. Please review and ponder on it. https://cwiki.apache.org/confluence/display/GEODE/Introduction+of+ClassLoaderService+into+Geode All comments are please to be made in this mail thread. —Udo

ClassLoaderService RFC Proposal

Hi there Apache Geode Devs, Please find

Re: Question on how Geode handles data on Disk

Hi there Amit, (Attempt 2), So, create a Region, you configure if the Region is to persist the data to disk or not. There is no selective algorithm that would select which data is written to disk and which is not. If it is configured to be persistent or eviction overflowed, it will be written

Re: Question on how Geode handles data on Disk

Hi there Amit, On Sep 7, 2020, 4:25 AM +1000, Amit Pandey , wrote: What I meant here "Also if I request data for ID 1 will it bring it only from disk or " was that if I request a tuple which is not in memory and is in disk, 1) How does Geode know its in DISK 2) Does it bring only that tuple (value

Re: Draft of August 2020 Geode report to the board

&reserved=0> ________ From: Udo Kohlmeyer Sent: Sunday, August 9, 2020 7:18:08 PM To: dev@geode.apache.org Subject: Re: Draft of August 2020 Geode report to the board Hi there Karen, Any chance that you could pls change the URL to the proper Medium URLs and not the wrapped URLs? —

Re: Draft of August 2020 Geode report to the board

Hi there Karen, Any chance that you could pls change the URL to the proper Medium URLs and not the wrapped URLs? —Udo On Aug 7, 2020, 5:04 PM -0700, Karen Miller , wrote: Thanks, Anthony. Here is Draft 2 of the August board report. Corrections and comments by Monday at noon please. ## Descripti

Re: [Proposal] - RFC etiquette

omes from lack of time because we're busy with other things and not so much with how the RFC proposal has been written. Anyhow, having an example of what this new section should look like would be helpful for new RFCs to be written. Alberto ________ From: Udo Kohlm

Re: [Proposal] - RFC etiquette

could end up being put to the trouble of writing a comprehensive RFC only to have barely any actual feedback. ________ From: Udo Kohlmeyer Sent: Thursday, July 9, 2020 1:18 PM To: geode Subject: [Proposal] - RFC etiquette Hi there Geode Dev's I would like to propose th

[Proposal] - RFC etiquette

Hi there Geode Dev's I would like to propose the following changes to the RFC process that we have in place at the moment. 1. All submitted RFC’s will provide a minimum 2 week review period. This is to allow the community to review the RFC in a reasonable timeframe. If we rush things, we wi

PR submission and Commit message etiquet.

Hey there Geode-Devs, It has come to my attention that there have been a few commits that have creeped into the `develop` branch that don’t follow a standard that we have set. I would like to make every committer and contributor aware of the following code of conduct we have all agreed to: htt

Re: Us vs Docker vs Gradle vs JUnit

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? But I am also supportive of fixing the tests that we can run them in parallel without the extra container scaffolding. —Udo On Jul 1, 2020, 11:38 AM -070

Re: [PROPOSAL] Add windows jobs to PR checks

In principal, +1 for adding them. But if it is gating or not, is determined by how much extra time we now have to add to waiting for a PR build to complete. Is there any way that we could improve the time testing time of these? —Udo On Jun 25, 2020, 11:05 AM -0700, Bruce Schuchardt , wrote: If

Re: [PROPOSAL]: BackPort GEODE-8029 to support/1.12 and support/1.13

+1 On Jun 10, 2020, 3:18 AM -0700, Ju@N , wrote: Hello devs, I'd like to propose bringing GEODE-8029 [1] to the *support/1.12* and *support/1.13* branches. The fix has been merged into develop through commit bc0090dc93643fd4d09c79a4b0c29d883172b546 [2], and it's basically to make sure we delete un

RE: [DISCUSS] RFC: New option for serial gw sender dispatcher threads start

the deadline until end of next Thursday (4th June), I hope its fine. BR/ Alberto B. De: Udo Kohlmeyer Enviado: viernes, 29 de mayo de 2020 19:30 Para: dev@geode.apache.org Asunto: RE: [DISCUSS] RFC: New option for serial gw sender dispatcher threads start Hi

RE: [DISCUSS] RFC: New option for serial gw sender dispatcher threads start

Hi there Alberto, Thank you for the RFC. Tbh, I don’t know if there should some guidance around the period that we invite comments on. I personally had a really busy week and could not get to the RFC review in the 1 week that I was given. I would like to request that this RFC is extended by 1

Re: [PROPOASAL] backport GEODE-8144

+1 On May 27, 2020, 1:35 PM -0700, 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 been merged. The PRs fixe endpoint verification problems in servers and

Re: [PROPOSAL] backport GEODE-8174 to 1.13 and 1.12

, 4:04 PM, "Eric Shu" wrote: +1 ____ From: Udo Kohlmeyer Sent: Tuesday, May 26, 2020 2:12 PM To: geode Subject: [PROPOSAL] backport GEODE-8174 to 1.13 and 1.12 Hi there Geode Dev, I would like to request a back port of a critical issue in the JCAConnect

[PROPOSAL] backport GEODE-8174 to 1.13 and 1.12

Hi there Geode Dev, I would like to request a back port of a critical issue in the JCAConnectionManager. This issue manifests itself as a ConcurrentModificationException when trying to close a connection. SHA: bef07b34131abddb8c0f04e0ab6a48f1daac991d —Udo

Re: Proposal to backport GEODE-8167

+1 On May 21, 2020, 8:51 AM -0700, Owen Nichols , wrote: Some automated scans have flagged Geode Pulse as potentially containing “high" security vulnerability CVE-2020-5407. Analysis shows that this saml vulnerability is not applicable to Geode Pulse. It is low risk to bump the spring-security d

Re: [PROPOSAL]: GEODE-8150 into support/1.13

+1.. On May 21, 2020, 8:12 AM -0700, Ju@N , wrote: Hello devs, I'd like to propose bringing *GEODE-8150 [1] *to the *support/1.13* branch. The ticket is basically to revert the upgrade of the *classgraph* [2] library, we found some performance issues that are not addressed even when using the late

Re: [PROPOSAL] bring GEODE-8131 PR to support branches

+1 On May 19, 2020, 8:53 AM -0700, Bruce Schuchardt , wrote: While investigating a distributed hang we discovered that the alerting system was blocking the logging of critical information that would have helped diagnose the issue. This PR modifies the logging of this information to first log i

Re: [PROPOSAL] Move definition of Region separator character to geode-common

n May 18, 2020, 12:25 PM -0700, Jacob Barrett , wrote: On May 18, 2020, at 10:15 AM, Udo Kohlmeyer wrote: I was wondering. Why do we require to add this Region.SEPERATOR to be anywhere outside of Region. Geode-management was purposefully designed NOT to have a dependency on core. Creating

Re: [PROPOSAL] Move definition of Region separator character to geode-common

I was wondering. Why do we require to add this Region.SEPERATOR to be anywhere outside of Region. Geode-management was purposefully designed NOT to have a dependency on core. Creating a new dependency on a donor module, just means that management module will now start knowing about geode. I su

Re: [PROPOSAL]: GEODE-7940 to support/1.12

Agreed… this definitely meets the inclusion requirements. +1 On Apr 17, 2020, 1:50 AM -0700, Owen Nichols , wrote: Hi Juan, this looks like a great fix and definitely meets the “critical fix" standard. Also thanks for the detailed description. I noticed it was just merged to develop very recentl

Re: Data ingestion with predefined buckets

Hi there Steve, Firstly, you are correct, the pattern you are describing is not recommended and possibly not even correctly supported. I've seen many implementations of Geode systems and none of them ever needed to do what you are intending to do. Seems like you are will to go through A LOT of

Re: Proposal to bring GEODE-7941 to support/1.12

+1 to backport On 4/6/20, 9:14 AM, "Anthony Baker" wrote: +1 to backport > On Apr 6, 2020, at 8:54 AM, Owen Nichols wrote: > > Recently some Geode users have expressed concern that shiro-1.4.1.jar is getting flagged for critical security vulnerability CVE-2020-1957.

Re: [VOTE] Apache Geode 1.12.0.RC1

Amazing catch Owen! I'll consider your "-1" as binding and echo it! Can we recut RC1 and address these issues? --Udo On 3/25/20 8:26 PM, Owen Nichols wrote: My vote is non-binding, but I’m a -1 for this RC1. Reasons: i) The geode-examples release branch appears to have been branched from ma

Re: RFC - Gateway sender to deliver transaction events atomically to receivers

o was proposing? Again I am not exactly sure if this was intended to be a vote but I would +1 the attempt and continuation of the discussion/proposal and probably -0 the current proposal as there are some ideas/things to iron out. On Wed, Mar 25, 2020 at 3:49 PM Udo Kohlmeyer wrote: Hi there Al

Re: RFC - Gateway sender to deliver transaction events atomically to receivers

Hi there Alberto, It's a "-1" from me. I have raised my concerns in the RFC comments. To summarize, whilst I like the idea (I had never thought of that problem you are trying to solve), I don't know how this will behave at scale. Just looking at some of the comments, I think it is safe to say

Re: [VOTE] Using Github issues and wiki for geode-kafka-connector project

+1 On 3/21/20 5:16 PM, Nabarun Nag wrote: Hello team, We are planning to experiment with using Github issues and wiki for the Apache project *Geode-Kafka-Connector. *(not Apache Geode project). Please do give your vote on this as we need to send the vote link to infra to activate it. *Why are

Re: Discussion on Deprecation

I think we are also missing the other side of the coin. Once we deprecate something and we now need a equivalent test that tests the same behavior using the new method/approach. i.e now we have to double up on the testing of said deprecated method/feature/class. First we have to keep the tests

Re: RFC - Client side configuration for a SNI proxy

Hi there Jake, Another twist to the story, but with a working (if unpolished ;) ) prototype. It covers all bases of: * Type safety * Extensibility * Simple API design * API clarity It takes the best of all approaches. I like it!! +1 to this implementation. -1 to Bill's approach. @Bil

Re: RFC - Client side configuration for a SNI proxy

eneric type signature on the enclosing type, for example: interface PoolFactory { P getProxy(); } -j On Tue, Mar 10, 2020 at 10:38 AM Udo Kohlmeyer wrote: I disagree. I think /setProxy(ProxyConfiguration)/ is 1st prize. If we are concerned that users will not know WHAT options

Re: RFC - Client side configuration for a SNI proxy

I disagree. I think /setProxy(ProxyConfiguration)/ is 1st prize. If we are concerned that users will not know WHAT options are available.. We could always have a static builder for our supported options. --Udo On 3/10/20 10:07 AM, Dan Smith wrote: Ok, how about this? setProxy(SniProxyConf

Re: RFC - Client side configuration for a SNI proxy

@Bill and I were just talking about exact thing. If one adds 1 level of abstraction to this, one might get something that is maybe a little more extendible. That said, we are not expecting to support 100's of different proxy types.. possible only 2. But I do lean towards @JohnB's suggestion..

Re: RFC - Client side configuration for a SNI proxy

Hi there Bill, Whilst I commend your enthusiasm. Giving the community a weekend to review an RFC is less than optimal. Please extend you deadline until 13 March 2020. Which is more reasonable. --Udo On 3/6/20 11:04 AM, Bill Burcham wrote: Please review the RFC for *Client side configuration

Re: Let's Deprecate the SECURITY_UDP_DHALGO Configuration Property

hat approach actually improved the security of data in motion. And I don’t believe it saw much if any use in practice. Anthony On Mar 2, 2020, at 10:27 AM, Udo Kohlmeyer wrote: I think that if TCP connections are secured and UDP connections are not, then we've regressed in our security. Is

Re: Let's Deprecate the SECURITY_UDP_DHALGO Configuration Property

l P2P traffic will be encrypted. If we don't want to support P2P encryption, it seems like we should deprecate both? -Dan On Fri, Feb 28, 2020 at 1:40 PM Udo Kohlmeyer wrote: Yes, the proposal was deprecation notice in 1.12 and remove in 1.13.. That does not leave users much time to react

Re: PR Titles

I thought PR titles are generated from the git comment. So, I'm expecting it to have the following format: "GEODE-XXX: " Glancing at the current PR list, I do see that there is at least 1 PR that does not follow that guideline. We also don't want to be overly prescriptive, so maybe if

Re: Let's Deprecate the SECURITY_UDP_DHALGO Configuration Property

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 Burghardt wrote: +1 seems reasonable to do this for 1.12 and be

Re: Let's Deprecate the SECURITY_UDP_DHALGO Configuration Property

+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

Re: Discussions about concerns over User API changes

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

Re: [PROPOSAL]: Include GEODE-7820 in Release 1.12.0

+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

Re: [DISCUSSION] - ClassLoader Isolation

in functions that they deploy on a server-cache. On 2/26/20, 10:10 AM, "Udo Kohlmeyer" wrote: Hi there Geode Dev's. There is a new RFC proposal on ClassLoader Isolation. The review end date is 13 Feb 2020. https://cwiki.apache.org/confluenc

[DISCUSSION] - ClassLoader Isolation

Hi there Geode Dev's. There is a new RFC proposal on ClassLoader Isolation. The review end date is 13 Feb 2020. https://cwiki.apache.org/confluence/display/GEODE/ClassLoader+Isolation Please review and discuss in this

Re: [DISCUSS] RFC: Shipping Geode patch releases

From the proposal it seems we are departing from the initial delivery paradigm of "always upgrade to the latest version, because all fixes are going in there", to the more product orientated approach of, there is a support lifespan for each {major}-{minor} version. Which is a more traditional p

Re: Redis PubSubTest started failing

x27;t even have windows unit tests for PRs. Walk before we run... On Wed, Feb 19, 2020, 09:00 Owen Nichols wrote: Perhaps also worth considering: can we get WindowsStressNew added to the PR checks? On Wed, Feb 19, 2020 at 8:50 AM Udo Kohlmeyer wrote: Is this something that can be fixed

Re: Redis PubSubTest started failing

@Owen.. off topic.. but i think it is worth the discussion On 2/19/20 9:00 AM, Owen Nichols wrote: Perhaps also worth considering: can we get WindowsStressNew added to the PR checks? On Wed, Feb 19, 2020 at 8:50 AM Udo Kohlmeyer wrote: Is this something that can be fixed in a short time

Re: Redis PubSubTest started failing

Is this something that can be fixed in a short time (2hrs)? If not, can be revert and get back to a clean pipeline? --Udo On 2/19/20 8:23 AM, Jens Deppe wrote: Thanks Kirk, We're working on fixing this. --Jens On Tue, Feb 18, 2020 at 3:23 PM Kirk Lund wrote: I just started seeing the Red

Re: Creation of buckets for partitioned region

Hi there Mario, I can confirm the first observation. Buckets are created lazily. Upon data create, buckets are created as required. --Udo On 2/14/20 12:16 AM, Mario Ivanac wrote: Hi geode dev, we have observed following behavior, at creation of partitioned regions. After partitioned region

Re: [PROPOSAL]: Include GEODE-7756 in Release 1.12.0

+1 On 2/13/20 3:37 AM, Ju@N wrote: Hello devs, I'd like to include the fix for GEODE-7756 [1] in release 1.12.0. The change prevents a performance degradation introduced in Geode 1.11 through to the OQL Method Invocation authorization feature, for which regular cache operations are slowed down

Re: [PROPOSAL]: Include GEODE-7789 in Release 1.12.0

+1 On 2/13/20 6:49 AM, Jinmei Liao wrote: +1 On Thu, Feb 13, 2020, 6:47 AM Owen Nichols wrote: +1 On Thu, Feb 13, 2020 at 3:05 AM Nabarun Nag wrote: +1 On Thu, Feb 13, 2020 at 2:09 AM Ju@N wrote: Hello devs, I'd like to include the fix for GEODE-7789 [1] in release 1.12.0. The chang

Re: Include GEODE-7776 in release 1.12

+1 On 2/11/20 11:23 AM, Dick Cavender wrote: This regression was introduced when the geode-gfsh subproject was recently added. While not obvious this created a critical build / runtime cycle between geode-core and geode-gfsh that causes some tools/IDEs, that don't cope well with circular depende

Re: [DISCUSSION] Bumping dependency versions for 1.12

fix in Spring 5.2.3 that is critical to bring? On Tue, Feb 11, 2020 at 9:14 AM Patrick Johnson wrote: +1 On 2/11/20, 8:42 AM, "Udo Kohlmeyer" wrote: Hi there, I wonder if this might be a little late in the game, but would we consider bumping some of the dependency ve

  1   2   3   4   5   6   >