1.15.0 release status update
After cutting the support/1.15 branch a few weeks ago, Jira [1] shows we are down to 3 blockers. Great work, keep those fixes (and bug reports) coming! Information about upcoming releases [2] and tips for backporting [3] can now be found in the wiki. PSA: When using a search engine to quickly locate Geode wiki topics, check the url: * cwiki.apache.org/confluence/display/GEODE is the official URL of the Geode wiki. * www.cwiki.us/display/GEODE is NOT authorized or maintained by the ASF and is several years out-of-date. Thanks, -Geode 1.15.0 Release Manager [1] https://issues.apache.org/jira/issues/?jql=project%3DGEODE%20AND%20(labels%3Dblocks-1.15.0%E2%80%8B)%20AND%20(fixVersion%20!%3D%20%221.15.0%22%20or%20fixVersion%20is%20empty%20or%20not%20status%20in(Resolved%2CClosed))%20AND%20resolution%20is%20empty [2] https://cwiki.apache.org/confluence/display/GEODE/Release+Schedule [3] https://cwiki.apache.org/confluence/display/GEODE/Backporting+Tips
Re: [DRAFT] Apache Geode Board report due by Wed Feb 9th
As, there are no more feedback on this report I am submitting this report to the board. Thank you all. Regards Nabarun From: Nabarun Nag Sent: Friday, February 4, 2022 3:52 PM To: dev@geode.apache.org Subject: Re: [DRAFT] Apache Geode Board report due by Wed Feb 9th Thank you all for the valuable feedback, below is the final draft, please do let me know if this is anything more to add. > ## Description: > The mission of Apache Geode is the creation and maintenance of software > related > to a data management platform that provides real-time, consistent access to > data-intensive applications throughout widely distributed cloud > architectures. > > ## Issues: > There are no Board-level issues at this time. > > ## Membership Data: > Apache Geode was founded 2016-11-15 (5 years ago) > There are currently 115 committers and 54 PMC members in this project. > The Committer-to-PMC ratio is roughly 2:1. > > Community changes, past quarter: > - No new PMC members. Last addition was Donal Evans on 2021-03-22. > - No new committers. Last addition was Alberto Bustamante on 2021-05-13. > > ## Project Activity: > We issued 9 releases this quarter, all do which include an updated Log4j2 version > to handle the remote code execution CVE. > Apache Geode Kafka Connector 1.1.0 was also released > this quarter. > We have also started the effort to remove the use of deprecated components > in the project. > > > Recent Releases of Apache Geode: > > - 1.14.3 was released on 2022-01-25 > > - 1.13.7 was released on 2022-01-22 > > - 1.12.8 was released on 2022-01-13 > > - 1.12.7 was released on 2021-12-17 > > - 1.13.6 was released on 2021-12-17 > > - 1.14.2 was released on 2021-12-17 > > - 1.12.6 was released on 2021-12-11 > > - 1.13.5 was released on 2021-12-11 > > - 1.14.1 was released on 2021-12-11 > > > Work on releasing 1.15.0 is progressing as planned. > > Apache Geode Kafka Connector 1.1.0 was released on 2022-01-18. > > ## Community Health: > - Continuing our monthly video conferences. > - Addition of Kafka Connector project to grow the community. > - Mailing lists are seeing the usual amount of traffic involving > discussions > related to improving performance, operation protocols, etc. From: Dan Smith Sent: Friday, February 4, 2022 3:20 PM To: dev@geode.apache.org Subject: Re: [DRAFT] Apache Geode Board report due by Wed Feb 9th Sounds good. BTW, I don't mean to discount all the hard work folks did getting these patches out quickly. Thanks again for everyone who helped with that effort! -Dan From: Owen Nichols Sent: Friday, February 4, 2022 2:52 PM To: dev@geode.apache.org Subject: Re: [DRAFT] Apache Geode Board report due by Wed Feb 9th That's a much better way to put it, Mark. Thanks! On 2/4/22, 2:50 PM, "Mark Bretl" wrote: I agree with Dan here that bragging about 'one of the quickest' is not needed, but noting we are up-to-date with Log4J patches and have documentation for mitigation might be a better approach. My $.02 --Mark On Fri, Feb 4, 2022 at 11:34 AM Dan Smith wrote: > Counting the kafka connector I'm not sure bragging about CVE patching > speed is justified, but otherwise looks good to me! > > -Dan > > From: Nabarun Nag > Sent: Tuesday, February 1, 2022 2:25 PM > To: dev@geode.apache.org > Subject: Re: [DRAFT] Apache Geode Board report due by Wed Feb 9th > > Thank you for the feedback, please find the new draft with the added > review comments. > > ## Project Activity: > We issued 9 releases this quarter which include an updated Log4j2 version > to handle the remote code execution CVE. The project had one of the > quickest turnaround times from the Log4j2 CVE disclosure to the patch > releases with the fix. Apache Geode Kafka Connector 1.1.0 was also released > this quarter. > We have also started the effort to remove the use of deprecated components > in the project. > > > Recent Releases of Apache Geode: > > - 1.14.3 was released on 2022-01-25 > > - 1.13.7 was released on 2022-01-22 > > - 1.12.8 was released on 2022-01-13 > > - 1.12.7 was released on 2022-12-17 > > - 1.13.6 was released on 2021-12-17 > > - 1.14.2 was released on 2021-12-17 > > - 1.12.6 was released on 2021-12-11 > > - 1.13.5 was released on 2021-12-11 > > - 1.14.1 was released on 2021-12-11 > > > > From: Owen Nichols > Sent: Tuesday, February 1, 2022 12:39 PM > To: dev@geode.apache.org > Subject: Re: [DRAFT] Apache Geode Board report due by Wed Feb 9th > > 1.12.8 seems to be missing from the list of releases. Also consider > bragging about Geode’s turnaround time from CvE disclosure to
Odg: Creating index failed
Hi Anil, I agree that it can happen that two threads try to create the index with the same name with different index expressions concurrently. This distributed lock will help to avoid this issue, but the same test will fail. The first issue is when we have the above case it will create the first index, but the second(the same name and different expression) will be not created but the command is successful. The second issue(these tests which are failing on PR) is that Geode expects that if run the same command again it will fail as there is already created index with the same name. With ignoring exceptions it will pass but shouldn't. So, with a distributed lock we can avoid the issue you mentioned but still has other issues. BR, Mario Šalje: Anilkumar Gingade Poslano: 3. veljače 2022. 16:46 Prima: dev@geode.apache.org Predmet: Re: Creating index failed The other problem which exists is; the case where two threads tries to create index with the same name with different index expression concurrently. I assume there are ways this could happen. One solution to address overall issue with index creation on partitioned region is by taking a distributed lock with the index name. When index creation request comes, it first acquires a distributed lock with the index name; any additional index creation with that name will be blocked till the previous index is created with the same name; during this time if the index creation comes through local or remote the exception can be ignored. As there is only one index creation will be in progress for the same request. -Anil. On 2/3/22, 4:41 AM, "Mario Kevo" wrote: Hi devs, After implementing ignoring exception some tests failed as we allowed now to pass command again (although it does nothing as the same index is already created by execution before). https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F7195data=04%7C01%7Cagingade%40vmware.com%7C5c8bc7454b9044a05b1308d9e71275dd%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637794888745101984%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=wUnq5WuzXrRnpeq%2FM8Ah1vF3TL8tETKxd%2B35v%2FXUMLg%3Dreserved=0 There is a summary of how it works by now. When we are creating an index on a partitioned region, the locator sends to all members to create an index on all data it contains. The partitioned region is specific as it is normal that you want to index all data which are distributed on all members. That leads to every member will try to create it locally and send index create requests to all members on that site. All members will check if there is an already created index or index creating is in progress and wait for it. In case a remotely originated request comes but there is already created index it will respond with Index and send an acknowledgment to the request sender side. In case it is not created already it will create an index on that member and then respond to the request sender side. This behavior is okay if we are using a small number of the server or using the --member option while creating indexes(which has no sense to use on the partitioned region as already described down in the mail thread). The problem is when we are using a larger num of the servers(8 or more) or just with debugging on. It will slow down the whole process and then can happen that on some of the servers remotely originated create index request comes before locally request. In that case, a remotely originated request will see that there is no index with that name and will create a new one. But the problem happens after that when a local request comes and there is already created index it will think that it is from some execution before and throw IndexNameConflictException. https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fblob%2Fdevelop%2Fgeode-core%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%2Fgeode%2Finternal%2Fcache%2FPartitionedRegion.java%23L8377data=04%7C01%7Cagingade%40vmware.com%7C5c8bc7454b9044a05b1308d9e71275dd%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637794888745101984%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=0lbpsVQ63FjPaRBvhqmhmAsYp8V0gH3BokmbASBC9hg%3Dreserved=0 The create index command will fail(despite of that the index is created on all data, some with local requests ad some with remotely originated requests). There are two problems with this implementation: 1. The user doesn't know that the index is created and will try to create it again but then it will fail on all servers. 2. The cluster config is updated after the command is finished successfully, which is correct as we cannot update the cluster config before anything is done. The user can use indexes despite that command failed, but
Next Geode community meeting: 17th of February
Hi all, We'd like to propose to have our next Geode community meeting on February 17th to present and discuss the following topic: "Thread and server health monitoring: how to kick out slow/sick members and the like" Details here: https://cwiki.apache.org/confluence/display/GEODE/Apache+Geode+Community+Meeting+Notes Please, let me know if there is any inconvenience with the date proposed. Otherwise, see you there! Alberto
