Support for non-blocking event listener methods [SPR-17298]

[spring-projects-issues]

Mark Paluch opened SPR-17298 and commented

In a non-blocking application flow, it's desirable to prevent event listeners from blocking and yet have a notion of managed event completion (i.e. an event listener needs to interact with a remote system but must not block). Event listener methods could return future/async types so the event multicaster can synchronize on execution/initiate execution to use non-blocking event listeners in a reactive (or at least non-blocking) arrangement.

Event listener methods could either return:

• A future (in particular ListenableFuture, CompletableFuture, or CompletionStage, either Void, T, or Collection<T> component types)
• A Publisher (or any other supported reactive type such as RxJava 2's Observable with Void or T component types).

Example:

@Component
public class MyListener {
  
    @EventListener
    public Mono<Void> handleContextRefresh(ContextRefreshedEvent event) {
        ...
    }

    @EventListener
    public Flux<MyBusinessResponseEvent> handleBusinessEvent(MyBusinessEvent event) {
        ...
    }

    @EventListener
    public CompletableFuture<Void> handleBusinessEvent(MyOtherBusinessEvent event) {
        ...
    }
}

 
This feature could allow to implement functionality in event listeners in an non-blocking programming model to prevent blocking calls.

Result handles should be used to attach at least some sort of exception handling to prevent exceptions from going unnoticed. For reactive types, the multicaster subscribes to the reactive type to materialize the outcome.

Values emitted from a result handle (i.e. non-void returns like CompletableFuture<Void>, Publisher<Void>) could be emitted again as events.

This ticket seems to relate to #21025.

---

Issue Links:

• #21025 Use of ApplicationEventPublisher in a reactive call stack

1 votes, 5 watchers

[jhoeller]

Since each such listener is conceptually independent, should we simply subscribe to each returned Publisher individually? Would we have to manually exhaust the publisher through subscription.request(Long.MAX_VALUE) and publish each item as an event in onNext?

[jhoeller]

I suppose we could also process it along the lines of our use of MonoToListenableFutureAdapter in spring-messaging... as long as we're willing to require the presence of Reactor on the classpath.