Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
spring-issuemaster opened this issue Sep 23, 2018 · 2 comments

Comments

Projects
None yet
2 participants
@spring-issuemaster
Copy link
Collaborator

commented Sep 23, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Apr 26, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Apr 26, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.