[ANNOUNCE] Apache Geode 1.13.1
The Apache Geode community is pleased to announce the availability of
Apache Geode 1.13.1.
Apache Geode is a data management platform that provides a
database-like consistency
model, reliable transaction processing and a shared-nothing architecture to
maintain very low latency performance with high concurrency processing.
Geode {version} contains a number of improvements and bug fixes. It
includes performance improvements in OQL order-by and distinct queries in
client/server when security is enabled. New GFSH commands were added to
get/set cluster config and to destroy gateway receivers. A new post
processor was added to the new client protocol. Pulse now supports legacy
SSL options. Auto-reconnecting members no more reuse old addresses and IDs.
Duplicated or member-specific receivers are removed from cluster config
during rolling upgrades. Users are encouraged to upgrade to the latest
release.
For the full list of changes please review the release notes:
https://cwiki.apache.org/confluence/display/GEODE/
Release+Notes#ReleaseNotes-1.13.1
The release artifacts can be downloaded from the project website:
The release documentation is available at:
http://geode.apache.org/docs/guide/113/about_geode.html
We would like to thank all the contributors that made the release possible.
Regards,
Dick Cavender on behalf of the Apache Geode team
needs permission to push code to geode example repo
Hi Team, I am trying to add an example for geode rest api.I have the changes in my branch but not sure what is the process to push changes to this repo.Could someone help with this? Also it seems my permission to raise Jira issue is also revoked. Please help with that too. With Best Regards, Ashish
Request for Jira Permissions
Hi, I’d like to request permission to assign jira tickets to myself and also to reopen tickets that have been resolved. Thanks, John
Re: needs permission to push code to geode example repo
Hi Ashish! The best way to contribute is to open a PR via GitHub. LMK if you need help with that. What’s your JIRA username? Anthony > On Nov 18, 2020, at 10:54 AM, aashish choudhary > wrote: > > Hi Team, > > I am trying to add an example for geode rest api.I have the changes in my > branch but not sure what is the process to push changes to this repo.Could > someone help with this? > > Also it seems my permission to raise Jira issue is also revoked. Please > help with that too. > > With Best Regards, > Ashish
Re: Request for Jira Permissions
Done. You should have access now. -Dan From: John Hutchison Sent: Wednesday, November 18, 2020 11:00 AM To: dev@geode.apache.org Subject: Request for Jira Permissions Hi, I’d like to request permission to assign jira tickets to myself and also to reopen tickets that have been resolved. Thanks, John
Re: Request for Jira Permissions
thx From: Dan Smith Date: Wednesday, November 18, 2020 at 2:08 PM To: dev@geode.apache.org Subject: Re: Request for Jira Permissions Done. You should have access now. -Dan From: John Hutchison Sent: Wednesday, November 18, 2020 11:00 AM To: dev@geode.apache.org Subject: Request for Jira Permissions Hi, I’d like to request permission to assign jira tickets to myself and also to reopen tickets that have been resolved. Thanks, John
Re: needs permission to push code to geode example repo
Hi Anish- I believe you would need to create a pull request to have your changes merged into the main repo. I’m not sure about the Jira issue. -John From: aashish choudhary Date: Wednesday, November 18, 2020 at 1:55 PM To: dev@geode.apache.org Subject: needs permission to push code to geode example repo Hi Team, I am trying to add an example for geode rest api.I have the changes in my branch but not sure what is the process to push changes to this repo.Could someone help with this? Also it seems my permission to raise Jira issue is also revoked. Please help with that too. With Best Regards, Ashish
Canceled: apache/geode-examples#492 (test-2-codeowners - 722f7ca)
Build Update for apache/geode-examples - Build: #492 Status: Canceled Duration: ? Commit: 722f7ca (test-2-codeowners) Author: Owen Nichols Message: disparate ownership areas View the changeset: https://github.com/apache/geode-examples/compare/c97cfacde936...722f7ca2fb49 View the full build log and details: https://travis-ci.com/github/apache/geode-examples/builds/202515628?utm_medium=notification&utm_source=email Restart your build: https://travis-ci.com/github/apache/geode-examples/builds/202515628?utm_medium=notification&utm_source=email -- You can unsubscribe from build emails from the apache/geode-examples repository going to https://travis-ci.com/account/preferences/unsubscribe?repository=16807635&utm_medium=notification&utm_source=email. Or unsubscribe from *all* email updating your settings at https://travis-ci.com/account/preferences/unsubscribe?utm_medium=notification&utm_source=email. Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications.
Failed: apache/geode-examples#496 (non-overlapping-changes - f503c91)
Build Update for apache/geode-examples - Build: #496 Status: Failed Duration: 1 min and 51 secs Commit: f503c91 (non-overlapping-changes) Author: Owen Nichols Message: disparate ownership areas View the changeset: https://github.com/apache/geode-examples/commit/f503c9153d63 View the full build log and details: https://travis-ci.com/github/apache/geode-examples/builds/202516058?utm_medium=notification&utm_source=email -- You can unsubscribe from build emails from the apache/geode-examples repository going to https://travis-ci.com/account/preferences/unsubscribe?repository=16807635&utm_medium=notification&utm_source=email. Or unsubscribe from *all* email updating your settings at https://travis-ci.com/account/preferences/unsubscribe?utm_medium=notification&utm_source=email. Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications.
[DISCUSS] Adding CODEOWNERS to Apache Geode
Hello Devs. I would like to improve the quality of the pull-request reviews we see for critical parts of the Apache Geode project. In discussions with other committers, a (not the) big hurdle to that is getting the right eyes to look at a given PR. To that end, I propose the adoption of GitHub's CODEOWNERS functionality for the Apache Geode code repository. A discussion-document of this issue has been written up by @upthewaterspout. Thanks Dan! https://cwiki.apache.org/confluence/display/GEODE/Introduce+Codeowners+file I have tested the feature with fellow Geode committers @upthewaterspout and @onichols-pivotal, and found it to meet our expectations. Please review the document, and comment or reply to this thread, by 25 November, so we might start the task of nominating and applying for ownership. -Robert Houghton
[PROPOSAL] Change the default value of conserve-sockets to false
Hi Geode dev, First, from the docs[1], a brief explanation of the purpose of the conserve-sockets property: "The conserve-sockets setting indicates whether application threads share sockets with other threads or use their own sockets for member communication. This setting has no effect on communication between a server and its clients, but it does control the server’s communication with its peers or a gateway sender’s communication with a gateway receiver." The current default value for the conserve-sockets property is true, which at first glance makes sense, since in an ideal world, existing sockets could be shared between threads and there would be no need to create and destroy new sockets for each process, which can be somewhat resource-intensive. However, in practice, there are several known issues with using the default setting of true. From the docs[1]: "For distributed regions, the put operation, and destroy and invalidate for regions and entries, can all be optimized with conserve-sockets set to false. For partitioned regions, setting conserve-sockets to false can improve general throughput. Note: When you have transactions operating on EMPTY, NORMAL or PARTITION regions, make sure that conserve-sockets is set to false to avoid distributed deadlocks." and[2]: "WAN deployments increase the messaging demands on a Geode system. To avoid hangs related to WAN messaging, always set `conserve-sockets=false` for Geode members that participate in a WAN deployment." Given that it is generally accepted as best practice to set conserve-sockets to false for almost all use cases of Geode beyond the most simple, it would make sense to also change the default value to false, to prevent people having to encounter a problem, search for the solution, then change the setting to what is almost always the "correct" value. I have done some experimenting to see what it would take to make this proposal a reality, and the changes required are very minimal, with only two existing DUnit tests that need to be modified to explicitly set the value of conserve-sockets that were previously relying on the default being true. Any feedback on this proposal would be very welcome, and if the response is positive, I can create a PR with the changes as soon as a decision is reached. Thanks, Donal [1] https://geode.apache.org/docs/guide/113/managing/monitor_tune/performance_controls_controlling_socket_use.html [2] https://geode.apache.org/docs/guide/113/managing/monitor_tune/sockets_and_gateways.html
Fixed: apache/geode-native#2802 (support/1.13 - ba85630)
Build Update for apache/geode-native - Build: #2802 Status: Fixed Duration: 1 hr, 19 mins, and 31 secs Commit: ba85630 (support/1.13) Author: Mario Salazar de Torres Message: GEODE-8724: Fix compilation using docker image (#696) - As latest tag for ubuntu base image was recently change from 18.04 to 20.04 it seems that some libraries version changed, like for example libc++. - As it seems with this new version libc++ headers are either not anymore located within /usr/include/c++/v1 or the symlink is missing. - So in order to solve that a symlink is manually created to ensure clang is able to find libc++ headers. (cherry picked from commit 4e241ffe6f6bda0254f97cdfe18929ce81d04ace) View the changeset: https://github.com/apache/geode-native/compare/62b51b19cc6a...ba85630388e5 View the full build log and details: https://travis-ci.com/github/apache/geode-native/builds/202594061?utm_medium=notification&utm_source=email -- You can unsubscribe from build emails from the apache/geode-native repository going to https://travis-ci.com/account/preferences/unsubscribe?repository=16807653&utm_medium=notification&utm_source=email. Or unsubscribe from *all* email updating your settings at https://travis-ci.com/account/preferences/unsubscribe?utm_medium=notification&utm_source=email. Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications.
Re: [PROPOSAL] Change the default value of conserve-sockets to false
Hi there Donal, Thank you for raising this. It is not an uncommon request to change the default value of this field. This has been discussed many times in the past. I would LOVE to approve this change, but this would mean that users that don’t set this property might suddenly have this property changed. We are not sure that this would mean for these users. BUT That said, there have been very little (to none) complaints about the product stability when `conserve-sockets=false` are set. +1 - if we are allowed to make this change outside of a major version change. --Udo From: Donal Evans Date: Thursday, November 19, 2020 at 12:04 PM To: dev@geode.apache.org Subject: [PROPOSAL] Change the default value of conserve-sockets to false Hi Geode dev, First, from the docs[1], a brief explanation of the purpose of the conserve-sockets property: "The conserve-sockets setting indicates whether application threads share sockets with other threads or use their own sockets for member communication. This setting has no effect on communication between a server and its clients, but it does control the server’s communication with its peers or a gateway sender’s communication with a gateway receiver." The current default value for the conserve-sockets property is true, which at first glance makes sense, since in an ideal world, existing sockets could be shared between threads and there would be no need to create and destroy new sockets for each process, which can be somewhat resource-intensive. However, in practice, there are several known issues with using the default setting of true. From the docs[1]: "For distributed regions, the put operation, and destroy and invalidate for regions and entries, can all be optimized with conserve-sockets set to false. For partitioned regions, setting conserve-sockets to false can improve general throughput. Note: When you have transactions operating on EMPTY, NORMAL or PARTITION regions, make sure that conserve-sockets is set to false to avoid distributed deadlocks." and[2]: "WAN deployments increase the messaging demands on a Geode system. To avoid hangs related to WAN messaging, always set `conserve-sockets=false` for Geode members that participate in a WAN deployment." Given that it is generally accepted as best practice to set conserve-sockets to false for almost all use cases of Geode beyond the most simple, it would make sense to also change the default value to false, to prevent people having to encounter a problem, search for the solution, then change the setting to what is almost always the "correct" value. I have done some experimenting to see what it would take to make this proposal a reality, and the changes required are very minimal, with only two existing DUnit tests that need to be modified to explicitly set the value of conserve-sockets that were previously relying on the default being true. Any feedback on this proposal would be very welcome, and if the response is positive, I can create a PR with the changes as soon as a decision is reached. Thanks, Donal [1] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgeode.apache.org%2Fdocs%2Fguide%2F113%2Fmanaging%2Fmonitor_tune%2Fperformance_controls_controlling_socket_use.html&data=04%7C01%7Cudo%40vmware.com%7Ca64b45dfe47446cdb7b608d88c271f1b%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637413446938137469%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=yFfjxy0smP0PBWdHp9ui6XwrOGZPIfLQF5L0gkdT9kE%3D&reserved=0 [2] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgeode.apache.org%2Fdocs%2Fguide%2F113%2Fmanaging%2Fmonitor_tune%2Fsockets_and_gateways.html&data=04%7C01%7Cudo%40vmware.com%7Ca64b45dfe47446cdb7b608d88c271f1b%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637413446938137469%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tNb0tpFLZU%2BGEIShpFpVXy4vPUv1cCyVgCF%2B1WmMjzk%3D&reserved=0
Re: [PROPOSAL] Change the default value of conserve-sockets to false
I’m not familiar with the inner workings, but your writeup is excellent and makes a compelling case. It sounds like you are saying that the original motivation for conserve-sockets=true was to improve performance, but in fact it makes performance worse. Do you have some numbers to quantify what magnitude of a difference this can make? It also looks bad that we actually document that Geode may deadlock if you use the default. To Udo’s concern about changing existing behavior, it sounds like you are saying there is no possible downside to conserve-sockets=false, but has that question been explored exhaustively? Is there ever any circumstance where we would still recommend a user to explicitly set conserve-sockets=true, once false is the default? From: Donal Evans Date: Wednesday, November 18, 2020 at 5:04 PM To: dev@geode.apache.org Subject: [PROPOSAL] Change the default value of conserve-sockets to false Hi Geode dev, First, from the docs[1], a brief explanation of the purpose of the conserve-sockets property: "The conserve-sockets setting indicates whether application threads share sockets with other threads or use their own sockets for member communication. This setting has no effect on communication between a server and its clients, but it does control the server’s communication with its peers or a gateway sender’s communication with a gateway receiver." The current default value for the conserve-sockets property is true, which at first glance makes sense, since in an ideal world, existing sockets could be shared between threads and there would be no need to create and destroy new sockets for each process, which can be somewhat resource-intensive. However, in practice, there are several known issues with using the default setting of true. From the docs[1]: "For distributed regions, the put operation, and destroy and invalidate for regions and entries, can all be optimized with conserve-sockets set to false. For partitioned regions, setting conserve-sockets to false can improve general throughput. Note: When you have transactions operating on EMPTY, NORMAL or PARTITION regions, make sure that conserve-sockets is set to false to avoid distributed deadlocks." and[2]: "WAN deployments increase the messaging demands on a Geode system. To avoid hangs related to WAN messaging, always set `conserve-sockets=false` for Geode members that participate in a WAN deployment." Given that it is generally accepted as best practice to set conserve-sockets to false for almost all use cases of Geode beyond the most simple, it would make sense to also change the default value to false, to prevent people having to encounter a problem, search for the solution, then change the setting to what is almost always the "correct" value. I have done some experimenting to see what it would take to make this proposal a reality, and the changes required are very minimal, with only two existing DUnit tests that need to be modified to explicitly set the value of conserve-sockets that were previously relying on the default being true. Any feedback on this proposal would be very welcome, and if the response is positive, I can create a PR with the changes as soon as a decision is reached. Thanks, Donal [1] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgeode.apache.org%2Fdocs%2Fguide%2F113%2Fmanaging%2Fmonitor_tune%2Fperformance_controls_controlling_socket_use.html&data=04%7C01%7Conichols%40vmware.com%7C73edfbbf4fe8435de38d08d88c271e40%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637413446927237420%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=qGAh1BfdFovLpF11C0A1jtHUwRPpQDGVO48bksfzhOw%3D&reserved=0 [2] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgeode.apache.org%2Fdocs%2Fguide%2F113%2Fmanaging%2Fmonitor_tune%2Fsockets_and_gateways.html&data=04%7C01%7Conichols%40vmware.com%7C73edfbbf4fe8435de38d08d88c271e40%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637413446927237420%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=kRoPhR391aHl1iJLAyrs7JhzyGqG2fJ4dTFLxdb4Zb0%3D&reserved=0
Re: [PROPOSAL] Change the default value of conserve-sockets to false
+1 * As nearly all of the production use-cases need "conserve-sockets" to be set to false, I think we can aim for changing the default value to false for 1.14.0 release. * We can highlight this change in the release notes and emails. Regards, Nabarun From: Udo Kohlmeyer Sent: Wednesday, November 18, 2020 6:00 PM To: dev@geode.apache.org Subject: Re: [PROPOSAL] Change the default value of conserve-sockets to false Hi there Donal, Thank you for raising this. It is not an uncommon request to change the default value of this field. This has been discussed many times in the past. I would LOVE to approve this change, but this would mean that users that don’t set this property might suddenly have this property changed. We are not sure that this would mean for these users. BUT That said, there have been very little (to none) complaints about the product stability when `conserve-sockets=false` are set. +1 - if we are allowed to make this change outside of a major version change. --Udo From: Donal Evans Date: Thursday, November 19, 2020 at 12:04 PM To: dev@geode.apache.org Subject: [PROPOSAL] Change the default value of conserve-sockets to false Hi Geode dev, First, from the docs[1], a brief explanation of the purpose of the conserve-sockets property: "The conserve-sockets setting indicates whether application threads share sockets with other threads or use their own sockets for member communication. This setting has no effect on communication between a server and its clients, but it does control the server’s communication with its peers or a gateway sender’s communication with a gateway receiver." The current default value for the conserve-sockets property is true, which at first glance makes sense, since in an ideal world, existing sockets could be shared between threads and there would be no need to create and destroy new sockets for each process, which can be somewhat resource-intensive. However, in practice, there are several known issues with using the default setting of true. From the docs[1]: "For distributed regions, the put operation, and destroy and invalidate for regions and entries, can all be optimized with conserve-sockets set to false. For partitioned regions, setting conserve-sockets to false can improve general throughput. Note: When you have transactions operating on EMPTY, NORMAL or PARTITION regions, make sure that conserve-sockets is set to false to avoid distributed deadlocks." and[2]: "WAN deployments increase the messaging demands on a Geode system. To avoid hangs related to WAN messaging, always set `conserve-sockets=false` for Geode members that participate in a WAN deployment." Given that it is generally accepted as best practice to set conserve-sockets to false for almost all use cases of Geode beyond the most simple, it would make sense to also change the default value to false, to prevent people having to encounter a problem, search for the solution, then change the setting to what is almost always the "correct" value. I have done some experimenting to see what it would take to make this proposal a reality, and the changes required are very minimal, with only two existing DUnit tests that need to be modified to explicitly set the value of conserve-sockets that were previously relying on the default being true. Any feedback on this proposal would be very welcome, and if the response is positive, I can create a PR with the changes as soon as a decision is reached. Thanks, Donal [1] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgeode.apache.org%2Fdocs%2Fguide%2F113%2Fmanaging%2Fmonitor_tune%2Fperformance_controls_controlling_socket_use.html&data=04%7C01%7Cnnag%40vmware.com%7Cb3a63185f8f948ce5e1708d88c2ee809%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637413480399258567%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hwVkxp99IM%2FeRWDt39P81GO%2Bq7LD7maQewAKLYqQlj0%3D&reserved=0 [2] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgeode.apache.org%2Fdocs%2Fguide%2F113%2Fmanaging%2Fmonitor_tune%2Fsockets_and_gateways.html&data=04%7C01%7Cnnag%40vmware.com%7Cb3a63185f8f948ce5e1708d88c2ee809%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637413480399268565%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=FOBKgXh1tOj3WDsLZRbBXoufPeaUu4YTKkSDKD81P9A%3D&reserved=0
Re: [PROPOSAL] Change the default value of conserve-sockets to false
The downside of conserve-sockets = false is that you are (essentially) back to a Thread|Socket / Request model (though Geode limits this system resource consumption to a degree by the use of Thread Pools in p2p distribution layer) and thus, you can run out of file descriptors (per newly opened Socket) pretty quickly if you are not careful. conserve-sockets set to true limits the use of finite system resources why risking deadlocks (i.e. A -> B -> C -> A), which is also contingent on ACKS (and the infamous ReplyProcessor21; at least at 1 time, not sure if it is still in play, but probably!). conserve-sockets set to false uses more system resources but avoids deadlocks. If this change is made, I'd minimally make sure to document that users should adjust their (soft & hard) ulimits accordingly, based on use cases, load, etc. Personally, this has caused enough grief in the past (both ways, actually!) that I 'd say this is a major version change. -j From: Nabarun Nag Sent: Wednesday, November 18, 2020 6:09 PM To: dev@geode.apache.org Subject: Re: [PROPOSAL] Change the default value of conserve-sockets to false +1 * As nearly all of the production use-cases need "conserve-sockets" to be set to false, I think we can aim for changing the default value to false for 1.14.0 release. * We can highlight this change in the release notes and emails. Regards, Nabarun From: Udo Kohlmeyer Sent: Wednesday, November 18, 2020 6:00 PM To: dev@geode.apache.org Subject: Re: [PROPOSAL] Change the default value of conserve-sockets to false Hi there Donal, Thank you for raising this. It is not an uncommon request to change the default value of this field. This has been discussed many times in the past. I would LOVE to approve this change, but this would mean that users that don’t set this property might suddenly have this property changed. We are not sure that this would mean for these users. BUT That said, there have been very little (to none) complaints about the product stability when `conserve-sockets=false` are set. +1 - if we are allowed to make this change outside of a major version change. --Udo From: Donal Evans Date: Thursday, November 19, 2020 at 12:04 PM To: dev@geode.apache.org Subject: [PROPOSAL] Change the default value of conserve-sockets to false Hi Geode dev, First, from the docs[1], a brief explanation of the purpose of the conserve-sockets property: "The conserve-sockets setting indicates whether application threads share sockets with other threads or use their own sockets for member communication. This setting has no effect on communication between a server and its clients, but it does control the server’s communication with its peers or a gateway sender’s communication with a gateway receiver." The current default value for the conserve-sockets property is true, which at first glance makes sense, since in an ideal world, existing sockets could be shared between threads and there would be no need to create and destroy new sockets for each process, which can be somewhat resource-intensive. However, in practice, there are several known issues with using the default setting of true. From the docs[1]: "For distributed regions, the put operation, and destroy and invalidate for regions and entries, can all be optimized with conserve-sockets set to false. For partitioned regions, setting conserve-sockets to false can improve general throughput. Note: When you have transactions operating on EMPTY, NORMAL or PARTITION regions, make sure that conserve-sockets is set to false to avoid distributed deadlocks." and[2]: "WAN deployments increase the messaging demands on a Geode system. To avoid hangs related to WAN messaging, always set `conserve-sockets=false` for Geode members that participate in a WAN deployment." Given that it is generally accepted as best practice to set conserve-sockets to false for almost all use cases of Geode beyond the most simple, it would make sense to also change the default value to false, to prevent people having to encounter a problem, search for the solution, then change the setting to what is almost always the "correct" value. I have done some experimenting to see what it would take to make this proposal a reality, and the changes required are very minimal, with only two existing DUnit tests that need to be modified to explicitly set the value of conserve-sockets that were previously relying on the default being true. Any feedback on this proposal would be very welcome, and if the response is positive, I can create a PR with the changes as soon as a decision is reached. Thanks, Donal [1] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgeode.apache.org%2Fdocs%2Fguide%2F113%2Fmanaging%2Fmonitor_tune%2Fperformance_controls_controlling_socket_use.html&data=04%7C01%7Cjblum%40vmware.com%7C87fe2b03a77045e6335408d88c3037b3%7Cb39138ca3
Fixed: apache/geode-native#2803 (develop - 9fdb183)
Build Update for apache/geode-native - Build: #2803 Status: Fixed Duration: 1 hr, 27 mins, and 46 secs Commit: 9fdb183 (develop) Author: Jacob Barrett Message: GEODE-2484: Removes ACE_DLL (#591) Replaces with boost::dll. View the changeset: https://github.com/apache/geode-native/compare/4e241ffe6f6b...9fdb183e146b View the full build log and details: https://travis-ci.com/github/apache/geode-native/builds/202613378?utm_medium=notification&utm_source=email -- You can unsubscribe from build emails from the apache/geode-native repository going to https://travis-ci.com/account/preferences/unsubscribe?repository=16807653&utm_medium=notification&utm_source=email. Or unsubscribe from *all* email updating your settings at https://travis-ci.com/account/preferences/unsubscribe?utm_medium=notification&utm_source=email. Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications.
Re: [DISCUSS] Adding CODEOWNERS to Apache Geode
+1 This will greatly improve the experience for contributors. Instead of an intimidating empty list of reviewers when you submit a PR (and no ability to add reviewers, if you’re not a committer), it will be great to already have at least two reviewers automagically assigned. I have a small concern that initially populating this file via a flurry of PRs may result in a lot of merge conflicts with anyone else that volunteers on the same or an adjacent line. Also, since you _must_ be a committer to be a code owner, is a PR even necessary…would directly committing changes to the feature/introduce-codeowners branch be acceptable? If not, who needs to review and who can merge the PRs against the ‘introduce’ branch? What happens if you are the only owner for an area, can you approve your own PR? Even if the goal is two owners per area, does that mean PRs by either owner cannot be merged if the only other owner is on vacation or otherwise unavailable? Can we submit PRs against the ‘introduce’ branch now and they just won’t be merged before Nov 26, or do we all just need to be patient until this review period has concluded? From: Robert Houghton Date: Wednesday, November 18, 2020 at 2:07 PM To: dev@geode.apache.org Subject: [DISCUSS] Adding CODEOWNERS to Apache Geode Hello Devs. I would like to improve the quality of the pull-request reviews we see for critical parts of the Apache Geode project. In discussions with other committers, a (not the) big hurdle to that is getting the right eyes to look at a given PR. To that end, I propose the adoption of GitHub's CODEOWNERS functionality for the Apache Geode code repository. A discussion-document of this issue has been written up by @upthewaterspout. Thanks Dan! https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FIntroduce%2BCodeowners%2Bfile&data=04%7C01%7Conichols%40vmware.com%7Cdae0b736ba274524699608d88c0e4aa7%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637413340295288351%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=SzfpQ1FIdfeZTs4NJuSiAZRNNkg8isKOz%2FEkSjnhnMg%3D&reserved=0 I have tested the feature with fellow Geode committers @upthewaterspout and @onichols-pivotal, and found it to meet our expectations. Please review the document, and comment or reply to this thread, by 25 November, so we might start the task of nominating and applying for ownership. -Robert Houghton
