IntentService and Threadpool

Question

I have an IntentService that needs to act as a manager and create tasks in the queue (Runnable) that are passed to ThreadPool.

Im a little confused in the IntentService lifecycle:

The protected abstract void onHandleIntent (Intent intent) method is already executed in a separate thread. In onHandleIntent I will create a new instance of Runnable and send it to ThreadPool. My service looks like this:

  public class SyncService extends IntentService { private final ThreadPoolExecutor threadPool; public SyncService() { super("SyncService"); BlockingQueue<Runnable> queue = new LinkedBlockingQueue<Runnable>(); threadPool = new ThreadPoolExecutor(1, 1, 20, TimeUnit.SECONDS, queue); } @Override public void onCreate() { super.onCreate(); EventBus.getInstance().register(this); } @Override public void onDestroy() { super.onDestroy(); EventBus.getInstance().unregister(this); } @Override protected void onHandleIntent(Intent intent) { if (intent.getAction().equals("sync")){ threadPool.submit(new SyncRunnable()); }else if(intent.getAction().equals("delete")){ threadPool.submit(new DeleteRunnable()); } else if(intent.getAction().equals("register")){ threadPool.submit(new RegisterRunnable()) } } } 

My questions:

• Is it possible to use ThreadPool in an IntentService?
• If I use ThreadPool, than will the IntentService be destroyed if Threadpool no longer has Runnables to execute or the queue, right?
• Is the IntentService what I want to achieve, and should I just execute my (long-term) Runnable code in onHandleIntent() , because this alread method works on the IntentService Thread Worker? If so, is there a queue limit for, since onHandleIntent () can run for up to 30 seconds before finishing and processing the next intent.

Answer 1

Is it possible to use ThreadPool in an IntentService?

Not really. IntentService is already a single-threaded (serial) version of what you are trying to achieve. I would get directly from Service .

If I use ThreadPool, than will the IntentService be destroyed if Threadpool no longer has Runnables to execute or the queue, right?

No. An IntentService can go into ruined state as soon as you return from onHandleIntent - ie immediately, because threadPool.submit does not block. In source, it calls stopSelf(int) with the initial value obtained when the service started.

 private final class ServiceHandler extends Handler { public ServiceHandler(Looper looper) { super(looper); } @Override public void handleMessage(Message msg) { onHandleIntent((Intent)msg.obj); stopSelf(msg.arg1); } } 

A Service goes into ruined state if you call stopSelf with the last (highest) startId. It will continue to work if a new start is in line.

If the service goes into a corrupted state, it will not destroy the thread pool, because it does not know about it. The problem is that Android now thinks your service is dead and it will no longer be considered a reason to save your application. A service working against a broken state is just a way of telling Android that something is happening and you don’t want to be destroyed.

If you want to do this correctly, you need to keep the state of the service in sync with what is actually happening.

Is the IntentService what I want to achieve, and should I just execute my (long) Runnable executable code on onHandleIntent () because this alread method works in the IntentService workflow?

If you are satisfied with the single-threaded serial version, yes. This is what onHandleIntent does for you.

If so, is there a queue limit for the intent since onHandleIntent () can run for up to 30 seconds before completing and processing the next intent.

There is no limit (this is, as far as I can tell, a linked list). But there is also nothing that will prevent you from creating more tasks than it can handle, which will ultimately lead to some overflow.