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

Conversation

Projects
None yet
2 participants
@pschoenfelder
Contributor

pschoenfelder commented Aug 29, 2018

No description provided.

pschoenfelder added some commits Aug 29, 2018

@pschoenfelder pschoenfelder requested a review from ssalinas Aug 29, 2018

@ssalinas

This comment has been minimized.

Show comment
Hide comment
@ssalinas

ssalinas Aug 29, 2018

Member

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

Member

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.

@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

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?

@pschoenfelder

pschoenfelder Aug 30, 2018

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

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

This comment has been minimized.

Show comment
Hide comment
@ssalinas

ssalinas Sep 10, 2018

Member

🚢

Member

ssalinas commented Sep 10, 2018

🚢

@ssalinas ssalinas merged commit 1c2ec0c into master Sep 10, 2018

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