dnrajugade / guava-libraries

Automatically exported from code.google.com/p/guava-libraries
Apache License 2.0
0 stars 0 forks source link

Support for custom HandlerFindingStrategy in EventBus #1226

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
This issue is quite similar to the closed issue in 
http://code.google.com/p/guava-libraries/issues/detail?id=803 (use case did not 
justify the request). However, my use case is different.

My case: many events that are posted to the event bus are of the same concrete 
type, with some different value for one of its fields. Consider a 
StateChangeEvent that has a processId field, to which that event refers.

public class StateChangeEvent {
    private Long processId; // referes Process.id
    private State newState;
}

public class Process {
    private Long id;
}

Without custom HandlerFindingStrategy, the StateChangeEvent handler methods 
would be invoked for each and every posted StateChangeEvent. If I have 1000 
state-changing Process instances in the air, each of which post 20 events, then 
most of the handler method invocations are well-redundant.

Customizing HandlerFindingStrategy will allow narrowing the invoked handler 
methods through mapping them by Process id.

Original issue reported on code.google.com by yair.ecl...@gmail.com on 11 Dec 2012 at 10:22

GoogleCodeExporter commented 9 years ago
Even if your use case is different, the same feature request should go with the 
same issue.

Original comment by lowas...@google.com on 11 Dec 2012 at 5:15

GoogleCodeExporter commented 9 years ago
I think I didn't present the feature request properly. Issue 803 basically 
requests to enable custom annotations to replace @Subscribe and 
@AllowConcurrentEvents. Opening HandlerFindingStrategy to public is actually an 
offered solution.

Here, on the other hand, the request is to enable custom filters on the 
EventHandlers that are invoked upon posting of an event (and again, opening 
HandlerFindingStrategy is just a proposed solution).

Consider AsyncEventBus. It creates a task for the internal Executor for each 
such EventHandler. This could blow up bounded queues or decelrate events 
processing for the least.

Anyway, it's not the same feature request. The common between the two is just 
the proposed solution but I don't really care how would this feature be 
implemented (except for curiosity aspects :-) ).

I ask to re-open this request (I can open a new one with the more proper above 
description if it suits better).

Thanks.

Original comment by yair.ecl...@gmail.com on 12 Dec 2012 at 12:13

GoogleCodeExporter commented 9 years ago
Here's an alternate solution for you that wouldn't require any API changes:

public class MessageForwarder {
  private Map<Long, EventBus> eventBusForProcess;

  @Subscribe
  public void processEvent(StateChangeEvent event) {
    eventBusForProcess.get(event.processId).post(event);
  }

  public void register(Process process) {
    EventBus processBus = new EventBus();
    processBus.register(process);
    eventBusForProcess.put(process.id, processBus);
  }
}

Essentially, the idea is to have your main event bus register a "delegator" 
that passes events only to the event buses that are "interested."

Original comment by lowas...@google.com on 12 Dec 2012 at 12:29

GoogleCodeExporter commented 9 years ago
First, thanks for the quick answer.

Looks goodd, except that I'm using EventBus in order to avoid creation of 
monitoring threads for each and every Process instance.

Is it possible to pass the same Executor to all Process-bound EventBuses? If 
so, I think that would do the trick.

Original comment by yair.ecl...@gmail.com on 12 Dec 2012 at 12:58

GoogleCodeExporter commented 9 years ago
Yup, it's totally possible.

Original comment by lowas...@google.com on 12 Dec 2012 at 1:15

GoogleCodeExporter commented 9 years ago
Great! Thanks for the help.

Original comment by yair.ecl...@gmail.com on 12 Dec 2012 at 7:34

GoogleCodeExporter commented 9 years ago
Though I still think that opening HandlerFindingStrategy for public is a better 
solution:

1) it's more efficient: no need to create numerous EventBus instances.

2) no need to implement EventBus removals algorithm. These EventBus instances 
cannot be held in memory for ever. Now client code has to worry about it, 
whereas it could be handled more safely within the EventBus implementation.

3) It's more elegant: it's actually sort of an abuse to use EventBus where a 
simple map would do.

Original comment by yair.ecl...@gmail.com on 12 Dec 2012 at 9:14

GoogleCodeExporter commented 9 years ago
This issue has been migrated to GitHub.

It can be found at https://github.com/google/guava/issues/<id>

Original comment by cgdecker@google.com on 1 Nov 2014 at 4:13

GoogleCodeExporter commented 9 years ago

Original comment by cgdecker@google.com on 3 Nov 2014 at 9:08