Re: Default branch for geode-examples

Make the default “develop” to be consistent with the rest of our repositories. Put a statement in the README.md that these examples for the 1.9.0-SNAPSHOT (develop). When cutting a release and merging to master change the say they are for 1.9.0 (rel/v1.9.0). > On Dec 12, 2018, at 9:07 AM, Anth

Re: 'io.spring.dependency-management' not found.

I have IJ 2018.3.2 and don’t have this issue with the plugin resolution when compiling Geode. > On Dec 19, 2018, at 10:54 AM, Kirk Lund wrote: > > My other IJ project is now broken after letting IJ update. Anyone know > anything about geode-dependency-management.gradle or why it would cause: >

Re: Geode 1.8.0 maven repository is missing sources and javadoc jars

If the only thing that is missing is that we didn’t publish jars then we just need to publish the jars. We don’t need to change the build to do it and rebuild. Manually post the artifacts and correct the gradle for 1.9. > On Dec 21, 2018, at 1:07 PM, Owen Nichols wrote: > > Maybe I misundersta

Re: Geode Version in the logs

Given that the version can’t change at runtime it doesn’t make sense to repeatedly print static state of the system. The log does print the static state of the system at startup. > On Jan 3, 2019, at 8:17 AM, Peter Tran wrote: > > Hello, > > Is it possible to prepend every log message with th

Re: Extremely long IntelliJ Gradle refresh times

I had a similar issue about 3 months ago where Gradle would just crawl. I tried many things with no luck. Eventually I just deleted all the Gradle ‘build’ directories and the Gradle cache and problem went away. -Jake > On Jan 9, 2019, at 6:23 AM, Nabarun Nag wrote: > > I have not experience

Re: Defining public SPIs in Geode

Yes it really is that simple. There are several examples of doing this in Goode. Look at the Extensions SPI. It could easily be pulled out into a geode-spi project for a separate artifact. It uses a ServiceLoader in the XML config to resolve namespaces to an extension parser that can then crea

Re: [Proposal] Adding Micrometer to Apache Geode

I am good with this proposal as long as it includes the deprecation of all the current stats APIs and VSD such that Micrometer is the only go forward stats definition and collection API in 2.0. > On Jan 15, 2019, at 9:37 AM, Mark Hanson wrote: > > Hello All, > > I would like to propose that w

Re: Should Geode stats conform to backwards compatibility constraints?

I don’t consider the stats API a public API. I think it is a leaked internal API. Do we document the interactions with this API? Do we document the stat names? I consider documentation the API. I can discover all sorts of exposed methods in a library but shouldn’t consider them contracted API.

Re: Should Geode stats conform to backwards compatibility constraints?

How about mod MAX_INT? It would wrap back to 0 and make it more consistent with at least SNMP counters that roll over to 0 when maxed. A monitoring and graphing system can account for this by recognizing the current value is less than the previous and typically uses the previous and current valu

Re: Bug Numbers and Trac Numbers in comments

Comments that don’t provide meaningful context beyond what is already expressed in the code should be removed. A number to a system that the general public can’t access is not meaningful. Delete or replace with meaningful comment. -jake > On Feb 19, 2019, at 1:41 PM, Michael Oleske wrote: >

Release Managers

Release manager need to add the next version number to JIRA when they branch the release. Changes going into develop need to be marked finished with a version but may not be merged to the current release branch. Also, after release isn’t the release branch supposed to be deleted? So what gives

Re: Release Managers

> On Feb 20, 2019, at 8:58 AM, Bruce Schuchardt wrote: > > I would _really_ like to keep the release branches for historical purposes. > It's very useful to be able to look back and see what was/wasn't in a release > when someone has a problem. If we delete the branches we need some other

Merging GEODE-6424 into release/1.9.0

Anyone have issue with merging https://issues.apache.org/jira/browse/GEODE-6424 into release/1.9.0? Without it we will have to wait for the next release before we can have meaningful baselines for function and query benchmarks. Without this fix

Re: Merging GEODE-6424 into release/1.9.0

Done! > On Feb 20, 2019, at 1:22 PM, Udo Kohlmeyer wrote: > > +1, Go,Go,GO!! > >> On 2/20/19 12:24, Jacob Barrett wrote: >> Anyone have issue with merging >> https://issues.apache.org/jira/browse/GEODE-6424 >> <https://issues.apache.org/jir

Re: Merging GEODE-6424 into release/1.9.0

; On Wed, Feb 20, 2019 at 2:59 PM Jacob Barrett wrote: >> >> Done! >> >>> On Feb 20, 2019, at 1:22 PM, Udo Kohlmeyer wrote: >>> >>> +1, Go,Go,GO!! >>> >>>> On 2/20/19 12:24, Jacob Barrett wrote: >>>> Anyone have issue w

Re: 1.9 release date

What Anthony said. +1 > On Mar 1, 2019, at 8:02 AM, Anthony Baker wrote: > > IMHO we start release work based on a quarterly schedule and we finish it > based on meeting quality goals. So right now I’m less worried about when the > release will be done (because uncertainty) and more focused o

Re: Jetty Webapp marked as optional?

> On Mar 5, 2019, at 1:52 PM, Jens Deppe wrote: > > How are building the code that's running here? Is it a Maven or Gradle > project and, if so, what dependencies are you declaring? Project geode-benchmarks is a Gradle project that depends on geode-core. Since the jetty-webapp dependency is

Re: [DISCUSS] Changing many geode-core dependencies from compile to runtime

+1 for the change and +1 for BOMs. We currently have an “all” BOM and a client BOM. Defining server and other usecase derived BOMs should be easy. -jake > On Mar 15, 2019, at 4:16 PM, John Blum wrote: > > If users will be explicitly declaring such dependencies in their > applications, then I

Re: Copying pdx types via client

Perhaps for others on this list that aren’t familiar with the context you could fill in the blanks. It is assumed you are asking about the “feature” where PDX metadata is propagated from one connection pool to another in an attempt to support multiple distributed systems in the same client. Whi

Re: Copying pdx types via client

> On Mar 26, 2019, at 11:26 AM, Michael Stolz wrote: > > I may be mistaken, but I think that this feature attempts to address cases > where users want to selectively copy several items from one distributed > system to another. Not sure if the two separate implementations of > "ClientCache"

Re: geode-all-bom-1.9.0.jar

It’s not API so it can be changed later right? It’s not intended for general direct consumption. The client BOM is. We can define future BOMs for consumptions. -jake > On Mar 29, 2019, at 5:42 PM, Anthony Baker wrote: > > Last call for naming suggestions. I’d like to fix this prior to rele

Re: [DISCUSS] Move or remove org.apache.geode.admin

> On Apr 2, 2019, at 5:04 PM, Dan Smith wrote: > > I think the best course of action is probably to remove it entirely. > However, this does bring up a couple of questions: > > 1) Is it ok in general to remove deprecated API in a non X.0 release (eg > geode 1.10 instead of geode 2.0)? I thin

Re: [DISCUSS] Move or remove org.apache.geode.admin

That’s your interpretation of semver. I interpret The API not to be broken within a major as those that are still valid when the major is released despite the availability of deprecated symbols from previous major. Just because I can access symbols does not make it API. API is the combination of

[Discuss] Removal of Thread Local Connection Pooling

Devs, The current connection pooling implementation contains a setting that enables a secondary pool that is thread local. See ClientCacheFactory. setPoolThreadLocalConnections method for details. This thread local pooling was added to reduce contention on the primary connection pool under high

Re: [DISCUSS] Move or remove org.apache.geode.admin

ion; just >> *sometime* within a new major version. >> >> Given that, these APIs were definitely deprecated before 1.0 and I believe >> we're within the definition of *semver* to be free to remove them now. >> >> +1 to removing them any time before 2.0.

Re: [Discuss] Removal of Thread Local Connection Pooling

> On Apr 5, 2019, at 8:23 AM, Anthony Baker wrote: > > One question: if I’m using thread-local connections ho does that affect pool > sizing? Are thread-local connections included in the overall pool size or > accounted for separately? On the client side thread local pool just pulls from t

