Okhttp: Stream priority: expose it & honor it

[swankjesse]

At the moment we don't honor stream priority, and we don't allow app developers to prioritize their streams.

We should.

[swankjesse]

https://speakerdeck.com/summerwind/2-prioritization

[shanghuibo]

Is there any progress in this issue?

[JakeWharton]

No

On Mon, Jun 6, 2016 at 10:29 PM shanghuibo [email protected] wrote:

Is there any progress in this issue?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/square/okhttp/issues/404#issuecomment-224149225, or mute
the thread
https://github.com/notifications/unsubscribe/AAEEEcc90-JqoPgEeT6VF9VhdjqZ4tvWks5qJNeBgaJpZM4BXgco
.

[HyperSimon]

我是来看jake大神的

[swankjesse]

Dispatcher Proposal

I propose a prioritization scheme for use in processing Dispatcher’s backlog of async calls. Each call has a priority between 0.0 (lowest priority) and 1.0 (highest priority). The default priority is 0.1.

We assign each queued call a priority score using the following function:

val BASE_MILLIS = 1000

fun Call.priorityScore() = (BASE_MILLIS + timeInQueueMillis()) * priority

Suppose we enqueue 3 calls:

A enqueued at time=0, priority=1.0
B enqueued at time=100, priority=0.5
C enqueued at time=200, priority=0.0

At time 200 we compute the priorities as A=1200, B=550, C=0.
At time 1000 we compute the priorities as A=2000, B=950, C=0.

Higher priority requests “age faster” than lower-priority requests. Any request with a non-zero priority eventually has been queued long enough to be preferred over higher-priority requests. Another example:

D enqueued at time=0, priority=0.1
E enqueued at time=10,000, priority=1.0
At time 10,000 we compute the priority of D=1100 ((1000+10,000) x 0.1), and E=1000 ((1000+0) x 1.0), so D is processed before E.
But if we hadn’t checked until time 11,000, then D=1200 and E=2000 so E is preferred.

Requests of priority 0.0 are allowed to starve and are only processed if requests of higher priority are not enqueued.

[biaomingzhong]

Dispatcher Proposal

I propose a prioritization scheme for use in processing Dispatcher’s backlog of async calls. Each call has a priority between 0.0 (lowest priority) and 1.0 (highest priority). The default priority is 0.1.

We assign each queued call a priority score using the following function:

val BASE_MILLIS = 1000

fun Call.priorityScore() = (BASE_MILLIS + timeInQueueMillis()) * priority

Suppose we enqueue 3 calls:

A enqueued at time=0, priority=1.0
B enqueued at time=100, priority=0.5
C enqueued at time=200, priority=0.0

At time 200 we compute the priorities as A=1200, B=550, C=0.
At time 1000 we compute the priorities as A=2000, B=950, C=0.

Higher priority requests “age faster” than lower-priority requests. Any request with a non-zero priority eventually has been queued long enough to be preferred over higher-priority requests. Another example:

D enqueued at time=0, priority=0.1
E enqueued at time=10,000, priority=1.0
At time 10,000 we compute the priority of D=1100 ((1000+10,000) x 0.1), and E=1000 ((1000+0) x 1.0), so D is processed before E.
But if we hadn’t checked until time 11,000, then D=1200 and E=2000 so E is preferred.

Requests of priority 0.0 are allowed to starve and are only processed if requests of higher priority are not enqueued.

Current dispatcher has readyAsyncCalls and runningAsyncCalls. How to implement this scheme?