Ability to do both Async and Synchronous events in the bus.

[basejump]

Add a buildNotificationCallableSync and a subscribeSync to make it possible to add Synchronous subscriptions listeners without the need for a Gorm AbstractPersitentEvent. This would be especially useful in easily enabling subscribers to participate in Transactions.

• In the Eventbus in the old platform-plugin for example, there was an option to fork:false that allowed this ability.

[graemerocher]

You can already subscribe GORM events synchronously by using @Listener instead of a @Subscriber

[basejump]

yes, but only if it's gorm event and it operate under a completely different mechanism with GormEventDispatcher. Also requires any events that you might want synchronous to be an AbstractPersitentEvent. If we can just have a buildNotificationCallableSync and a subscribeSync then it would be easy to extend and have both simliar to what is done in the SynchronousEventBus setup for testing. There are a ton of use cases for this but the biggest one would be events that are transactional and don't use GORM, specifically in lighter weight microservices.

[basejump]

We are using a forked version of Platform plugin and were hoping to replace it with this or at least be able to extend this, the only main thing missing from the base EventBus is a mechanism for synchronous events. The way its deisgned its also more or less locked down so we can't even add another , less than ideal solution, SynchronousEventBus as it will blow an IllegalStateException

[basejump]

@graemerocher We can do the work on this and issue a PR but was looking for some consensus on this.

[graemerocher]

Sounds good. Contributions welcome

[basejump]

We could close this feature request if we were the only ones interested in it. For synchronous events that need to be in a transaction, we are leaning on Spring's built-in event support.
We inject ApplicationEventPublisher and call publisher.publishEvent(event) as well as using this events eventBus.notify(event.routingKey, event) so Asynchronous listers can be used as well. 2 calls to 2 different event buses but it works and its fast. Can use the old way of implementing their ApplicationListener or use the newer @eventlistener annotation to on the listening end.
Spring has refactored it to use generics and it performs really well.

[longwa]

We are also interested in a way to subscribe to events synchronously and have them execute with the same transaction as the publisher. I was considering implementing a custom event bus that allows me to look at the subscription to see if it should be synchronous before returning the callable wrapper. I haven't really gotten to implementing it so there could be other problems with this approach.

[longwa]

After implementing the same solution as @basejump I started wondering why I even needed the Grails EventBus part of it at all. It seems like the spring event handling, especially with the newer annotation support, can handle most of the sync and async needs just fine.

By adding @Async to the method, I can handle the asynchronous requirement. Also, the @EventListener(condition = ...) is nicer for specifying dynamic conditions such as regex eventId matching or just other special matching conditions.

The downside is that I don't see any call back support for handling 'replies' on the spring side, so no sendAndWait equivalent.

Are there other reasons that I might prefer using the Grails event plugin vs. the built-in spring support that I'm not considering?

Just thinking out loud really, but it seems like they have mostly overlapping functionality so I'm wondering why both.

[davebrown1975]

Was there any development to this issue? I'm in a similar position, attempting to replicate synchronous events, if nothing else I'd like to use the sendAndReceive functionality however can't find any documentation explaining how to do so.