A little background is necessary. In order for a job to be executed clients must first register a job factory function which returns a job instance in the form of an rx.Completable. That Completable contains the actual job execution code. Subscriptions to the Completable should happen on the I/O RxJava scheduler. I have seen in testing both with the compression job and with some dummy jobs I have been using for testing that subscriptions run on the computation scheduler.
There are a couple reasons that job subscriptions should happen on the I/O scheduler and more importantly that they do not run on the computation scheduler. First, the computation scheduler thread pool size is fixed to the number of cores. This would cap the number of jobs that could execute in parallel and for jobs that are completely async like the compression job this would be quite limiting. The I/O scheduler will create additional threads as necessary.
The second and more important reason is that the computation scheduler is not intended for blocking or long running operations. The job scheduler has no way of knowing whether or not a job is going to be async. A dummy job that I have been using for testing would block for either two or seven minutes. Subscriptions to the job were happening on the computation scheduler. This was causing problems where it seemed like computation scheduler threads were getting blocked, almost indefinitely at times. It was even causing the compression job to hang.