-
Notifications
You must be signed in to change notification settings - Fork 1
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
William/v2 server #42
Conversation
94e0037
to
1256164
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Copied the comments for convenience while giving another review.
) | ||
} catch (error) { | ||
if (asMaybeConflictError(error) == null) throw error | ||
await addEvent(connection, event, new Date(created.valueOf() + 1)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have been using this strategy in the other servers. It works quite well.
The basic idea is that at least one thread will always be making progress. If thread A, B, and C are all trying to add events at the same time, one will succeed and the other two will fail. That progress means we now we only have 2 events to add. So, the two remaining threads loop and and another one succeeds. Now we have only one event waiting, which will succeed on the third go-around. Even if more events arrive in the meantime, progress will continue happening.
This will only fail if we have more than 1000 events arrive per second. I am pretty sure CouchDB / CPU usage will die first.
a6c6d93
to
b452d0a
Compare
We are going to shut down the v1 routes, but we need the loginId list for security.
460c33e
to
a9dff1f
Compare
This replaces #40 and #36. It provides an actual implementation.