Мне тоже кажется что проблема накручена. Не настаиваю, но если обьясните подробно задачу, может и найдем сообща нормальное решение. Пока извините, это похоже на сумбур и велосипед

А почему такая архитектура? Вообще держать потоки невыгодно и немасштабируемо. Я так понимаю что вся соль в "Часть этого массива остается в потоке" Почему не сохранить его промежуточно на диск например, и когда придет ответ запустить Runnable с ссылкой на место на диске где сохранена эта часть?
В целом я бы двигался к отделению бизнес-логики от утилитной(в вашем случае потоки, шедулинг, очереди и тд). Какие-то соображения по секьюрити или видимости мб? Я бы строил систему примерно так -
1) Есть три типа тасков - a) вычитать файл и сохранить промежуточные данные, из остальных данных составить message и положить его в queue b) Взять таск из queue отослать его на сервер, подождать ответ, сделать из него месседж и положить во вторую queue c) взять месседж из второй queue, вычитать первую часть массива и завершить весь цикл. Можно таски b и c объединить, но так как b блокирующий, это не есть гуд, я бы выделил для них различные пулы.
2) Есть две очереди(возможно 3, если файлы добавляются динамически)
3) Есть три пула, для каждого типа задачи.
4) Есть два коорднатора, Мониторят каждый свою queue и при поступлении месседжей, конструируют Runnable и посылают в пул


Это если смотреть низкоуровнево.
В принципе задача хорошо ложится на акторную модель, потому можно посмотреть также на Akka, если видите много возни с вариантом выше.