Как превратить Моно в действительно асинхронный (не реактивный!) вызов метода?

Нормально ли (= нет ли у этого каких-либо нежелательных побочных эффектов) просто вызвать Mono#subscribe() и вернуться из метода контроллера?

Есть побочные эффекты, но вы можете спокойно жить с ними:

• Это действительно огонь и забудь, что означает, что, хотя вы никогда не будете уведомлены об успехе (что осознает большинство людей), вы также никогда не будете уведомлены о неудаче (что осознает гораздо меньше людей).
• Если процесс по какой-то причине зависнет, этот издатель никогда не завершится, и у вас не будет возможности узнать об этом. Поскольку вы подписываетесь на ограниченный пул эластичных потоков, он также свяжет один из этих ограниченных потоков на неопределенный срок.

Первый момент, с которым вас может быть все в порядке, или вы, возможно, захотите каким-то образом протоколировать некоторые ошибки дальше по этой реактивной цепочке в качестве побочного эффекта, чтобы у вас, по крайней мере, было внутреннее уведомление, если что-то пойдет не так.

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

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

Наконец, этот пример:

public Mono<Void> processData() {
    service.processData()
        .subscribeOn(Schedulers.boundedElastic())
        .subscribe();
    return Mono.empty();
}

...это блестящий пример того, чего не следует делать, поскольку вы создаете своего рода "самозваный реактивный метод" - кто-то может очень разумно подписаться на этого возвращенного издателя, думая, что он завершится, когда основной издатель завершит, что, очевидно, здесь не происходит. Используя void возвращаемый тип и, следовательно, ничего не возвращать-это правильное решение в этом сценарии.

Ваш вариант со следующим кодом на самом деле в порядке:

@GetMapping
public void processData() {
    service.processData()
        .subscribeOn(Schedulers.boundedElastic())
        .subscribe();
}

На самом деле это то, что вы делаете в @Scheduled метод, который просто ничего не возвращает, и вы явно подписываетесь на Mono или Flux так что элементы испускаются.