Re: InternalCacheTransactionManager2PC removed from public API

Sorry for the delay. In the initial source grant it inadvertently in the public headers. Prior to the 1.x release of Geode Native it was move internal where it belongs. There is currently no way in Geode Native to get access to the two phases commit transaction manager. This is an oversight tha

Re: InternalCacheTransactionManager2PC removed from public API

> On Apr 17, 2019, at 9:26 AM, Charlie Black wrote: > > The way transactions are done in Geode there shouldn't be any artifacts on > the client side. > > For more info check out the chapter on transactions with Geode: > https://geode.apache.org/docs/guide/16/developing/transactions/JTA_transa

Re: GEODE-6662 for 1.9.0

If it Leakes on object overt the life of the application, no biggy. If it leaks an object frequently, say every time you call get, then fixxy. -Jake > On Apr 17, 2019, at 12:05 PM, Anthony Baker wrote: > > If a geode process leaks memory, I think that’s a critical issue. > > Anthony > > >

Re: defunct branches

> On Apr 18, 2019, at 8:01 AM, Bruce Schuchardt wrote: > > It's also pretty weird that the UI doesn't show all of the release branches, > like these: > > origin/release/1.1 > origin/release/1.2.0 > origin/release/1.2.1 > origin/release/1.3.0 > origin/release/1.4.0 >

Re: Geode release steps

We should be creating the release branches for all those repositories at the same time. > On Apr 22, 2019, at 1:56 PM, Dan Smith wrote: > > Hi devs, > > I'm looking at trying to automate some of the geode release steps, but one > thing I noticed is that we are inconsistent about when or if we

Re: Extensions team hijack into Apache workers

Why are you asking to hijack a worker? Workers do not perform any builds or tests as all of this is offloaded to the heavy lifter VMs. These VMs are transient and can’t be accessed after a job is complete. -jake > On May 7, 2019, at 3:28 PM, Scott Jewell wrote: > > Hi, > > Not sure if this

Re: Extensions team hijack into Apache workers

ne > if the test was making progress or had hung. > > It sounds as if that hope may be misguided. > > Is there some way that you'd recommend to accomplish this? > > Thanks. > >> On Tue, May 7, 2019 at 3:55 PM Jacob Barrett wrote: >> >> Why are you askin

Re: Remove mavenLocal from Geode gradle files

Maven local is necessary for some of our other build processes like benchmarks. Is there no other way to correct this issue. I have never run into this issue. -jake > On May 8, 2019, at 10:13 AM, Kirk Lund wrote: > > I'd like like to remove mavelLocal the Geode gradle files. > > GEODE-6753:

Re: Remove mavenLocal from Geode gradle files

ll resources from Maven local. Benchmarks is an external wrapper that > executes geode commands, right? > > On Wed, May 8, 2019, 12:12 Jacob Barrett wrote: > >> Maven local is necessary for some of our other build processes like >> benchmarks. >> >> Is there

Re: [DISCUSS] reduce PR checks to JDK11 only

I that the serialization test was only an issue when compiled with JDK11? We don’t compile with JDK11, we compile with JDK8 and run under JDK11. > On May 20, 2019, at 8:50 AM, Robert Houghton wrote: > > The PR pipeline should be a timely test, but also sane and helpful. Maybe > making the JDK8

Re: Changing external methods to no longer throw UnsupportedOperationException

But what application is going to legitimately call this method and expect that it throw an exception? What would be the function of that usage? If you assume that calling this method under these conditions had no value and would therefor never have been called then one could argue that implement

Re: [DISCUSS] Criteria for PMC, committers

A few observations I have found by looking through the Apache wiki for all the projects is: That several of them do separate the two roles. The discussions about committers happens in the dev@ list while discussions for PMC happen on the private@ list. Some projects projects treat PMC as a promot

Re: [DISCUSS] require reviews before merging a PR

> On May 30, 2019, at 5:00 PM, Anthony Baker wrote: > > Checkout [1] for some helpful context from the early days. > > Anthony > > [1] > https://lists.apache.org/thread.html/108602a14b422abe9c94d46b2c5d02c11a9cbb8b224db08b706c6263@1430991799@%3Cdev.geode.apache.org%3E > >

Re: [DISCUSS] require reviews before merging a PR

> On May 30, 2019, at 4:47 PM, Owen Nichols wrote: > > Some folks have found it really helpful to have the PR author schedule a > walk-through of the changes to give reviewers more context and explain the > thinking behind the changes. This can’t be policy unless the walkthrough is schedule

Re: [DISCUSS] Criteria for PMC, committers

of this > thread, the only real requirement for committer (or PMC) is trust, and I > believe voting is the best way to reach consensus on when trust has been > earned. > > -Owen > >> On May 29, 2019, at 12:04 PM, Jacob Barrett > <mailto:jbarr...@pivotal.io>> wr

Re: [DISCUSS] require reviews before merging a PR

> On May 31, 2019, at 8:52 AM, Owen Nichols wrote: > > Apache requires 3 reviews for code changes. Docs and typos likely would not > fall under that heading. Where is this listed as a requirement? The link you sent before offered guidance on common policies within the organization.

Re: what is the best way to update a geode pull request

Would that be PR of a the PR template. Might that cause a black hole to form? I’m in favor of updating this wall of text you smack your face on for each PR. Let’s pair it down to discourage people (myself strongly included) from ignoring or deleting it. -jake > On May 31, 2019, at 1:33 PM, A

Re: [DISCUSS] require reviews before merging a PR

) reviews > before a PR can be merged, since some valid scenarios were raised where 0 > reviews prior to merge could be appropriate. > >> On May 31, 2019, at 9:01 AM, Jacob Barrett wrote: >> >> >>> On May 31, 2019, at 8:52 AM, Owen Nichols wrote: >

Re: [DISCUSS] require reviews before merging a PR

I’ll be posting a PR for it later next week so y’all can review. > On May 31, 2019, at 2:02 PM, Helena Bales wrote: > > I'm happy to provide feedback on a CONTRIBUTING.md, but I don't want to > take the lead on this particular doc right now. > >> On Fri, May 31

Re: what is the best way to update a geode pull request

> On May 31, 2019, at 2:23 PM, Udo Kohlmeyer wrote: > I must be honest, but I am yet to find 1 developer that keeps a list of all > changes they want to be refactored separate from the bug/feature code. OR > better stated I am yet to find where this was sustainable AND productive. Challenge

Re: what is the best way to update a geode pull request

> On May 31, 2019, at 2:40 PM, Udo Kohlmeyer wrote: > > If we are concerned about the single line that can break the product, then > our testing has failed us on so many levels, that there is no hope. Sorry, I used a hyperbolic statement about looking for 1 line out of 1000. The point was “

Re: [DISCUSS] Criteria for PMC, committers

I think it's a lot of what is under the contributing section, but I think it needs to be cleaned up. A lot of the what should be done is lost under the screen shots of things. I nice clear bullet point, with maybe links to the wiki for details, would be nice. If we collected all of this in the C

Re: IntelliJ inspect git hooks

If you’re already using IntelliJ then if you commit with IntelliJ you can enable the commit analysis and it will tell you if there are warnings before you commit. -jake > On Jun 3, 2019, at 9:16 AM, Peter Tran wrote: > > Hi All, > > I was wondering if anyone has any git hooks setup to ensur

Re: IntelliJ inspect git hooks

anks Jake > > Is it configurable to warn you if you're adding new warnings? Right now > it's tough to clean up all warnings in a file you touch but at least we > should not be making things worse (at least stop the bleeding so to say) > >> On Mon, Jun 3, 2019 at 12:55 P

Re: [DISCUSS] Disable merge for failing pull requests

I’m still not interested until there is a solution for all community members to retrigger failed jobs. Also not excited about not having a way to override if there is a known issue that prevents a job from going green. My last PR needed multiple reruns because of a known flakey test with an acti

Re: "Output path is not specified for module" (IntelliJ)

This seems to happen frequently with 2019.1. The easiest way I found to fix this was to start over with the IJ project. Some have had luck switching between the gradle builder and the IJ builder in the cradle configuration panel. > On Jun 6, 2019, at 11:47 AM, Peter Tran wrote: > > Hello, >

Re: [DISCUSS] changing geode 32-bit counter stats to 64-bit

I like this! I’d go ahead and change all the usage of the int methods to the long methods. I’d deprecate the int methods to make it very clear. If some consumer is using the int methods they will still work with the same rollover issues but perhaps with the deprecated warning they will update

Re: Unnecessary uses of final on local variables

> On Jun 13, 2019, at 1:31 PM, Kirk Lund wrote: > > According to Effective Java 3rd Edition, all local variables are implicitly > made final by the JVM… Can you please provide a link or at least the chapter and item number that this statement is made in. I have scanned through the book and s

Re: [PROPOSAL]: Improve OQL Method Invocation Security

> As part of GEODE-3247 , > several options were analysed and, after considering the wealth of security > holes and the difficulty of determining which methods deployed by the > developer were intended to be available for queries and which were n

Re: Unnecessary uses of final on local variables

I too am in camp final too. You could say `final boolean useFinal = true`. For all the same reasons Bill stated below. > On Jun 17, 2019, at 5:33 PM, Bill Burcham wrote: > > The final keyword is not redundant—quite the opposite—it's extremely valuable. > > Local variables are not, in general,

Re: [PROPOSAL]: Improve OQL Method Invocation Security

ay. >> That said, I won't have time to go through the proposal and make the >> required changes until next week, so I'll keep the document hidden until >> all biased words are replaced. >> Cheers. >> >> >> On Sat, Jun 15, 2019 at 12:25 AM Jacob Ba

Re: Request for contributor permissions

Maria, There are no special permissions to contribute. Please read https://cwiki.apache.org/confluence/display/GEODE/How+to+Contribute for details about contributing. Contributions can be made via GitHub’s pull request featu

Re: "Output path is not specified for module" (IntelliJ)

gt;> but inevitably will return. I would recommend the setting changes as >>>> described above if it recurs. >>>> >>>> Ryan >>>> >>>> On Thu, Jun 6, 2019 at 12:04 PM Peter Tran >>> <mailto:pt...@pivotal.io>> wrote: >>

Re: [DISCUSS] Add a test dependency to geode-core - ArchUnit

Are you adding this dependency to just the membership module? I am cool with that. > On Jun 20, 2019, at 2:39 PM, Dan Smith wrote: > > Hi all, > > Bill, Ernie, and I would like to add a new (apache licensed) test > dependency to geode-core - https://github.com/TNG/ArchUnit. This is a tool > th

Re: [DISCUSS] Add a test dependency to geode-core - ArchUnit

ing a way to track progress and enforce the direction of > dependencies on the way to a separate gradle module will help with that. > > -Dan > >> On Thu, Jun 20, 2019 at 4:23 PM Jacob Barrett wrote: >> >> Are you adding this dependency to just the membership modul

Re: [PROPOSAL]: Improve OQL Method Invocation Security

> On Jun 24, 2019, at 11:35 AM, Juan José Ramos wrote: > > Please take some time to review it thoroughly, adding comments and/or > concerns either to the *Wiki page [1]* or this email thread directly, all > feedback is more than welcome. Let’s try to keep the conversation in one medium or the o

Re: [PROPOSAL]: Improve OQL Method Invocation Security

> On Jun 24, 2019, at 11:49 AM, Juan José Ramos wrote: > > I’d rather get feedback in any way and aggregate everything on my own than > maybe not getting anything because I'm explicitly limiting the options to > provide it. Dealers choice so both it is! Could you also consider public live s

Re: [DISCUSS] RFC 0: Lightweight RFC Process

> On Jun 24, 2019, at 3:42 PM, Dan Smith wrote: > >> >> Just to make sure I got this 100% right, you mean the work related as part >> of the proposal would be under development, correct? > > > Yes! And I like your suggestion to just create a couple of buckets on the > wiki, rather than one

Re: [PROPOSAL]: Improve OQL Method Invocation Security

Juan, You asked people to comment in both the wiki and the emails but you didn’t include comments from the wiki below. I have two issues, the first I raised in the wiki is what about caching the authentication lookups: > Can we safely assume that some caching of authorization requests will be

Re: [PROPOSAL]: Improve OQL Method Invocation Security

> On Jul 1, 2019, at 6:55 AM, Juan José Ramos wrote: > >> Can we safely assume that some caching of authorization requests will >> be performed? What will the scope and lifetime of this caching be? Are the >> authentication rules and modules assumed to be immutable at runtime? All of >> this w

Re: [PROPOSAL]: Improve OQL Method Invocation Security

> On Jul 2, 2019, at 11:58 AM, Juan José Ramos wrote: > > Hello Jake, > > I've been doing some reading about the *Java Security Manager* and, even > when it might work for our use case, I don't think is a good fit due to the > following reasons: > 1). We already have chosen *Shiro* for authen

Re: [PROPOSAL]: Improve OQL Method Invocation Security

So if we don’t want to use the Java built in SecurityManager to solve this, because we feel it's too big or too inflexible for our needs, have other projects implemented something we can borrow? We can’t be the first to need something like this if Java’s solution isn’t a good fit. Again I want

Re: [PROPOSAL]: Improve OQL Method Invocation Security

edAuthorization > [4]: > https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security#OQLMethodInvocationSecurity-AnnotationBasedMethodAuthorizer > > On Fri, Jul 5, 2019 at 1:46 PM Jacob Barrett wrote: > >> So if we don’t want to use the Java built in SecurityManager t

Re: [DISCUSS]: ClusterManagementService configuration objects

Are these new objects public API or internal? > On Jul 10, 2019, at 1:16 PM, Jinmei Liao wrote: > > We've been working on a new and improved ClusterManagmentService for a > while now. It allows developers/administrators to manage the clusters > through rest calls instead of having to use gfsh (m

Re: [Proposal] Refactor the Cache and Region perf stats structure.

There isn’t currently a partition stat instance per bucket. Are you saying you’re making that a thing now? > On Jul 11, 2019, at 9:24 AM, Mark Hanson wrote: > > Correct. > >> On Jul 11, 2019, at 9:23 AM, Darrel Schneider wrote: >> >> Why would a PartitionedRegionStatsImpl contain more than o

Re: [Proposal] Refactor the Cache and Region perf stats structure.

. I would hope to roll them up, > but I can see a case where you have buckets on different servers, that would > seem to necessitate that. > >> On Jul 11, 2019, at 9:26 AM, Jacob Barrett wrote: >> >> There isn’t currently a partition stat instance per bucket. Are you s

Re: IntelliJ setup for develop

Tests are rebuilt because for some reason IntelliJ calls cleanTest before test. If someone finds a way to tell it not to do that you would make some new friends. -Jake > On Jul 24, 2019, at 3:37 PM, Murtuza Boxwala wrote: > > In my ideal world, I compile and run tests with IntelliJ. IntelliJ

Re: Problem with LGTM on geode-native pull request

Yes, that seems to be the issue. Can you update the lgtm.yml and push to your branch. Thanks, Jake > On Jul 30, 2019, at 5:09 AM, Alberto Gomez wrote: > > Hi, > > I am getting a failure on the C/C++ LGTM analysis over a recently > created pull request on geode-native: > https://github.com/

Re: [DISCUSS] Time to cut Geode 1.10.0?

The selected SHA seems rather arbitrary. Could you enlighten us as to why one from last week rather than say today? GEODE-7006 fixes a bug introduced in 1.9. GEODE-7008 fixes a similar issue introduced in incubation. Both were merged today. > On Jul 30, 2019, at 10:38 AM, Dick Cavender wrote

Re: Problem with LGTM on geode-native pull request

gt; >> >> On Wed, Jul 31, 2019 at 5:38 AM Alberto Gomez >> wrote: >> >>> Hi, >>> >>> I updated the .lgtm.yml file so that the right version of Apache Geode >>> is downloaded and now I get errors in the linking process about some >>

Re: Travis-ci & geode-native repo

We worked with Travis support to increase our timeout on the backend. As you can see from the Travis report it takes a long time to build. It doesn’t run any of the integration tests either. We use it as a litmus test on PRs mostly. There is a future goal to role the build into the same pipelin

Re: ./gradlew test no longer runs/reruns tests?

Gradle has, for as long as I can recall, always had this behavior for unit tests. The default in Gradle Test plugin is to not rerun tests unless the main sources have changed. For integration, distributed and acceptance tests we have changed that default to always run regardless of source change

Re: geode-native ipv6

We are on the latest ACE. > On Aug 8, 2019, at 9:56 AM, Mark Hanson wrote: > > The latest ACE framework seems to have support, but I don’t know how far off > latest we are. I don’t think we test anything in an IPv6 context, so I would > say no that we don’t officially support it in the client.

Re: [DISCUSS] Geode dependency update process (review by 8/28/2019)

We can simply update all dependencies to their latest as long as within a major it doesn’t change the public API. We have tried to do this after releases, though sometimes that PR languishes for a while. There is no formal process though so formalizing it would be great. The release manager coul

Re: Failing LGTM Check

I have a ticket open with LGTM on this issue. Just ignore it and move forward. > On Aug 13, 2019, at 1:48 PM, Aaron Lindsey wrote: > > My PR has a LGTM check that shows “Failing” on the PR and LGTM site, but the > LGTM logs say “Succeeded”: > Failing PR check: https://github.com/apache/geode/pu

Re: Failing LGTM Check

LGTM confirmed this is a recent issue on their end that they are currently addressing. https://discuss.lgtm.com/t/analysis-failed-in-github-pr-integration/2251 -Jake > On Aug 13, 2019, at 1:48 PM, Aaron Lindsey wrote: > > My PR has a LGTM check that shows “Failing” on the PR and LGTM site, b

Re: geode-native ipv6

ll be same until > // IPV6 support is added in the client > uint32_t temp; > memcpy(&temp, hostAddr, 4); > m_memID.writeInt(static_cast(temp)); > > >> On Thu, Aug 8, 2019 at 1:18 PM Jacob Barrett wrote: >> >> We are on the latest ACE. >> >>> On

Re: I propose including the fix for GEODE-3780 in 1.10

Because someone will ask, can we be proactive in these request with identifying if the issue being fixed is introduced in Geode 1.10 or is a preexisting condition. -jake > On Aug 15, 2019, at 2:09 PM, Bruce Schuchardt wrote: > > This is a fix for a problem where a member that has lost quorum

Re: Propose fix for 1.10 release: Prevent NPE in getLocalSize()

You should be able to do the cherry-pick on your fork and then open a PR against the release branch. > On Aug 15, 2019, at 2:04 PM, Aaron Lindsey wrote: > > It sounds like there is consensus on adding this fix. Could someone please > cherry-pick this for me? > > Thanks, > Aaron > >> On Aug 1

Re: New build warnings

On that note, I’ve had a PR open to address all the API warnings for some time now. Would love a review. https://github.com/apache/geode/pull/3872 > On Aug 15, 2019, at 3:59 PM, Kirk Lund wrote: > > Just a reminder, that our many sun.misc.* warnings are drowning out real > warnings... > > We

Re: [DISCUSS] what region types to support in the new management rest api

+1 to Alexander’s statement. Also, initial revisions need not be feature parity. For us on the common use cases. It’s sounds like an advanced use case to have proxy regions on the server so focus on the common partitioned and replicated first for the initial release. -jake > On Aug 20, 2019,

Re: [DISCUSS] what region types to support in the new management rest api

If you code it you have to test it. An all or nothing approach will take longer to deliver any value. Breaking it into a priority set and committing the sets gives immediate value. > On Aug 20, 2019, at 6:12 PM, Michael Stolz wrote: > > I'm not at all sure why supporting the current set is mo

Re: geode-native ipv6

, at 12:34 AM, Mario Ivanac wrote: > > Hi, > > > Can you help me, how to simulate ipv6 in new integration test framework? > > > BR, > > Mario > > ____ > Šalje: Jacob Barrett > Poslano: 14. kolovoza 2019. 21:00:35 > Pri

Use of Internal JDK API

Hey Team, I just merged the fix for GEODE-130, an oldie but goodie, regarding all those annoying internal JDK API warnings when compiling. Please don’t be that person who puts more internal JDK API’s into the product. If you must please do it in the new geode-unsafe module. You will find that t

Re: Gradle daemon crashed in PR precheckin

I wonder if the auto merge creates something funky. Try rebasing or merging your branch first then push. > On Aug 22, 2019, at 11:11 AM, Bruce Schuchardt wrote: > > Using --no-daemon doesn't stop it from launching a daemon. It just tells it > to shut down the daemon when the build is done. >

Re: [DISCUSS] Improvements on client function execution API

> On Aug 22, 2019, at 11:29 AM, Dan Smith wrote: > I took a look at the C++ API. The C++ API also has a > ResultCollector.getResult(timeout) method. Does that timeout do anything, > given that execute(timeout) already waited for the given timeout? The C++ client will wait on getResult until al

Re: [DISCUSS] Improvements on client function execution API

> On Aug 22, 2019, at 11:55 AM, Jacob Barrett wrote: >> On Aug 22, 2019, at 11:29 AM, Dan Smith wrote: >> I took a look at the C++ API. The C++ API also has a >> ResultCollector.getResult(timeout) method. Does that timeout do anything, >> given that execute(time

Re: [DISCUSS] Improvements on client function execution API

> On Aug 21, 2019, at 8:49 AM, Alberto Gomez wrote: > 2. Timeout in ResultCollector::getResult() and Execution::execute() blocking > > Regarding the timeout in the ResultCollector::getResult() method problem and > the blocking/non-blocking confusion for Execution::execute() two alternatives

Re: Gradle daemon crashed in PR precheckin

gt; https://stackoverflow.com/questions/46801741/jvm-crashes-with-error-cannot-allocate-memory-errno-12 > > On Thu, Aug 22, 2019 at 11:16 AM Jacob Barrett wrote: > >> I wonder if the auto merge creates something funky. Try rebasing or >> merging your branch first then push

Re: [DISCUSS] Version 1.11 serialization ordinal is wrong

I commented in the jira about using int. > On Aug 23, 2019, at 9:54 AM, Bruce Schuchardt wrote: > > Yeah, that code is confusing. I think the ordinal constants should all be > changed to shorts and the constructor for Version should take a short as > well. I can see why someone creating a ne

Re: Proposal to include GEODE-7088 and GEODE-7089 in 1.10.0

+1 Thanks for the details! > On Aug 26, 2019, at 3:33 PM, Ryan McMahon wrote: > > Udo, > > Here are inline answers to your questions: > > *Is this an existing issue?* > > Short answer - yes, but it has never been in a release version of Geode. > The leak was introduced as part of some change

Re: [DISCUSS] Pulling the current proposed 1.10 release until we can agree on develop being stable

While I share your concern that too many things are getting cherry-picked into the release, I disagree that recutting the branch is a good solution. Recutting the branch effectively cherry-picks everything on the develop branch. This means we start at ground zero evaluating this release. Each

Re: [DISCUSS] Improvements on client function execution API

t;> we can just clearly document the current behavior of execute() as >> part of >> adding these new methods. Going forward we can add new methods to >> Execution >> that are clearly non-blocking (submit?, invoke?) and implement them >> consistently on *both* the client in the ser

Re: Question about excluding serialized classes

Sorry I am entering this late in the game but why do we need to decorate the function at all for metrics. The current implementation has statistics without decoration. All the concerns raised in this thread concern me as well as the cost of constructing yet another object every time a function i

  1   2   3   4   5   6   7   >