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

OrderedScheduler#chooseThread(key) handle null key #1372

Closed
wants to merge 1 commit into from

Conversation

sijie
Copy link
Member

@sijie sijie commented Apr 27, 2018

Descriptions of the changes in this PR:

Motivation

It is more convenient if OrderedScheduler#chooseThread(key) can handle null key. so the applications who is using #chooseThread don't need to worry which method to choose - chooseThread() vs chooseThread(key).

Solution

in chooseThread(key), fallback to randomly pickup a thread if key is null.

@sijie
Copy link
Member Author

sijie commented Apr 28, 2018

retest this please

Copy link
Member

@jiazhai jiazhai left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1

@sijie
Copy link
Member Author

sijie commented Apr 30, 2018

retest this please

return threads[rand.nextInt(threads.length)];
} else {
return threads[MathUtils.signSafeMod(orderingKey.hashCode(), threads.length)];
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks fine, but wondering what is the usecase of this? I worry it might mask bugs as ordered safe executor is an absolute must to protect the correctness (wherever it is needed). So callers need to know what they are doing.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it is for convenience, so in the caller, I don't have to do if (orderKey != null) chooseThread(orderKey); else chooseThread(..). I can have a separate util function to do that, but I feel it is better to do it at the executor level.

@sijie
Copy link
Member Author

sijie commented Apr 30, 2018

retest this please

@sijie sijie self-assigned this Apr 30, 2018
@sijie sijie closed this in 1f0f92c Apr 30, 2018
sijie added a commit that referenced this pull request Apr 30, 2018
Descriptions of the changes in this PR:

*Motivation*

It is more convenient if OrderedScheduler#chooseThread(key) can handle null key. so the applications who is using #chooseThread don't need to worry which method to choose - `chooseThread()` vs `chooseThread(key)`.

*Solution*

in `chooseThread(key)`, fallback to randomly pickup a thread if key is null.

Author: Sijie Guo <sijie@apache.org>

Reviewers: Enrico Olivelli <eolivelli@gmail.com>, Jia Zhai <None>

This closes #1372 from sijie/order_scheduler_null_key

(cherry picked from commit 1f0f92c)
Signed-off-by: Sijie Guo <sijie@apache.org>
@sijie sijie deleted the order_scheduler_null_key branch July 16, 2018 02:47
reddycharan pushed a commit to reddycharan/bookkeeper that referenced this pull request Oct 17, 2018
Descriptions of the changes in this PR:

*Motivation*

It is more convenient if OrderedScheduler#chooseThread(key) can handle null key. so the applications who is using #chooseThread don't need to worry which method to choose - `chooseThread()` vs `chooseThread(key)`.

*Solution*

in `chooseThread(key)`, fallback to randomly pickup a thread if key is null.

Author: Sijie Guo <sijie@apache.org>

Reviewers: Enrico Olivelli <eolivelli@gmail.com>, Jia Zhai <None>

This closes apache#1372 from sijie/order_scheduler_null_key

(cherry picked from commit 1f0f92c)
Signed-off-by: Sijie Guo <sijie@apache.org>
Signed-off-by: JV Jujjuri <vjujjuri@salesforce.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants