Guava: EventBus / AsyncEventBus -- Async should be decided by subscriber

[gissuebot]

_Original issue created by gilroy on 2012-03-30 at 02:42 AM_

---

I'm really not sure how to offer this criticism, but it seems like the decision of if a handler should execute synchronously or asynchronously is better known by the handler itself than the event bus.

For example, if I am updating an audit system and an index based on a change, I might want the former synchronous and the latter asynchronous. In the current design, I could (1) have two event busses, and post the event to each, or (2) queue the event onto a thread inside the index's handler.

Although both approaches are workable, neither seems ideal. Taking inspiration from the AllowConcurrentEvents annotation, how do you feel about an AsynchronousEvents annotation? It does seem consistent with the rest of your API.

As an implementation aside, you can see how AnnotatedHandlerFinder#newHandler() might be enhanced to return an AsynchronousEventHandler -- although that might require Executor be pushed down. Another way to think about is is to consider AsyncEventBus as nothing more than a custom HandlerFindingStrategy that returned AsynchronousEventHandlers be default.

If this enhancement request does not fit your vision for the package, perhaps you'd consider allowing the HandlerFindingStrategy to be configured publicly? Since I'm offering my opinion, I'll say this is the less exciting option to me.

I fully expect that this has already been much discussed internally. A discussion of your rationale would still benefit the community.

Thanks very much for your work releasing this library.

-dg

[gissuebot]

_Original comment posted by [email protected] on 2012-03-30 at 03:56 PM_

---

My opinion does not reign supreme on eventbus questions, but:

I agree that your alternatives are workable, and that when you're in the case you happen to be in, they seem un-ideal. But what we like about them is that they preserve the simplicity and clarity of how EventBuses operate. This package is one where we think it's very important to strike the right compromise between power and simplicity, and I'm personally pretty happy with how we've got it. The last thing I ever want to see is for a series of well-intentioned changes to wind up making it start seeming more like a "framework" than a library.

[gissuebot]

_Original comment posted by wasserman.louis on 2012-04-03 at 04:25 PM_

---

_(No comment entered for this change.)_

---

Labels: Type-Enhancement, Package-EventBus

[gissuebot]

_Original comment posted by [email protected] on 2012-05-05 at 12:19 AM_

---

I had a post on here earlier which I retracted because I think it was false. As I understand it (and I'd love some feedback on this). AsyncEventBus handles the individual event handlers in seperate threads, but each handler (that is, each subscribing method) will be called synchronously, if you wish for the methods themselves to also be calles async then you must annotate them with @AllowConcurrentEvents

If we could get this clarified that'd be great.

[gissuebot]

_Original comment posted by [email protected] on 2012-05-30 at 07:45 PM_

---

_(No comment entered for this change.)_

---

Labels: -Type-Enhancement, Type-Addition

[gissuebot]

_Original comment posted by dstovall on 2014-02-28 at 04:23 PM_

---

Besides Sync v. Async, the handler may also like to request a specific thread (or thread group or executor or ...).

To extend the use case above, I would like to support three handlers:
Handler 1) A synchronous handler to update the audit record
Handler 2) An asynchronous handler to reindex
Handler 3) An EDT handler to update a Swing component

This seems to be very parallel to AllowConcurrentEvents. If you allow a handler to denote that it is thread-safe, wouldn't it be similar for a handler to say "I'm not thread-safe, actually I need to be called from _this_ thread".

Handlers 2 & 3 can certainly re-dispatch the event, but that results in a lot of boilerplate code. Exactly the "tiny anonymous classes" that the EventBus documentation refers to, and code is very similar to the behavior provided by EventBus.

Since I know it will come up, there are suggestions out on the internet to create multiple EventBuses for listeners to register with. The EventBuses are then chained together or hidden behind a proxy. There are three issues that are immediately apparent to me:
1) This (always?) ends up disabling DeadEvents or duplicating DeadEvents (depending on implementation).
2) Whomever is registering the listeners has to know which Bus to register with.
3) All handlers on the listener will be dispatched the same way.

Now, all that said... I really like the simplicity of the current API. Since documentation specifically cites the Swing pattern, I anticipate that the EventBus authors have a recommended approach/solution for using EventBus with Swing. Whatever that approach is may be generalizable...

[gissuebot]

_Original comment posted by [email protected] on 2014-06-26 at 09:53 PM_

---

_Issue #1536 has been merged into this issue._

[cpovirk]

We're unlikely to add significant features to EventBus anymore.