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

Workload replay threads should share a single DelayQueue #16

Closed
xkrogen opened this issue Mar 28, 2018 · 0 comments
Closed

Workload replay threads should share a single DelayQueue #16

xkrogen opened this issue Mar 28, 2018 · 0 comments

Comments

@xkrogen
Copy link
Collaborator

xkrogen commented Mar 28, 2018

Currently, within a single workload replay mapper, numerous threads are started to replay back commands. Commands are partitioned by their source path, and then directed to a thread corresponding to their partition. This results in issues with, for example, skewed paths in which single threads get backed up and result in commands being executed far later than initially intended. Instead, we should simply let all of the threads share a single DelayQueue to spread the load among all of them.

This has the disadvantage that some operations occurring on the same source path may occur out of order, but this has not proved to be an issue in our experience.

xkrogen added a commit to xkrogen/dynamometer that referenced this issue Mar 28, 2018
…ared queue between all threads in a single workload mapper.
xkrogen added a commit to xkrogen/dynamometer that referenced this issue Mar 28, 2018
…ared queue between all threads in a single workload mapper.
@xkrogen xkrogen closed this as completed in 8f73360 Apr 5, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant