Possible enhancement: Allow setting request priorities

[vinaysshenoy]

I've been using Volley with an OkHttp stack for a while now, but I've been wanting to switch to a pure OkHttp stack for a while now(streaming response bodies, interceptors, multipart requests, ease of integration are a few of the reasons).

One of the reasons I have held of on this change is because Volley has one feature that OkHttp doesn't have yet: support for prioritizing requests. Would such a feature be acceptable as a Pull Request if I implement it?

[swankjesse]

This is a tricky feature to do generally. Is policy fixed or pluggable? Does the default policy starve low priority requests? When is priority enforced? Do we short circuit low priority calls that would benefit from the cache? Is the priority shared with the HTTP/2 server?

I'm reluctant to solve this partially, and solving it generally is a lot of work. I'd prefer to punt on this for now.

[vinaysshenoy]

AH, got it. I didn't think of that.

Anyway, this is something I need and I feel it would be a good addition to
the library. I'll draft up a set of reqs for the feature(considering
whatever you've mentioned) and update this issue. If you're okay with them,
I can implement this and submit a PR whenever it's ready.

On Thu, Feb 5, 2015 at 2:31 AM, Jesse Wilson notifications@github.com
wrote:

This is a tricky feature to do generally. Is policy fixed or pluggable?
Does the default policy starve low priority requests? When is priority
enforced? Do we short circuit low priority calls that would benefit from
the cache? Is the priority shared with the HTTP/2 server?

I'm reluctant to solve this partially, and solving it generally is a lot
of work. I'd prefer to punt on this for now.

—
Reply to this email directly or view it on GitHub
#1361 (comment).

Vinay S Shenoy
Android App Developer at Flipkart.com
+91-9538122356 | vinaysshenoy@gmail.com
LinkedIn : http://in.linkedin.com/in/vinaysshenoy

[swankjesse]

Cool. I think we'll probably hold on priorities until we also make the backend async for HTTP/2. When things are async we suddenly get better control over which order tasks are completed.

[ansman]

@swankjesse Is there a timeline for when the backend will be async?

[swankjesse]

No timeline.

[iAviatorJose]

@swankjesse is this feature implemented ???

[swankjesse]

Not implemented.

[alexanderkjeldaas]

I don't quite understand the worries cited above. Couldn't the priority simply be forwarded to the HTTP/2 server and be interpreted by the server?

How the server interprets priorities is given by the HTTP/2 spec (they can be ignored), and whether requests are starved etc. is out of scope for the library.

The tcp socket buffer size is the only thing the client needs to have control of.

[swankjesse]

OkHttp has a queue of pending requests not yet transmitted to the server. A good priority mechanism should probably influence the queue.

[6bangs]

For our use case, we only wanted new requests to be prioritized over old requests, specifically with regard to the ready deque (last in, first out). The easiest way to accomplish that was to change the add call in the Dispatcher to a push (specifically this line).

This seems to be a more sensible default for many applications, if a real prioritization feature isn't on the roadmap for the foreseeable future.

[swankjesse]

Duplicate of #404