Re: Geode retry/acknowledge improvement

In the JIRA ticket the stuck thread is a Function Execution executor thread. These threads force the use of shared connections by default. If you want to get the behavior that Darrel is describing you need to modify your functions to request thread-owned connections with

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

Kirk speaks my mind. -1 on this requirement On 4/21/21, 11:29 AM, "Kirk Lund" wrote: -1 as I've already explained in my DISCUSS thread for this topic, I don't think final gives sufficient benefit for local variables or method parameters because it only prevents reassigning object

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

I agree with Udo. Also, this shouldn't be a VOTE without discussion and I don't see a DISCUSS thread. On 4/14/21, 7:46 PM, "Udo Kohlmeyer" wrote: "+1" to ENCOURAGING developers to make "final" a requirement for method arguments. "-1" to making it a hard rule. If we want to

request for people putting up pull requests

If you want people to review your PR it would be kind of you to put in a description of its purpose. If you just reference a JIRA ticket we have to do the extra work of pulling up the ticket to see what it’s about. I’m seeing this more and more lately.

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

ches are not a good alternative. A separate repo would make the entire process (e.g. releases) easier, not unlike the Kafka connector, or even Spring Data for that matter. $0.02 -j ________ From: Bruce Schuchardt Sent: Mon

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

incomplete at best. It does not properly handle all forms of JSON or types (e.g. Java 8 Data/Time types). From: Bruce Schuchardt Sent: Thursday, March 25, 2021 8:01 AM To: dev@geode.apache.org Subject: Re: [DISCUSS] removal of experimental Proto

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

-Connector * Geode-Redis * Geode Offheap These are projects that we maintain without any (known) users actively using these features. --Udo On 3/24/21, 2:16 AM, "Bruce Schuchardt" wrote: Hi folks,

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

oval. I was working on improving the geode thread monitor and found doing that on the protobuf code was much more complicated. ________ From: Bruce Schuchardt Sent: Tuesday, March 23, 2021 8:16 AM To: dev@geode.apache.org Subject: [

[DISCUSS] removal of experimental Protobuf client/server interface

Hi folks, We’ve had an experimental client/server interface in Geode that no-one to my knowledge is using. We’re testing it with every build and are having to make changes to it to keep it up to date with the rest of the project. The last change of substance to the geode-protobuf

Re: Question regarding VersionRequest/VersionResponse messages

Rolling upgrade is only supported for Geode v1.0 and up. Rolling from GemFire 8 isn't supported due to the JGroups upgrade. On 3/10/21, 10:37 AM, "Bill Burcham" wrote: Jakov, VersionRequest/VersionResponse is understood by the 8.1.x/GFE_81 product versions. I don't know what

Re: [PROPOSAL] backport GEODE-8761 to support/1.14

+1 This will be very nice to have On 3/9/21, 9:08 AM, "Darrel Schneider" wrote: GEODE-8761 causes geode to detect threads in a cache server that are stuck processing a client request. This can be very helpful in diagnosing hangs. The changes to make this happen are rather simple and I'd

Re: errors from logging code in unit tests

" waiting for views to stabilize sending SerialAckedMessage from m1 to m2 On 2/24/21, 1:30 PM, "Bruce Schuchardt" wrote: This has started showing up in all of my test runs. Is anyone else seeing it? Maybe something in my environment?

errors from logging code in unit tests

This has started showing up in all of my test runs. Is anyone else seeing it? Maybe something in my environment? 2021-02-24 11:19:44,765 main ERROR Error processing element GeodeConsole ([Appenders: null]): CLASS_NOT_FOUND 2021-02-24 11:19:44,778 main ERROR Error processing element

Re: [DISCUSS] client/server communications and versioning

e WAN - do we want to keep sending the current product version with the WAN, or use the client protocol version? -Dan ____ From: Bruce Schuchardt Sent: Tuesday, February 23, 2021 9:38 AM To: dev@geode.apache.org Subjec

Re: [DISCUSS] client/server communications and versioning

-Dan From: Bruce Schuchardt Sent: Tuesday, February 23, 2021 9:38 AM To: dev@geode.apache.org Subject: [DISCUSS] client/server communications and versioning I’m considering a change in client/server communications that I would like feedback on.

[DISCUSS] client/server communications and versioning

I’m considering a change in client/server communications that I would like feedback on. We haven’t changed on-wire client/server communications since v1.8 yet we tie these communications to the current version. The support/1.14 branch identifies clients as needing v1.14 for

Re: code-owners seems to have some problems

Thanks Owen. Good to know about the keyhole/shield icons. The filter function doesn't work as well as I hoped. The shield icons that matched my username in CODEOWNERS are BOLD while the others are a bit greyed out; Using that I was able to identify a few files that matched line 28 in

code-owners seems to have some problems

I was pulled in to PR 5989 but can’t figure out how that happened with the current CODEOWNERS file. These all seem out of my area: boms/geode-all-bom/src/test/resources/expected-pom.xml

I propose to remove ProductUseLog from Geode

This is a little known class that creates a file in a Locator’s directory that logs who is in the cluster and a bit about the load on servers. These artifacts have never been useful for debugging problems and there’s no reason to keep the log. All of the information it provides is already in

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

Oh, but I forgot about WAN changes that may have been made to the handshake to allow different versions in different clusters. Jake might be right about this. On 2/2/21, 8:31 AM, "Bruce Schuchardt" wrote: I think it's only the locator connections that do this. Regular clie

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

One thing that might help somewhat would be to modify the KnownVersion class to hold both the product version and the client/server protocol version, which wouldn't have to change if there are no incompatibilities introduced in client/server comms in a release. That's more in keeping with what

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

I think it's only the locator connections that do this. Regular client->server connections using the handshake code just send the client's current version, which must not be newer than the server's version. On 2/1/21, 9:53 AM, "Jacob Barrett" wrote: Having just spent some time yanking

Integrating Geode with the Rapid membership service

There was an effort to modularize the membership system in Geode and I spent some time seeing if a different membership service could be integrated with Geode in place of the current implementation. I wrote a blog post about it here:

Re: [Proposal] - Cleanup Protocol Version Checks

/20, 9:36 AM, "Jacob Barrett" wrote: > On Dec 9, 2020, at 8:09 AM, Bruce Schuchardt wrote: > > We should also get rid of the old jump tables in CommandInitializer Would it make sense to do that in the same PR that tackles setting the min client versi

Re: [Proposal] - Cleanup Protocol Version Checks

+1 We should also get rid of the old jump tables in CommandInitializer On 12/8/20, 2:38 PM, "Jacob Barrett" wrote: We all do lots of cleanup as we go through areas of the source, like optimizing lambda expressions, renaming variables with more meaningful names and deleting commented out

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

+1 for having the default be conserve-sockets=false. Any time there has been trouble and conserve-sockets=true is involved we always suggest changing it to false. On 12/3/20, 6:58 AM, "Anilkumar Gingade" wrote: I was conversing with few of the dev's about requirement of different

Re: Apache Geode 1.13.1 patch proposal

It looks like I should hold off on backporting those two PRs. They're not high priority tickets. On 11/12/20, 2:43 PM, "Bruce Schuchardt" wrote: +1 I'll have a couple of PRs that I'll want to backport next week. On 11/12/20, 11:01 AM, "Dick Cavender" wrote

Re: Apache Geode 1.13.1 patch proposal

+1 I'll have a couple of PRs that I'll want to backport next week. On 11/12/20, 11:01 AM, "Dick Cavender" wrote: It's been two months since the 1.13.0 release and there have been 28 important fixes on support/1.13 that the community would benefit from. Based on this I'd like to propose

Re: PR process and etiquette

fd54990524108d87ba4a89c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637395294432731053%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=jSkrBwqgjJ83QGTeEsB5NJkOU9j4zq2THWUEDPPTee0%3Dreserved=0 > > > > > > From

Re: PR process and etiquette

o request a review of their PR seems far more problematic in term of attracting and retaining new contributors. On 10/28/20, 8:10 AM, "Bruce Schuchardt" wrote: -1 While I often use the Draft option I don't see why we want to add even more rules about how we use git

Re: PR process and etiquette

-1 While I often use the Draft option I don't see why we want to add even more rules about how we use github. I think it's enough to 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

Re: [PROPOSAL] Backport GEODE-6008 to support 1.12

+1 On 9/29/20, 3:10 PM, "Xiaojian Zhou" wrote: Hi, GEODE-6008 changed “java.lang.IllegalStateException: NioSslEngine has been closed” to IOException, which enabled DirectChannel to handle it and retry the connection in the case that the connection is closed. This fix is

[PROPOSAL] backport GEM-8506 to support branches

This is a long-standing problem that we’d like to get into the support branches. While the problem affects performance of transmission of large messages it also causes decryption problems with secure communications using TLSv1.3. While folks can avoid the problem by using TLSv1.2 we would

Re: Geode 1.13 RC1 accepted

I missed the vote but am okay with it. Maybe not start a 3-day vote on a holiday next time? On 9/9/20, 3:49 PM, "Dave Barnes" wrote: It's past the announced deadline and we have closed the vote with a successful result. Voting status == +1 10 votes (*=PMC member,

Re: [PROPOSAL] Backport GEODE-8475 to 1.13

+1 On 9/2/20, 10:38 AM, "Xiaojian Zhou" wrote: Hi, All: I want to backport my fix in GEODE-8475 to 1.13. It fixed a hang caused by a potential deadlock. This fix is quite safe, I have verified it by running all queue related regression. Regards Gester

[PROPOSAL] port GEODE-8467 to support/1.13

I’d like to cherry-pick this change into support/1.13: There is a flaw in the code that handles a server being forced out of the cluster. The flaw keeps the server from shutting down and leaves the server in a hung state. The PR adds error handling to two methods, one in the Cache’s

[DISCUSS] reminder: proposal for WAN support of an ingress proxy

Comments due by the end of this week… In some environments it’s expensive to provide all server machines with externally-resolvable hostnames. We recently added support for “off platform” clients to access servers through an ingress

[DISCUSS] proposal for WAN support of an ingress proxy

In some environments it’s expensive to provide all server machines with externally-resolvable hostnames. We recently added support for “off platform” clients to access servers through an ingress proxy

Re: [PROPOSAL] port GEODE-8385 changes to support/1.13

> > On Wed, Jul 29, 2020 at 8:04 AM Bruce Schuchardt > wrote: > > > This concerns a hang during recovery from disk. The problem was > > introduced in 1.13. > > > > https://nam04.safelinks.protection.outlo

[PROPOSAL] port GEODE-8385 changes to support/1.13

This concerns a hang during recovery from disk. The problem was introduced in 1.13. https://issues.apache.org/jira/browse/GEODE-8385

Re: [PROPOSAL] backport fix for GEODE-8020 to support/1.13

Since I had 3 +1’s I merged the change to support/1.13 From: Bruce Schuchardt Date: Thursday, July 9, 2020 at 8:00 AM To: "dev@geode.apache.org" Subject: [PROPOSAL] backport fix for GEODE-8020 to support/1.13 There are reports that SSL performance is off on the support/1

[PROPOSAL] backport fix for GEODE-8020 to support/1.13

There are reports that SSL performance is off on the support/1.13 branch with respect to the support/1.12 branch, but performance on develop okay. The only communications changes in develop that aren’t in 1.13 are those that fixed this long-standing bug, so I’d like to backport it to the 1.13

Re: Back-Port GEODE-8240 to 1.12, 1.13

+1 On 7/1/20, 9:43 AM, "Bill Burcham" wrote: I'd like permission to back-port the fix for rolling upgrade bug GEODE-8240 to support/1.12 and support/1.13 -Bill

Re: [PROPOSAL] merge GEODE-8259 to support branches

+1 I reviewed this PR and, as Gester said, it's low risk. If it fixes a problem someone is having let's backport it. On 6/30/20, 3:51 PM, "Xiaojian Zhou" wrote: Customer encountered a singlehop getAll failure due to SerializationException which is identified as socket error. The

Re: Fate of master branch

Let's just delete it. I need to do that in my own repos as well. On 6/26/20, 8:05 AM, "Blake Bender" wrote: Apologies if this has been addressed already and I missed it. In keeping with other OSS projects, I believe it’s time we did something about removing the insensitive term master

[PROPOSAL] merge GEODE-8195 to support/1.13 and support/1.12

This small fix avoids a failure of one cluster to communicate with the locators of another cluster, ensuring that a proper handshake for WAN communications occurs. Without the fix it’s possible that WAN connections will not be formed and updates will not be transmitted between sites.

Re: [PROPOSAL] Add windows jobs to PR checks

If they take a very long time to run, how about adding them but not requiring them to pass? On 6/25/20, 10:08 AM, "Jacob Barrett" wrote: > On Jun 25, 2020, at 10:01 AM, Jinmei Liao wrote: > > +1, what was the reason for it not being included the PR before? The Windows

Re: [PROPOSAL] back port fix for GEODE-8251 to support branches

+1 On 6/18/20, 3:24 PM, "Jinmei Liao" wrote: The fix for this issue

[PROPOSAL] backport GEODE-8277 to support/1.13

Several keystores used by a test have expired, which will cause acceptance tests to fail in support/1.13. I’d like to cherry-pick the new keystores into that branch. The new keystores have a 5/2120 expiration date.

[PROPOSAL] backport PR #5250 to support/1.13

This PR has been merged to develop. It fixes a problem with the previous commit for GEODE-8144 that caused performance degradation when TLS is enabled between servers. I have run perf tests and verified that it fixes the problem. It’s a small change that makes a big difference…

[PROPOSAL] backport GEODE-8238 to support/1.13

This ticket concerns loss of a message and a subsequent hang during shutdown. The problem is also in support/1.13 and I’d like to backport to that branch. https://issues.apache.org/jira/browse/GEODE-8238 It’s a small change to fix a problem introduced in changes for GEODE-7727.

Re: [DISCUSSION] Stop using the Geode Repository for Feature/WIP Branches

Jake, you make some good points that I hadn't considered before. On 6/2/20, 3:42 PM, "Jacob Barrett" wrote: I know this has been brought up multiple times without resolution. I want us resolve to ban the use of Geode repository for work in progress, feature branches, or any other

[PROPOASAL] backport GEODE-8144

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 locators. Without this fix it’s not possible to boot a

Re: [PROPOSAL] port GEODE-8144 changes to 1.13

to add my endorsement first thing next week assuming it gets into develop before the weekend. > On May 22, 2020, at 1:39 PM, Bruce Schuchardt wrote: > > Sorry about the weird link - this is PR 5131 > > > > > On 5/22/20,

Re: [PROPOSAL] port GEODE-8144 changes to 1.13

Sorry about the weird link - this is PR 5131 On 5/22/20, 1:33 PM, "Bruce Schuchardt" wrote: I’ve been asked to propose backporting these changes to the 1.13 branch. This is a security issue – endpoint verification in servers is currently broken. That is, if you enable

[PROPOSAL] port GEODE-8144 changes to 1.13

I’ve been asked to propose backporting these changes to the 1.13 branch.  This is a security issue – endpoint verification in servers is currently broken.  That is, if you enable it you’re unable to start up a cluster. Endpoint verification requires the server-side of a tcp/ip connection to

Re: Question about version checks inside fromData method in GatewaySenderEventImpl

While GatewaySenderEventImpl is structured correctly to fit into the backward-compatibility serialization framework it does have some odd code. It looks like mistakes were made in the past in the serialization code for this class and the odd code is trying to compensate. The "version"

re: reverting GEODE-8020 in support/1.12

Never mind that last email – I see that Owen already reverted it.

reverting GEODE-8020 in support/1.12

The initial PR for GEODE-8020 is in the support/1.12 branch but has proven to reduce performance.  We’ve since found that the buffer corruption that this PR was addressing was due to the test in question using TLSv1 as the ssl-protocol.  Changing the test to use TLSv1.2 fixed the problem, so

Re: Update of SSLParameterExtension interface

I guess that would have to go into the 1.13 branch as well. This changes the public API but I think we should do it. The current API isn't usable since it refers to a non-public interface. On 5/4/20, 9:31 AM, "Mario Ivanac" wrote: Hi all, after comments that

Re: Dangers of using sockets in unit tests

This seems more like it should be another call to remove all singletons. Tshe SocketCreatorFactoryJUnitTest that failed doesn't create a socket. It just configures a SocketCreator and then asserts that it was correctly configured. On 4/27/20, 1:58 PM, "Kirk Lund" wrote: This test

Re: Proposal to include fix for GEODE-8020 in support/1.12

Thanks - this has been merged to the support branch > On Apr 27, 2020, at 9:12 AM, Bruce Schuchardt wrote: > > commit ec8db54ad7f342542762beb8f3e912dff44e3a53 (HEAD -> develop, origin/develop) > > Author: Bruce Schuchardt > > Date:

Proposal to include fix for GEODE-8020 in support/1.12

commit ec8db54ad7f342542762beb8f3e912dff44e3a53 (HEAD -> develop, origin/develop) Author: Bruce Schuchardt Date:   Mon Apr 27 09:07:16 2020 -0700     GEODE-8020: buffer corruption in SSL communications (#4994)     revert change in GEODE-6661 that made NioSslEngine use a direct buf

Re: Checking for a member is still part of distributed system

AdvisorListener.memberDeparted() is invoked from paths other than membership view changes, such as when a Region is destroyed. A member may still be in the cluster (membership view) after AdvisorListener.memberDeparted() has been invoked. If isCurrentMember() returns true then the server is

Re: About Geode rolling downgrade

-Alberto From: Bruce Schuchardt Sent: Thursday, April 16, 2020 5:04 PM To: dev@geode.apache.org Subject: Re: About Geode rolling downgrade -1 Another reason that we should not support rolling downgrade is that it makes it

Re: About Geode rolling downgrade

-1 Another reason that we should not support rolling downgrade is that it makes it impossible to upgrade distributed algorithms. When we added rolling upgrade support we pretty much immediately ran into a distributed hang when a test started a Locator using an older version. In that release

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

I've run into the CacheExistsException problem that John mentioned many times, or the associated "A connection to a distributed system already exists in this VM" exception thrown by InternalDistributedSystem. On 4/14/20, 4:02 PM, "John Blum" wrote: Among other problems I encountered, 1

Re: JGroups vulnerabilty

Thanks Mario - Geode uses neither the AUTH nor the ENCRYPT JGroups protocols, so this doesn't apply. On 4/7/20, 12:04 PM, "Mario Kevo" wrote: Hi, I was trying to understand whether Geode is impacted by a security vulnerability reported on JGroups

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

+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. Analysis shows that Geode does not use Shiro in a manner that would

Re: WAN replication issue in cloud native environments

+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 , "dev@geode.apache.org" Cc: Jacob Barrett , Anilkumar Gingade , Charlie Black Subject: RE: WAN replic

Re: WAN replication issue in cloud native environments

.     From: Alberto Bustamante Reyes Date: Monday, March 23, 2020 at 2:18 PM To: Bruce Schuchardt , Dan Smith , "dev@geode.apache.org" Cc: Jacob Barrett , Anilkumar Gingade , Charlie Black Subject: RE: WAN replica

If you see a test fail with "Message distribution has terminated"

I’ve traced it down to the fix for GEODE-7727 while I was working on GEODE-6008 with Mark Hanson on Friday. https://issues.apache.org/jira/browse/GEODE-7727 It’s a timing issue that seems to mostly hit tests using SSL but could show up anywhere. There’s a PR up with a fix for the

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

+1 On 3/21/20, 5:17 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

Re: WAN replication issue in cloud native environments

with the hostname-for-clients approach, too. From: Alberto Bustamante Reyes Date: Wednesday, March 18, 2020 at 8:35 AM To: Dan Smith , "dev@geode.apache.org" Cc: Bruce Schuchardt , Jacob Barrett , Anilkumar Gingade , Charlie Black Subject: RE: WAN replication issue in cl

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

+1 On 3/18/20, 4:13 PM, "Dan Smith" wrote: One addendum to this proposal: This proposed method of configuring a SNI proxy server requires that the client sends the SNI hostname as part of the TLS handshake. In the previous proposal we suggested it would only be sent if a

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

+1 On 3/18/20, 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

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

-1 on changing the check I'm with Owen - let's leave things alone for now.  On 3/17/20, 7:43 PM, "Owen Nichols" wrote: At least one person on the thread (@anthony) raised concerns but has not replied since. Also since this thread was started, the bug that miscounted files has

Re: WAN replication issue in cloud native environments

I'm coming to this conversation late and probably am missing a lot of context. Is the point of this to be to direct senders to some common gateway that all of the gateway receivers are configured to advertise? I've been working on a PR to support redirection of connections for client/server

[IGNORE] another test message - sorry for the spam

test message - please ignore

I’m switching to a new email account.

Re: Let's Deprecate the SECURITY_UDP_DHALGO Configuration Property

rson-week trying to fix the problem (Bruce Schuchardt and me) and it’s not clear how much more time it will take. If we decide to deprecate the feature, fixing this problem would be de-prioritized accordingly. 3. If we decide, in the future, that UDP message secu

[PROPOSAL] include GEODE-7829 in 1.12

During a refactor the default ack-wait-threshold was changed from 15 to 51. This will affect any deployment that doesn’t set its own threshold. The ack-wait-threshold determines how long we wait for a response to a message, such as replication of a put(), before taking some action.

Re: [DISCUSSION] - ClassLoader Isolation

Udo, how does this relate to the client cache? I assume people have the same problems with dependencies in client-cache applications that they have 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

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

+1 The change Juan has made corrects a problem introduced during membership refactoring. Every cache operation message that's sent allocates several objects that used to be held in statics but were moved into instance variables at one point. Juan's change moves these back into static

Re: [DISCUSS] Prevent locator startup if startup/restart thread throws an uncaught exception

I think that sounds reasonable. There are two threads involved - the ReconnectThread, which is running InternalDistributedSystem.reconnect(), and the Location Services Restart Thread, which is running code in InternalLocator. If one of them gives up it ought to stop the other one as well and

Re: Failure to push message seen in a dunit test

0 at 10:04 AM Bruce Schuchardt wrote: > Kirk, do you recall which of the tests in that class hit this problem? It > looks pretty serious. > > On 2/19/20, 9:24 AM, "Kirk Lund" wrote: > > While running PersistentCol

Re: Failure to push message seen in a dunit test

Kirk, do you recall which of the tests in that class hit this problem? It looks pretty serious. On 2/19/20, 9:24 AM, "Kirk Lund" wrote: While running PersistentColocatedPartitionedRegionDistributedTest a thousand times to verify that I've fixed a flaky issue in the test, it hit

[PROPOSAL] include GEODE-7796 in Release 1.12.0

This fix addresses the inability of a Locator to properly reconnect to the cluster after being kicked out.  Instead of rejoining or shutting down the Locator gets into a state where it no longer tries to reboot location services and hangs.

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

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

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-testing. Problem statement: When a locator is

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

I agree with deleting @Ignored tests except for the few that have JIRA tickets open for them.  There are less than 1/2 dozen of these and we should consider keeping them since we have a way of tracking them. On 12/31/19 2:07 PM, Alexander Murmann wrote: Here are a few things that are true for

Re: [DISCUSS] abandon branch protection rules

I feel that we should keep it but that we need to look into what's causing the frustration with the stresstest job.  That seems to be the thing causing the most grief.  People make a small change to some test, such as changing an import statement, and then find that it fails in stresstest. I

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

AM, Bruce Schuchardt wrote: I see a lot of plus-ones and a "voting deadline" on this DISCUSS thread and a request to "vote" using a PR. This all seems out of order to me. Our votes are supposed to be on the email list, aren't they? and I haven't seen a VOTE request.

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

nally never do any of those three things. Please start a separate thread if you would like to revisit the community decision to require passing PR checks. On Dec 20, 2019, at 7:49 AM, Bruce Schuchardt wrote: I agree with Jake. I would go further by saying that I see very little merit in th

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

I agree with Jake.  I would go further by saying that I see very little merit in this proposal.  I think we're getting more and more bureaucratic in our process and that it stifles productivity.  I was recently forced to spend three days fixing tests in which I had changed an import statement

Re: PRs review

Mario, I've merged GEODE-6927.  You can close the JIRA ticket. On 12/10/19 4:20 AM, Mario Kevo wrote: Hi Geode dev, Need some PR reviewers on the following PRs. JIRA: https://issues.apache.org/jira/browse/GEODE-6927 PR: https://github.com/apache/geode/pull/4085 JIRA:

Re: [DISCUSSION] De/un-deprecate IndexType ENUM

This proposal seems reasonable to me On 12/3/19 10:19 AM, Joris Melchior wrote: Ah, that makes sense. I will update! On Tue, Dec 3, 2019 at 12:41 PM Alexander Murmann wrote: Joris, the "to be reviewed by" field is for a target date by which to wrap up the discussion. Do you mind updating

Re: [DISCUSS] - Move gfsh into its own submodule

+1 great idea! On 11/22/19 8:39 AM, Jens Deppe wrote: Hello All, We'd like to propose moving gfsh and all associated commands into its own gradle submodule (implicitly thus also producing a separate maven artifact). The underlying intent is to decouple geode core from any Spring dependencies.

Re: Proposal of new config property "ssl-server-name-extension"

+1 On 11/19/19 3:26 AM, Mario Ivanac wrote: Hi geode dev, as a part of solution for https://issues.apache.org/jira/browse/GEODE-7414 we would like to introduce new config property "ssl-server-name-extension". This property will contain generic string, which will be added as Server Name

Re: bug fix needed for release/1.11.0

will close at noon. Thanks, Mark On Nov 6, 2019, at 8:00 AM, Bruce Schuchardt wrote: The fix for this problem is in the CI pipeline today: https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Build/builds/1341 On 11/5/19 10:49 AM, Owen Nichols wrote: +1

  1   2   3   4   5   6   7   >