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

Closed
spring-projects-issues opened this issue Sep 23, 2018 · 2 comments
Closed

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

spring-projects-issues opened this issue Sep 23, 2018 · 2 comments

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues 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
Copy link
Contributor

@jhoeller jhoeller 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?

Loading

@jhoeller
Copy link
Contributor

@jhoeller jhoeller 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.

Loading

@jhoeller jhoeller removed this from the 5.2 M2 milestone May 1, 2019
@jhoeller jhoeller added this to the 5.2 M3 milestone May 1, 2019
@jhoeller jhoeller removed this from the 5.2 M3 milestone Jun 7, 2019
@jhoeller jhoeller added this to the 5.2 RC1 milestone Jun 7, 2019
@jhoeller jhoeller closed this in 7bfe01a Jul 5, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants