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

Setting a request's priority #820

Closed
mrmaffen opened this Issue Apr 22, 2015 · 2 comments

Comments

2 participants
@mrmaffen
Copy link

mrmaffen commented Apr 22, 2015

Hey guys,
first of all: Great work so far! Keep it up :)

Here's my problem:
In my app I want to run some long syncing operations in the background while still being able to use Retrofit to fetch other data from my API. Currently the syncing operations block Retrofit completely for (in some cases) over 60 seconds which means that no other data can be fetched in the meantime. This is obviously not acceptable wrt UX.
I couldn't however find an easy way to set a request's priority with Retrofit. I'd love to see a feature like this to be implemented. If I could simply annotate the type of request in my API interface with some priority value, that would be great.

Thanks!

@mrmaffen

This comment has been minimized.

Copy link

mrmaffen commented Apr 22, 2015

Here's my workaround/solution:

Executor httpExecutor = Executors.newCachedThreadPool(new ThreadFactory() {
    @Override
    public Thread newThread(final Runnable r) {
        return new Thread(new Runnable() {
            @Override
            public void run() {
                android.os.Process.setThreadPriority(THREAD_PRIORITY_LOWEST);
                r.run();
            }
        }, "Retrofit-Idle-Background");
    }
});
restAdapter = new RestAdapter.Builder()
        .setExecutors(httpExecutor, new MainThreadExecutor())
        .build();
mImplementation = restAdapter.create(API.class);

I can now use mImplementation for my sync operations. Even though this is obviously not an optimal solution, since I use 2 ThreadPools and prioritize the Thread instead of the actual Runnable, it still works fine as a temporary workaround it seems.

Note: I'm using 1.8.0

@JakeWharton

This comment has been minimized.

Copy link
Collaborator

JakeWharton commented May 6, 2015

Currently the syncing operations block Retrofit completely for (in some cases) over 60 seconds which means that no other data can be fetched in the meantime.

Are you sure this happens? Retrofit uses an unbounded pool of threads so we'll happily execute multiple request concurrently.

Definitely looking for more info regarding the above, but I'm going to close this issue for now because:

Retrofit v2 is pushing the threading model down into the HTTP client rather than having its own. This will increase throughput as well as allow the HTTP client to do smarter things such as limiting per-server connections to a specified amount or multiplexing requests over a single connection with HTTP/2.

@JakeWharton JakeWharton closed this May 6, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment