Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add email unsubscriptions #1843

Merged
merged 4 commits into from Sep 10, 2018
Merged

Add email unsubscriptions #1843

merged 4 commits into from Sep 10, 2018

Conversation

@pschoenfelder
Copy link
Contributor

@pschoenfelder pschoenfelder commented Aug 29, 2018

No description provided.

@pschoenfelder pschoenfelder requested a review from ssalinas Aug 29, 2018
@ssalinas
Copy link
Member

@ssalinas ssalinas commented Aug 29, 2018

storage/api portions look fine here. Only potential thing I see is that, since Singularity sends a lot of emails, we will make quite a few getChildren calls fetching that list. Can we maybe cache it for some amount of time? Even caching for 5 minutes or so would save a ton of calls


public void addToBlacklist(String email) {
create(getEmailPath(email));
cache.invalidate(BLACKLIST_ROOT);

This comment has been minimized.

@ssalinas

ssalinas Aug 30, 2018
Member

last note here... depending what singularity service instance is hit this may or may not do any good. If the leader is hit with the api call, then it will be effective immediately. If a non-leader instance is hit, the leader will still be waiting until its cache expires. If we want this to be 100% consistent on the leader, we'd want to add the maybeProxyToLeader pattern we use in other resources to the NotificationsResource.

This comment has been minimized.

@pschoenfelder

pschoenfelder Aug 30, 2018
Author Contributor

Good point. But how does hitting the leader ensure synchronization across all instances if each has it's own cache? Wouldn't we need to invalidate the cache on every single instance?

This comment has been minimized.

@ssalinas

ssalinas Aug 30, 2018
Member

It doesn't ensure synchronization everywhere, but it ensures that the one actually doing the email sending is up to date

@ssalinas
Copy link
Member

@ssalinas ssalinas commented Sep 10, 2018

🚢

@ssalinas ssalinas merged commit 1c2ec0c into master Sep 10, 2018
0 of 2 checks passed
0 of 2 checks passed
continuous-integration/travis-ci/pr The Travis CI build could not complete due to an error
Details
continuous-integration/travis-ci/push The Travis CI build could not complete due to an error
Details
@ssalinas ssalinas deleted the email-unsub branch Sep 10, 2018
@ssalinas ssalinas added this to the 0.21.0 milestone Sep 26, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

2 participants
You can’t perform that action at this time.