Petro123TivakПока не понял о чем ты
я о том что асинхронный сервлет для другой задачи. Не твоей.
Там асинхронный подпроцесс (твой долгий) потом сам отвечает клиенту.
Так понятно?
использование асинхронности и время обработки на сервере не связаны напрямую.
Вопрос в том, сколько коннектов хочется держать одновременно и сколько потоков понадобится для их обработки.

Итак, рассказываю, что в итоге сделал
с servlet 3.1 так и не удалось найти нормального решения. Все решения сводились к тому, что приходится запускать обработку в отдельном потоке, а поток контейнера лочить. что само по себе не правильно.
В идеале надо было решение, чтобы запускать обработку в отдельном потоке, а при готовности или таймауте инициировать событие записи. но как это правильно сделать я не нашел.

в итоге откатился к servlet 3.0
проверил работу встроенного механизма timeout на tomcat 9. по моим тестам они ничего не гарантирует, даже приблизительно, при цифрах в 100мс.
Поэтому сделал таймаут при помощи отложенного запуска потока + написал простенький контроль состояния асинхронного контекста.
посмотрим как это себя покажет в будущем.

Жаль что на текущем этапе пришлось отказаться от неблокирующего io

Petro123Tivak,
вывод такой, что задача у тебя странная. А не сервлеты.
Tivakс servlet 3.1 так и не удалось найти нормального решения. Все решения сводились к тому, что приходится запускать обработку в отдельном потоке, а поток контейнера лочить. что само по себе не правильно.
В идеале надо было решение, чтобы запускать обработку в отдельном потоке, а при готовности или таймауте инициировать событие записи. но как это правильно сделать я не нашел.
представь себе, что сервлет - это обычный поток А
Значит при старте обычного потока А тебе надо через секундомер(Б) вырубить поток А и вместо него отправить ответ.
Т.е. лезть в контейнер.
Мыши пищали, но ели кактус (с)

вот не согласен. мне не надо никуда лезть в контейнер. просто или я успел обработать запрос и отдать ответ или не успел обработать запрос и отдал стандартный ответ. не вижу тут вылезание из контейнеров.
почему хотелось использовать именно не блокирующее io? а чтобы не блокировать потоки, в случае проблем при передаче (например).
опять же в идеале потом задача сведется к ожиданию ответов из внешних систем (из бд например или других сервисов). соответственно нам для этого всего не нужен на каждый запрос отдельный поток.
поток нужен только для приема сообщения, формирования запроса к бд, обработки ответа от бд и ответа внешнему клиенту. нет никаких ожиданий.
Но на данный момент это все мечты. К которым надеюсь вернемся в будущем)))

Petro123Tivak,
Давай конкретнее.
Выше было про поток А и поток Б.
Это понятно?

В общих чертах так и получилось.
servlet стартует поток А и отложено стартует поток Б.
если в момент старта потока Б поток А отработал и отправил ответ, то все хорошо, он ничего не делает.
если же поток А все еще работает, то поток Б отправляет ответ клиенту.
Я тут нигде в недра контейнера не залез )))

Тему можно закрывать )
Решение было найдено и реализовано.
если найду как правильно реализовать задуманное на servlet 3.1 то обязательно отпишусь в этой теме.

Всем спасибо за помощь!!!!