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

Thank you for this Bill, I must admit that I'm starting to get a feeling of "scope creep" here.. I understand that all efforts to "modularize" membership would require some form of peripheral decoupling. BUT I'm starting to get concerned that we are hitting a rabbit hole scenario. Maybe thi

Re: Proposal to modify Servlet spec support for the HTTP Session Management Module for AppServers

I think that we should really be looking at going to 4.0. It would be compatible with 3.1, but given that 4.0 is standard with Java 8 (which already EOL), we should try and get onto the latest. I don't think that us aligning ourselves with a tech release in 2013 is something we should do. -

Re: [DISCUSS] is overriding a PR check ever justified?

@Naba.. wrong thread :) We have real scenario here now, where we have no consensus on whether we are allowed or not allowed to override.. Do we vote now? OR do we apply common sense? TBH, at this junction we should really just do whatever we believe is correct. A committer is appointed due t

Re: [VOTE] Fix bad-merge of GEODE-7488

No brainer vote for me. +1 @Donal, overrides should only EVER be for "break glass emergency". Anybody who would abuse it for any other reason, should seriously be considered "enemy-of-the-state". --Udo On 11/22/19 11:55 AM, Robert Houghton wrote: I was overzealous in a merge to Geode, and g

Re: [DISCUSS] is overriding a PR check ever justified?

dentify areas that we might be able to improve with additional coverage or checks. On Fri, Nov 22, 2019 at 12:40 PM Udo Kohlmeyer wrote: @Naba.. wrong thread :) We have real scenario here now, where we have no consensus on whether we are allowed or not allowed to override.. Do we vote now? OR

Re: [DISCUSS/VOTE] Proposal to bring GEODE-7465 to release/1.11.0

This is no-brainer *+1* On 11/26/19 11:27 AM, Owen Nichols wrote: I would like to propose bringing “GEODE-7465: Set eventProcessor to null in serial AEQ when it is stopped” into the 1.11 release (necessitating an RC4). Without the fix, a sequence of ordinary gfsh commands will leave the WAN

Re: Certificate Based Authorization

+1 On 12/2/19 1:29 AM, Mario Kevo wrote: Hi, There is another potential functionality we would like to discuss and get some comments for. The idea is TLS certificate based authorization. Currently, if a user wants secure communication (TLS) + authorization, he needs to enable TLS and acces

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

@Dan, I will add my -1 to this. I understand your argument of "let's solve the problem by removing  the offender". But in reality who is the offender? Is it the one class that is using an "internal" api OR is it the implementation itself that is to tightly coupled that extending it is impos

Re: New geode-gfsh module

I imagine once the Management v2 API's are GA (and feature complete), I don't see a reason why /gfsh/ should not be a stand alone module. It would definitely have to be updated to use the new v2 API's, which should not have any direct dependency on geode-core any more. On 12/6/19 10:01 AM, Jac

Re: [DISCUSS] Adding a couple user APIs dealing with RegionFactory.

I think at this point I'd be looking at the new V2 Management API's for Regions. I think any new "public" effort that we'd be adding to the product should be done through the Management API's for Regions, rather than exposing new public API's that in reality should not be made "public". --Ud

Re: [REQUEST] Squash merge please

I'm not sure what this discussion is about... WE, as a community, have agreed in common practices, in two place no less... 1) Quoting our PR template For all changes: * Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? * Has your PR bee

Re: [REQUEST] Squash merge please

d to enable this feature.. As I don't agree with making the process even more restrictive... BUT, in reality... If our own members cannot be bothered to follow the rules we have all agreed upon, then the system has to protect itself. --Udo On 12/16/19 10:34 AM, Udo Kohlmeyer wrote: I

Re: [DISCUSS] Adding a couple user APIs dealing with RegionFactory.

tructor for RegionFactory is necessary. And thus a createRegionFactory Hence my changes. Thanks, Mark On Dec 11, 2019, at 4:41 PM, Udo Kohlmeyer wrote: I think at this point I'd be looking at the new V2 Management API's for Regions. I think any new "public" effort th

Re: [VOTE] Release candidate for Apache Geode version 1.11.0.RC3.

I'm working on this right now.. Will submit a PR for GEODE-7531 and GEODE-7159 (it is the similar change than 7531) shortly. --Udo On 12/16/19 2:45 PM, Owen Nichols wrote: Dan/John, please submit a PR against develop with the minimum change needed for GEODE-7531 so we can vote on backporting

[VOTE] Inclusion of GEODE-7531 into 1.11

Hi there Apache Devs. I can we please vote on the inclusion of GEODE-7531. This issue is to fix an bug which assumes that all `Pool` objects are of type `PoolImpl` and immediately casts Pool -> PoolImpl. In the case of testing with Mocks, the type casts fail, because the Pool-mocks are not o

[VOTE] Inclusion of GEODE-7159 into 1.11

Hi there Apache Devs. I can we please vote on the inclusion of GEODE-7159. This issue is to fix an bug which assumes that all `Pool` objects are of type `PoolImpl` and immediately casts Pool -> PoolImpl. This issue is related to GEODE-7531, and is specific to the emergencyClose method. In th

Inclusion of GEODE-7531 and GEODE-7159 into 1.11

Hi there Release manager for the 1.11 release. Please could you include GEODE-7531, SHA: f5b59350cc1b4580154df047f409a6c7a4095f0b and GEODE-7159, SHA: 0f05e9ccd94c04a205ace82de6616e9bffa92fa7 into 1.11. Regards Udo

Re: Proposal to including GEODE-7593 in release/1.11.0

+1 On 12/19/19 10:05 AM, Owen Nichols wrote: GEODE-7593 fixes a memory leak where indexes could retain references to pdx values when eviction should have released that memory. This is not a new issue, but is critical because system stability is threatened when eviction does not release memory

Re: privacy protection

Hi there Mario, The idea of encryption-at-rest, is something that has been on my radar for at least 4yrs now. I would not mind having a chat about what your requirements are and how we can get this into Geode. Looking forward to chatting to you about this. --Udo On 1/15/20 2:20 AM, Mario

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

+1 - for inclusion On 2/5/20 4:22 AM, Ju@N wrote: Hello devs, I'd like to include the fix for GEODE-7728 [1] in release 1.12.0. The change is basically to avoid throwing an exception and return the correct result whenever a query has more than one condition and one of them compares two indexed

[Vote] Include GEODE-7752 into 1.12

Hi there Geode dev, I would like to request that GEODE-7752 (7028f601680fee3f57cbdff63951128d7180ca13) gets included into 1.12. This piece of code is a refactor of work done in GEODE-7715. This refactor specializes Builders and simplifies Builder behavior for better user experience. --Udo

Re: [Vote] Include GEODE-7752 into 1.12

ander Murmann wrote: Udo, you say "refactor", but this sounds more like a feature or user facing improvement. Do you mind elaborating a little more why this should be in this release? On Wed, Feb 5, 2020 at 1:54 PM Patrick Johnson wrote: +1 On 2/5/20, 1:53 PM, "Udo Kohlmeyer&quo

Re: [Vote] Include GEODE-7752 into 1.12

Do you mind elaborating a little more why this should be in this release? On Wed, Feb 5, 2020 at 1:54 PM Patrick Johnson +1 On 2/5/20, 1:53 PM, "Udo Kohlmeyer" wrote: Hi there Geode dev, I would like to request that GEODE-7752 (7028f601680fee3f57cbdff63951128d7180ca13)

Re: [Vote] Include GEODE-7752 into 1.12

Hi there EB, fix has been merged to develop. (Everything is green now) 9c102e4f8836ca32ad51a05bbd4d0107e8fc0343 Thanks --Udo 0On 2/5/20 4:34 PM, Ernest Burghardt wrote: Fair enough Udo, just let us know when you have it ready. Thanks, EB On Wed, Feb 5, 2020 at 4:31 PM Udo Kohlmeyer wrote

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

+1 On 2/7/20 8:36 AM, Jinmei Liao wrote: Hi devs, I would like to include the fix for GEODE-7717[1] in release 1.12.0. The change modifies the json response structure of all of the "list" operations in cluster management rest service. Including it in this release, where most users are just star

Re: please include the fix for geode-7750 and geode-7760 in 1.12

+1 On 2/7/20 8:57 AM, Bruce Schuchardt wrote: af8307 fixes a number of problems with auto-reconnect that have been reported recently.  Owen and Darrel did a lot of work in analyzing failures and this revision addresses the problems they encountered, plus a couple of others exposed by stress-t

[DISCUSSION] Bumping dependency versions for 1.12

Hi there, I wonder if this might be a little late in the game, but would we consider bumping some of the dependency versions for 1.12? Off the top of my head, Spring from 5.2.1 to 5.2.3 --Udo

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

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: [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: [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: 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: 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: 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

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: [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

[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: [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

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: 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: 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: 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: 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

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: 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: 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: 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

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

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

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: 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: [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: 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: 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: [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: 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: 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]: 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: [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] 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] 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]: 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 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

[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] 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

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: [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: [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: [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: [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: 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

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

[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

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

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: 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: 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: 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: 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

ClassLoaderService RFC Proposal

Hi there Apache Geode Devs, Please find

[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

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

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

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

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

[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: [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,

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

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

;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

[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: 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

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: [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

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

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: 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/

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

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: [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,

<    1   2   3   4   5   6   >