You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
xkrogen
added a commit
to xkrogen/dynamometer
that referenced
this issue
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.
The text was updated successfully, but these errors were encountered: