Re: Utilizing GitHub .CODEOWNERS files

Hi Robert, Seems like a reasonable experiment. You can tag me if you like. Thanks, -Dan From: Robert Houghton Sent: Friday, October 30, 2020 1:52 PM To: dev@geode.apache.org Subject: Utilizing GitHub .CODEOWNERS files Thanks to @udo and @nabarunnag the conversa

Re: [DISCUSS] ServiceRegistry RFC

ace the static method/code block usages of ClassPathLoader with instance references to ClassLoaderService. --Udo From: Dan Smith Date: Wednesday, October 21, 2020 at 5:14 AM To: dev@geode.apache.org Subject: Re: [DISCUSS] ServiceRegistry RFC It might be better to hang thi

Re: [DISCUSS] ServiceRegistry RFC

It might be better to hang things off InternalCache rather than create a new singleton. The cache is already a singleton, but we've been working on removing that by plumbing the cache everywhere. The cache is effectively our context object, and once we've finished removing calls to Cache.getInst

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

I also don't see a pressing need for a breaking change here. It's unlikely the current behavior is going to cause any problems for users with "standard" jar file names. On the other hand, having failures or new, weird classpath issues on upgrade for users with non-standard jar names doesn't seem

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

+1 Looks good to me. If this is just for tests, I suspect there is some gradle way to make parallel forks use different working directories. But having this option in the product doesn't seem like a bad idea. -Dan From: Dale Emery Sent: Tuesday, October 6, 2020

Re: [DISCUSS] One more 1.13 change

Thanks all, I merged the change. -Dan From: Raymond Ingles Sent: Tuesday, September 29, 2020 7:56 AM To: dev@geode.apache.org Subject: Re: [DISCUSS] One more 1.13 change +1 On 9/28/20, 3:21 PM, "Dan Smith" wrote: Hi, I'd like t

[DISCUSS] One more 1.13 change

Hi, I'd like to backport this change to support/1.13 as well GEODE-8522: Switching exception log back to debug - https://github.com/apache/geode/pull/5566 This cleans up some noise in our logs that customers might see. [https://avatars3.githubusercontent.com/u/47359?s=400&v=4]

Re: [PROPOSAL] Backport usability improvements to support 1.13 branch

+1 - I had a question on the PR itself about how we're merging these. -Dan From: Joris Melchior Sent: Thursday, September 24, 2020 8:13 AM To: dev@geode.apache.org Subject: Re: [PROPOSAL] Backport usability improvements to support 1.13 branch +1 On 2020-09-23,

Re: Request contributor permissions on ASF Jira

Hi Mario, I added you, you should have access now. Thanks, -Dan On Sep 19, 2020 5:40 AM, Mario Salazar de Torres wrote: Hi, To whom it might concern, I would like to start contributing to the Geode solution and I created a Jira explaining the feature/fix. Thing is I could not change the Jira i

Re: Proper location for debugging tools

The main geode repo has a dev-tools directory, that’s a good spot for scripts. If it’s specific to native client I’d put it in geode-native but if not the geode repo seems fine. -Dan > On Sep 11, 2020, at 1:41 PM, Blake Bender wrote: > > Hi all, > > I have a Python script I’ve used quite a b

Re: JIRA issues for geode native developers

It looks like they weren’t listed as committers in JIRA. I added them, you should be able to assign them issues now! -Dan > On Aug 21, 2020, at 11:00 AM, Blake Bender wrote: > > Hello, > > In the course of attempting to be a better Geode citizen yesterday, I > attempted to assign a JIRA issu

Re: [PROPOSAL] Backport GEODE-8423 to support/1.13

+1 -Dan On Aug 12, 2020, at 8:59 AM, Sarah Abbey mailto:sab...@vmware.com>> wrote: get

Re: Request wiki access

Done. You should have access now. From: Patrick Johnson Sent: Monday, August 3, 2020 1:37 PM To: dev@geode.apache.org Subject: Request wiki access Hi, Can someone grant me write access to the Apache Geode wiki? My user name is jpatrick, same as my email address

Re: Switching default branch in .net core repo

+1 -Dan On Thu, Apr 23, 2020, 8:05 AM Anthony Baker wrote: > Please do, this will match our default approach to development > (gitflow-ish). > > +1 > > Anthony > > > > On Apr 23, 2020, at 7:35 AM, Blake Bender wrote: > > > > Good morning, > > > > We created a repo yesterday for the .net core c

Re: About Geode rolling downgrade

> Anyhow, we wonder what would be as of today the recommended or official way to downgrade a Geode system without downtime and data loss? I think the without downtime option is difficult right now. The most bullet proof way to downgrade without data loss is probably just to export/import the data,

Re: Reconfiguring our notifications and more

+1 -Dan On Tue, Apr 21, 2020 at 9:00 AM Owen Nichols wrote: > +1 > > > On Apr 21, 2020, at 8:54 AM, Anthony Baker wrote: > > > > I’d like a quick round of feedback so we can stop the dev@ spamming [1]. > > > > ASF has implemented a cool way to give projects control of lots of > things [2]. In

Re: Concurrent tests hitting OOME, hangs, etc

I like the idea of a separate concurrency test suite. We have other tests of concurrency that aren't using this runner that could also go there - maybe we could establish some good conventions and figure out how to give more CPU time to these tests. I'd actually like to see *more* tests of concurre

Re: [Discuss] Cache.close synchronous is not synchronous, but code still expects it to be....

IMO if it's not currently synchronous, that's just a bug that needs to be fixed. If folks can provide details on what actually was asynchronous or the particular test failures they saw, that would be helpful. Previously, when this came up it looks like Kirk found that close would not wait for a di

Re: [Discuss] Cache.close synchronous is not synchronous, but code still expects it to be....

Can you spell out what parts of Cache.close are asynchronous? As far as I can tell it shuts down threadpools, etc. synchronously. -Dan On Tue, Apr 14, 2020 at 3:09 PM Mark Hanson wrote: > Hi Jake, > > For Option 6: We could fix isClosed as well. That is a great suggestion. > Currently, it retur

Re: Data ingestion with predefined buckets

uckets made fix .. thoughts? > > > -Steave M. > > > On Sat, Apr 11, 2020, 1:54 AM Dan Smith wrote: > > > Hi Steve, > > > > The bucket that data goes into is generally determined by the key. So for > > example if your data in File-0 is all for custo

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

+1 -Dan On Fri, Apr 10, 2020 at 12:37 PM Anilkumar Gingade wrote: > +1 > Based on: The risk is low. Avoids false positives in automated > vulnerability scans. > > On Fri, Apr 10, 2020 at 12:33 PM Dick Cavender > wrote: > > > +1 > > > > On Fri, Apr 10, 2020 at 11:16 AM Owen Nichols > wrote: >

Re: Data ingestion with predefined buckets

Hi Steve, The bucket that data goes into is generally determined by the key. So for example if your data in File-0 is all for customer X, you can include Customer X in your region key and implement a PartitionResolver that extracts the customer from your region key and returns it. Geode will then

Re: In progress RFC's?

Replace singleton PoolManager with ClientCache scoped service has been moved to the icebox. -Dan On Thu, Apr 2, 2020 at 9:08 AM Anthony Baker wrote: > I was reviewing the list of RFC’s stil under discussion and noticed that > the following may need to be moved to a different status: > > Classlo

Re: [DISCUSS] Replacing singleton PoolManager

to get away from needing singletons in the future, but for now I've moved this to the icebox. -Dan On Mon, Dec 9, 2019 at 5:20 PM Dan Smith wrote: > On Fri, Dec 6, 2019 at 10:45 AM Dale Emery wrote: > >> >> > Dale - are you suggesting a ConnectionPoolService that

Re: [DISCUSS] Replace UDP messaging for membership with TCP

entation based on TLS > > > On Apr 1, 2020, at 3:20 PM, Dan Smith wrote: > > > >> When we move from a reliable UDP implementation to one based on TCP, we > >> need to think about how to provide reliability on top of TCP. If you > dig > >> into TCP, you’

Re: Error while executing dynamic Lucene query

Great, glad to hear it! -Dan On Tue, Apr 7, 2020 at 10:01 AM vas aj wrote: > Hi Dan, > > Thanks for the reply. > I moved the Lucene query logic to Geode Function and now the query is > working as expected. > > Regards, > Aj > > On Tue, Apr 7, 2020 at 12:52 AM Dan

Re: Error while executing dynamic Lucene query

Your custom query code does need to be on the server in order for this to work. Specifically, this lambda is your LuceneQueryProvider, which needs to be serializable in some way (Serializable, DataSerializable, etc.) and the code need to be on the server: index -> {

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

+1 -Dan On Mon, Apr 6, 2020 at 10:30 AM Bruce Schuchardt wrote: > +1 to backport to support/1.12 > > On 4/6/20, 8:55 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: WAN replication issue in cloud native environments

r is restarted, as both will be considered > down. > > So I think it would be better to use ip+port+id, it will have less impacts. > > BR/ > > Alberto B. > ____ > De: Dan Smith > Enviado: viernes, 27 de marzo de 2020 19:14 > Para: dev@geode.

Re: [DISCUSS] Replace UDP messaging for membership with TCP

> When we move from a reliable UDP implementation to one based on TCP, we > need to think about how to provide reliability on top of TCP. If you dig > into TCP, you’ll find that it tries really hard (sometimes up to 15 > minutes!!) but doesn’t guarantee message delivery. Does this matter in > pra

Re: RFC: Add C Bindings to Geode Native Client

Once we do have agreement on what new repositories we want, I think any pmc member should be able to create them on gitbox.apache.org. Deleting them if we decide we don't want them is harder :) -Dan On Tue, Mar 31, 2020, 12:26 PM Blake Bender wrote: > Just want to make sure I understand what yo

[DISCUSS] Replace UDP messaging for membership with TCP

Hi all, We created a RFC for replacing our UDP messaging in Geode with a TCP based solution. This will address the issues we have supporting our current udp encryption solution, along with helping us move away from jgroups, which currently can't be upgraded. Please review and comment by 4/7/2020

Re: [DISCUSS] Redundancy Gfsh Commands

Looks good. I put a few comments inline (look for the yellow highlights). -Dan On Mon, Mar 30, 2020 at 2:21 PM Kirk Lund wrote: > [I added this as a comment on the wiki page] > > You might want to consider making RestoreRedundancyOperation actually > extend CompletableFuture. The interface is a

Re: [VOTE] Apache Geode 1.12.0.RC4

+1 Ran my release check https://github.com/upthewaterspout/geode-release-check -Dan On Fri, Mar 27, 2020 at 1:33 PM John Blum wrote: > SDG continues to build with the Apache Geode 1.12.0 RC4 bits. > > https://jenkins.spring.io/job/spring-data-geode/job/master-next/16/ > https://github.com/spri

Re: WAN replication issue in cloud native environments

With this PR, it would be possible to identify servers running with the > same ip and port, because now they will be identified by member id. But > Bruce realized that it could be a problem if two servers are running in the > same JVM, as they will share the same member id. It seems its very unlike

Re: WAN replication issue in cloud native environments

Bruce Schuchardt wrote: > +1 > > I think this could move to the "In Development" state > > > > From: Alberto Bustamante Reyes > Date: Wednesday, March 25, 2020 at 4:13 PM > To: Bruce Schuchardt , Dan Smith < > dsm...@pivotal.io>, "dev@geode.a

Re: [VOTE] Apache Geode 1.12.0.RC1

geode-assembly-1.12.0.zip does not appear to have any signature files associated with it. It also looks like it just contains a Dockerfile - is this actually an artifact we want to distribute? -Dan On Wed, Mar 25, 2020 at 2:12 PM Ernest Burghardt wrote: > Hello Geode Dev Community, > > This is

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

> btw what are we voting on? Just curious as I wasn't sure if we were voting for the current proposal or whether we should continue this discussion? Sorry, just +1'd because I like the idea, not to imply we're voting on anything. I thought that's a general apache convention during a discussion.

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

+1 I think this a good improvement to the way transactions behave with WAN! I had a couple of more detailed comments I put on the doc. Thanks, -Dan On Wed, Mar 25, 2020 at 8:05 AM Alberto Gomez wrote: > Hi, > > Could you please review the RFC for "Gateway sender to deliver transaction > events

Re: Request for Apache Geode Wiki Edit Permission

Hi Barry, You should have access now. -Dan On Wed, Mar 25, 2020 at 11:23 AM Barry Oglesby wrote: > This is a request for permission to edit the Apache Geode Wiki using my > Apache credentials: > > Username: boglesby > Email: bogle...@apache.org > > Thanks, > Barry Oglesby >

Re: RFC: Add C Bindings to Geode Native Client

+1 Great idea! Hey, it's also easy to call into C libraries from Java - maybe we can write a java client ;) It would be nice to see a little bit more detail about the actual API, like what does a region put look like? -Dan On Wed, Mar 25, 2020 at 8:25 AM Robert Houghton wrote: > +1 > YES. > >

Re: Need edit/add permissions on the Geode wiki

Hi Blake, You should have access now. Thanks! -Dan On Tue, Mar 24, 2020 at 1:38 PM Blake Bender wrote: > Hello, > > I am attempting to add an RFC to the wiki, and don't appear to have any > kind of write access. Can someone help me out? > > Thanks, > > Blake >

Re: Request adding to the Geode project in JIRA

Hi Ray, You should have access now. Thanks, -Dan On Mon, Mar 23, 2020 at 12:42 PM Raymond Ingles wrote: > While I can log in (as 'ringles') to the Geode JIRA, I don't seem to be > able to assign/be assigned JIRA tickets. Can I be added to whatever group > allows that? Thanks! >

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

+1 -Dan On Sat, Mar 21, 2020, 9:48 PM Udo Kohlmeyer wrote: > +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

Re: [DISCUSS] Client side configuration for a SNI proxy

Mar 19, 2020 at 7:27 AM Joris Melchior > wrote: > > > +1 > > > > On Mon, Mar 16, 2020 at 6:33 PM Dan Smith wrote: > > > > > Hi all, > > > > > > A new RFC is up for this feature > > > > > > > > > https://cwiki.ap

Re: [DISCUSS] Client side configuration for a SNI proxy

, 2020 at 3:33 PM Dan Smith wrote: > Hi all, > > A new RFC is up for this feature > https://cwiki.apache.org/confluence/display/GEODE/Client+side+configuration+for+a+SNI+proxy. > > > Please review and comment by this Friday, 3/20/2020. > > This hopefully addresses so

Re: [PROPOSAL] Include fix for GEODE-7763 into release 1.12.0

+1 On Wed, Mar 18, 2020 at 11:41 AM Jason Huynh wrote: > Hello Dev list, > > I'd like to include a fix for GEODE-7763 in release 1.12.0. > The change removes the call to exportValue, preventing a serialization, > when no clients are waiting for the specific event. > The reason why I think it sho

Re: [PROPOSAL] eliminate file count loophole in PR StressNewTest

in a non-deterministic process > > On Tue, Mar 10, 2020 at 8:58 PM Dan Smith wrote: > > > I checked, and 1% of our last 500 commits touched more than 30 tests. Of > > those 1%, over half touched more than 100 tests. So I'd guess somewhere > > around .5% of prs will fal

[DISCUSS] Client side configuration for a SNI proxy

Hi all, A new RFC is up for this feature https://cwiki.apache.org/confluence/display/GEODE/Client+side+configuration+for+a+SNI+proxy. Please review and comment by this Friday, 3/20/2020. This hopefully addresses some of the concerns with the previous RFC for this feature. The new proposal is fo

Re: Discussion on Deprecation

+1 One point though - we do need to leave some tests that specifically test the deprecated method(s), since we still support the deprecated APIs until we remove them. Everything else should be converted. -Dan On Sun, Mar 15, 2020 at 6:41 PM Jacob Barrett wrote: > Hey Team, > > When deprecating

Re: RFC - Client side configuration for a SNI proxy

As Bill pointed out, I'm looking into whether we can make an API where a user could plug in their own proxy implementation, somewhat along the lines of what Jake suggested. Just to be clear - Jake's code is more of a demonstration of some concepts than a working prototype. The API we actually need

Re: RFC - Client side configuration for a SNI proxy

hould depend on the > >> geode-proxy module that has logic to service discover ProxyFactory. > Given a > >> ProxyConfiguration instance it should be able to > load/discover/interrogate > >> for the correct ProxyFactory. The socket factory asks the ProxyFactory > for

Re: [PROPOSAL] eliminate file count loophole in PR StressNewTest

>>> assuming > >>> any changes to the test may have introduced the flaky-ness. > >>> It's about paying the cost upfront or later when the test is > determined to > >>> be flaky. > >>> If 25+ tests have been changed in a PR, the

Re: RFC - Client side configuration for a SNI proxy

host, int port) But I could live with a ProxyConfiguration interface that just provides those three fields, Option B setProxy(ProxyConfiguration) interface ProxyConfiguration { ProxyType type; String host; int port; } On Tue, Mar 10, 2020 at 11:19 AM Dan Smith wrote: > The other reaso

Re: RFC - Client side configuration for a SNI proxy

xy(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: &

Re: [PROPOSAL] eliminate file count loophole in PR StressNewTest

On Tue, Mar 10, 2020 at 10:51 AM Robert Houghton wrote: > @dsmith > The file change for determining the merge base was due to changing the > Concourse resource. The file encodes the merge-base SHA, regardless of > depth of the git checkout. > > Makes sense. But maybe the file is inaccurate? Seems

Re: RFC - Client side configuration for a SNI proxy

Ok, how about this? setProxy(SniProxyConfiguration config) interface SniProxyConfiguration extends ProxyConfiguration { static SniProxyConfiguration create(String host, int port); String getHost(); int getPort() } The main difference here from John's proposal being that setProxy takes a

Re: RFC - Client side configuration for a SNI proxy

> What is your thinking about using the enum vs specific named API’s (e.g. setPoolProxyWithSNI). I think the nice thing about the enum is over separate methods is that it's strongly typed, but it might still allow us to support additional proxy types in the future with less modifications for code

Re: WAN replication issue in cloud native environments

in the > sender configuration, right? > -- > *De:* Dan Smith > *Enviado:* jueves, 5 de marzo de 2020 4:41 > *Para:* Alberto Bustamante Reyes > *Cc:* dev@geode.apache.org ; Bruce Schuchardt < > bschucha...@pivotal.io>; Jacob Barrett ; Anilkumar > Ginga

Re: WAN replication issue in cloud native environments

ery 5 seconds due to > "java.io.EOFException: The connection has been reset while reading the > header". But I dont know yet what is causing it. > > -- > *De:* Dan Smith > *Enviado:* martes, 3 de marzo de 2020 18:07 > *Para:* dev@geode.apache.org

Re: [PROPOSAL] eliminate file count loophole in PR StressNewTest

e of PR’s are currently subject to the 25 test file rule? > How many would be subject to the concourse timeout? > > > > I’d like to understand the scope of the impact for this change. > > > > Anthony > > > > > >> On Mar 1, 2020, at 8:58 AM, Owen Nich

Re: [DISCUSS] RFC: Shipping Geode patch releases

thing but unnecessary complexity to require a second > round of sifting. > > support/1.12 will have to be cut from release/1.12.0 as a one-time special > case, but the end result should be indistinguishable. > > > On Mar 2, 2020, at 4:24 PM, Dan Smith wrote: > > > > +

Re: WAN replication issue in cloud native environments

> We are currently working on other issue related to this change: gw senders pings are not reaching the gw receivers, so ClientHealthMonitor closes the connections. I saw that the ping tasks are created by ServerLocation, so I have tried to solve the issue by changing it to be done by Endpoint. Thi

Re: Let's Deprecate the SECURITY_UDP_DHALGO Configuration Property

> > @Dan, are you thinking that secured intra-cluster communication needs to > be deprecated as a whole? > > Exactly. We shouldn't be left with "partially secure" intra-cluster communication, where some stuff goes over TLS and some is plain text. Setting ssl-enabled-components=cluster without setti

Re: [DISCUSS] RFC: Shipping Geode patch releases

+1 to the proposal as written. The proposal does talk about support branches, but doesn't describe when they are created. Is the idea that we create a support/1.X branch as soon as we release geode 1.X, and then create release branches off of that as needed? -Dan

Re: Let's Deprecate the SECURITY_UDP_DHALGO Configuration Property

Should we deprecate cluster ssl as well? Cluster ssl without udp encryption means that not all 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 dep

Re: [PROPOSAL] eliminate file count loophole in PR StressNewTest

Won't this make it impossible to merge refactoring changes that touch a lot of tests? -Dan On Sat, Feb 29, 2020, 12:37 PM Robert Houghton wrote: > Yes, as it should > > On Sat, Feb 29, 2020, 12:25 Dan Smith wrote: > > > Doesn't the build fail when concourse times out? > >

Re: [PROPOSAL] eliminate file count loophole in PR StressNewTest

Doesn't the build fail when concourse times out? -Dan On Fri, Feb 28, 2020, 1:37 PM Donal Evans wrote: > +1 > > If the original reason for the 25 file limit was to prevent StressNewTest > taking too long, then the concourse timeout renders the restriction > redundant. Also, I'd think that if an

Re: Odg: ParallelGatewaySenderQueue implementation

Hi Mario, That bug number is from an old version of GemFire before it was open sourced as geode. Looking at some of the old bug info, it looks like the bug had to do with the fact that calling stop on the region was causing there to be unexpected RegionDestroyedException's to be thrown when the q

Old geode-benchmark PRs

Hi, I noticed we have some old outstanding PRs for the geode-benchmarks project. Are any of these things we want to merge or should we close them out? https://github.com/apache/geode-benchmarks/pulls -Dan

Re: Request for Confluence edit permissions

Hi Dave, Done! You should have access now. Thanks, -Dan On Tue, Jan 21, 2020 at 12:08 PM Dave Barnes wrote: > This is a request for permission to edit the Apache Geode Wiki on > Confluence using my Apache credentials: > Username: dbarnes > Email: dbar...@apache.com > I've been using anothe

Re: privacy protection

Hi Mario, It's something we've talked about before, I think it would be a good idea. The two workarounds I have seen done are - full disk encryption - storing the geode disk files on an encrypted disk - encrypting values - At the client side, converting values into encrypted bytes before storing

Re: [DISCUSS] stop releasing both .tar.gz AND .zip for geode-examples

+1 to removing the .zip for geode-examples. -Dan On Fri, Jan 17, 2020 at 12:11 PM Owen Nichols wrote: > Geode dropped .zip starting with 1.8.0, so it is likely an oversight that > Geode-examples still makes .zip artifacts too. > > It was requested[1] recently that we fix this. > > The proposed

Re: [DISCUSS] include geode-benchmarks in 1.12 release

we’d be happy to help others in the > community with on the dev list — but not something we would expect > questions about on the user list. > > > On Jan 16, 2020, at 10:23 AM, Dan Smith wrote: > > > > We are supposed to be including all of the source necessary to test G

Re: [DISCUSS] include geode-benchmarks in 1.12 release

run on a laptop” > be > > enough to let other interested contributors help get geode-benchmarks to > a > > “better state”? > > >>> > > >>>> On Jan 14, 2020, at 9:38 PM, Jacob Barrett > > wrote: > > >>>> > >

Re: [DISCUSS] include geode-benchmarks in 1.12 release

On Tue, Jan 14, 2020 at 4:11 PM Owen Nichols wrote: > I believe the desire is to include the source code for geode-benchmarks as > part of the official geode release, much like how we include geode-examples. > Oh! I thought you meant running the benchmarks in the release pipeline - I think last

Re: [DISCUSS] include geode-benchmarks in 1.12 release

Looks like the benchmarks have passed for around 30 builds in a row. +1 to including them if they don't fail for spurious reasons between now and cutting the release. BTW - Do we have stats on the variance we see in the benchmark numbers? Are we getting close to failing occasionally? What is the c

Re: enable-time-statistics

I personally wouldn't be too worried about enabling time based statistics in production. I think we segregated the time statistics because they do have to call System.nanoTime to measure the elapsed time. At one point in the history with old JDKs they called System.currentTimeMillis, which was real

Re: RFC - Logging to Standard Out

+1. Looks good! -Dan On Wed, Jan 8, 2020 at 12:56 PM Blake Bender wrote: > +1 - this is also a todo item for the native client, I think. NC has a bug > in logging which is in my top 3 for "most irritating," as well, which is > that logging actually starts *before* the logging system is initial

Re: Requesting Wiki access

You should have access now. Thanks, -Dan On Mon, Jan 6, 2020 at 11:58 AM Donal Evans wrote: > Hi, > > Would it be possible to be given access to edit the Geode wiki please? My > username is donalevans. > > Thanks! >

Re: Wiki access

Done! You should have access now. Thanks, -Dan On Thu, Jan 2, 2020 at 3:56 AM Mario Ivanac wrote: > Hi All, > > Happy New Year! > > Can I have access to edit the Geode Wiki? > My username is "mivanac". > > Thanks, > Mario >

Re: [DISCUSS] Proposal to require linear commit history on develop

gt;>> ./gradlew devBuild > > >>> ...spotlessJava FAILED > > >>> We implemented branch protections to make this impossible, right? > > >>> > > >>> We can very easily close this loophole by disabling all but the > > >>> >

Re: [DISCUSS] What should we do with @Ignore tests?

Some of these test have been ignored for a long time. However, looking at the history, I see we have ignored some tests as recently as in the last month, for what seem like some questionable reasons. I'm concerned that this could be a two step process to losing test coverage - someone who things t

Re: [DISCUSS] abandon branch protection rules

Regarding the StressTest job - how about we switch that have a new JVM for each test? That's how DistributedTest and IntegrationTest normally run. We let StressTest reuse the JVMs because it would be faster and find problems related to static state left behind, but I think in practice people are fi

Re: [VOTE] Apache Geode 1.11.0.RC4

27, 2019 at 1:44 PM Dan Smith wrote: > On Fri, Dec 27, 2019 at 1:28 PM Owen Nichols wrote: > >> It looks like the Benchmark < >> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-11-0-main/jobs/Benchmark/builds/11> >> job in the release pipe

Re: [VOTE] Apache Geode 1.11.0.RC4

On Fri, Dec 27, 2019 at 1:28 PM Owen Nichols wrote: > It looks like the Benchmark < > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-11-0-main/jobs/Benchmark/builds/11> > job in the release pipeline has failed for the last 4 runs. At various > times it has flagged Pa

Re: [VOTE] Apache Geode 1.11.0.RC4

On Tue, Dec 24, 2019 at 10:12 AM Ernest Burghardt wrote: > I also ran integrationTests locally (/gradlew integrationTest) on Mac and > saw these failures > It looks like these tests are expect InetAddress.getLocalHost to return a non-loopback address. Some of them failed for me on my (linux) lap

Re: [VOTE] Apache Geode 1.11.0.RC4

+1 Looks good to me - I ran geode-release-check on it - poked around in the java code. -Dan On Fri, Dec 20, 2019 at 2:49 PM Mark Hanson wrote: > Given it is the holidays, perhaps more time is in order. I am bumping the > voting deadline to Friday, December 27th, 2019. > > Thanks, > Mark > > >

Re: [DISCUSS] Proposal to require linear commit history on develop

>>>> just prevents people from accidentally pressing a button that we > >>> have > >>>>>>>>> already agreed should never be pressed, but because we never > >>>> configured > >>>>>>> our > >>>

Re: [DISCUSS] Proposal to require linear commit history on develop

-1 to (1) and (2). I think merge commits are appropriate in certain circumstances, so I don't think we should make a blanket restriction. In fact I think our release process involves some merges. I think setting standards on what is reasonable to be an individual commit will do a lot more to clea

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

+1 to adding a way to copy the RegionAttributes. BTW, I really wish this RegionFactory was an interface. I don't know if adding a copy constructor makes it harder to migrate to an interface later, but maybe just having this single public method might be better? + RegionFactory createRegionFacto

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

I see a lot of PR comments on those PRs. What is the new API you added? -Dan On Wed, Dec 11, 2019 at 2:57 PM Mark Hanson wrote: > Hi All, > > There was a suggestion that since I am making a couple user visible API > changes that I might want to ask the dev list. > > Basically I was migrating co

Re: [DISCUSS] Replacing singleton PoolManager

On Fri, Dec 6, 2019 at 10:45 AM Dale Emery wrote: > > > Dale - are you suggesting a ConnectionPoolService that returns > ConnectionPool instances? > > Yes. > > > Would that mean ConnectionPool would extend Pool and we would deprecate > Pool itself? > > Maybe extend. I worry about extending, for t

Re: [DISCUSS] Replacing singleton PoolManager

Pool instances? Would that mean ConnectionPool would extend Pool and we would deprecate Pool itself? -Dan On Fri, Dec 6, 2019 at 8:32 AM Darrel Schneider wrote: > +1 > > On Thu, Dec 5, 2019 at 4:40 PM Dan Smith wrote: > > > Hi, > > > > I wrote up a proposal for deprecating

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

I had a side conversation with John. I created a proposal in a separate and a JIRA (GEODE-7555) for what I think is a good long term solution to the issues STDG had mocking the Geode API. In the short term, I'm fine with whatever we decide we should do to support STDG. -Dan On Thu, Dec 5, 2019 a

[DISCUSS] Replacing singleton PoolManager

Hi, I wrote up a proposal for deprecating of the singleton PoolManager in favor of a ClientCache scoped service. Please review and comment on the below proposal. I think this should address the issues that Spring Data Geode and friends had trying to mock Pools and remove the need for those projec

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

gt; > >> > > >> On Wed, Dec 4, 2019, 17:59 Udo Kohlmeyer wrote: > > >> > > >>> @Dan, > > >>> > > >>> I will add my -1 to this. > > >>> > > >>> I understand your argument of "let's solve the

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

> > Quite frankly the reasons STDG (or dependent projects downstream like SDG, > SBDG, SSDG) are doing what it is (they are) doing is irrelevant to point > articulated in the description of GEODE-753. > What bothers me here is not your suggestions in GEODE-1753, but the fact that you are vetoing a

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

On Wed, Dec 4, 2019 at 2:11 PM John Blum wrote: > This is not a test failure in SDG. SDG builds fine with Apache Geode 1.11 > (and all tests pass), as I indicated above in my origin +0 vote. > > This is a definitive problem for SBDG when using STDG to mock Apache Geode > resources/objects, which

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

On Wed, Dec 4, 2019 at 11:16 AM John Blum wrote: > I am changing my vote to -1! > > I have filed GEODE-7531 > [1], > which is a serious blocking issue for all things *Spring* for Apache > Geode. This issue alone is currently preventing me from u

<    1   2   3   4   5   6   7   8   9   10   >