I agree with Rod's sentiments. I'd be happy to review any PRs that you submit. It would be fantastic to breath some life back into the project.
In terms of multi region ES, this is not possible within ES itself since ES does not support it natively. Instead, the indexing module uses a queueing mechanism of Entity Write -> SNS -> SQS. This allows us to configure an SNS topic to publish indexing events, then these events are delivered to each region's own SQS queue. The listeners read the entity id and version, then index the entity in it's own region's ES cluster. Cassandra internally is multi region. When an entity is written to Cass, it will be replicated to the other regions automatically assuming your ring is set up correctly. In the event an async replication were to fail, the indexing events have a fallback consistency read pattern to force read repair from another region. The indexing attempts read at LOCAL_QUORUM, if this fails, it then falls back to QUORUM to try to get an up to date record from the region that contains the record. Todd On Wed, May 23, 2018 at 6:49 PM Rod Simpson <[email protected]> wrote: > This sounds great. I believe all documentation is either on the website ( > usergrid.org), or amongst the code itself (in the form of comments and > readme files). > > Can you clarify what you mean by Cassandra Multi-site deployments? I assume > you are referring to a multi-region cluster. This should work fine. You > can co-locate tomcat servers in the same regions as the Cassandra rings and > use regional DNS to route calls to them. There was an effort to > incorporate Elasticsearch clusters in as well, and I am not sure what the > status of that is or if Elasticsearch can be deployed multi-region (it > couldn’t be several years ago). Probably Todd should correct me here if I > am giving misinformation. > > If you want to see the Usergrid project continue, then please submit pull > requests as soon as possible. We still have to follow the Apache way. > This means that interested parties who contribute code can be considered > for committer status and eventually those committers can take leadership > roles in the project. In this way, the project could eventually turned > over to a new management, as it were. > > I believe that there are enough project members that pull requests could > get reviewed and accepted (i’m willing to review and ack PRs). > > Others can chime in if they feel differently. > > Rod > > > -- > Rod Simpson > > On May 23, 2018 at 2:39:42 PM, Ed Anuff ([email protected]) wrote: > > bump! > > On Tue, May 15, 2018 at 9:49 AM, Fouad Omri <[email protected]> > wrote: > > > Hello Dave, > > > > we are planning to extend the usergrid platform: > > 1) deployment on Kubernetes using Helm charts > > 2) Cassandra Multi-Site Deployment and upgrade of Cassandra and > > elasticseach versions > > 3) Enhance Notification using Firebase Cloud Messaging > > 4) Upgrade to Spring boot and Spring Cloud > > > > Can you please share with us the architecture documentation of usergrid, > > especially whether some work has been done in the area of Cassandra > > Multi-Site deployment, and some best practices? > > > > We don't want the usergrid project to disappear, and we want to start > > contributing back to the community ASAP > > > > Many thanks for your support, > > Fouad > > > > On Fri, May 11, 2018 at 1:38 PM, Dave <[email protected]> wrote: > > > > > Usergrid friends, > > > > > > We had a conversation about this on the private mailing list, but we > need > > > to discuss here in the open. > > > > > > It seems that, while we do have a good number of committers and PMC > > > members, we do not have any developers actively working on the project > or > > > any volunteers willing manage a release. We have not added a new > > committer > > > or made a release in over two years. > > > > > > If the project is to continue, then we need new folks to step up and > > start > > > contributing. Otherwise we should retire it and move the project to the > > > attic via the process outlined here: https://attic.apache.org/ > > process.html > > > > > > Thanks, > > > Dave > > > > > > > > > > > -- > > -------- > > > > *Dr.- Ing. Fouad N. Omri* > > > > > > Predapp - Predictive Applications > > Im Neuenheimer Feld 518 > > 69120, Heidelberg > > Germany > > > > Tel G: +49 176 79 85 22 72 <+49%20176%2079852272> > > > > *Optimized Data-driven Business decisions based on artificial > intelligence > > and self-learning algorithms* > > > > Notice: This transmittal and/or attachments may be privileged or > > confidential. It is intended solely for the addressee named above. Any > > review, dissemination, or copying is strictly prohibited. If you received > > this transmittal in error, please notify us immediately by reply and > > immediately delete this message and all its attachments. Thank you. > > >
