API finalizations to Bro's Broker framework


  • Remove relay functions

  • In scripts that define custom topics, try to use pre-existing cluster topics

  • Add a Broker::forward(topic) function + enable broker forwarding mechanism (implies fixing any routing loops that exist)

  • Documentation updates for all the above




Jan Grashoefer
September 6, 2018, 6:58 PM

To be honest, I think the additional event makes the code harder to read if one is not familiar with that pattern. At a first glance I see three events but worker_to_workers_relay will be raised on proxies only. This has to be deduced by carefully reading the line

Jon Siwek
September 7, 2018, 12:16 AM

You can insert comments like "only raised on proxies" if it would help, but otherwise it's basic search/grep operations that one has to do all the time when reading code. Or don't use a differently-named event for relaying and use a single event with @if. Or maybe a plain "if" would be easier to understand in some cases, so feel free to do that. There's not a single, right way to do things for every combination of person + problem.

Jan Grashoefer
September 7, 2018, 12:41 AM

There's not a single, right way to do things for every combination of person + problem.

I agree, but in this case I think it might just make sense to define something like a best practice or common pattern. For example, use the same event names suffixed by _relay or _proxy.

Justin Azoff
September 7, 2018, 4:59 AM

Well, I got things working using the manual relay event.. It would be nice if there was a generic one that could be used, but it's not the end of the world.

I did run into the issue that the API is

I'm not sure if this 2nd parameter provides any value to the use of round robin message distribution. two scripts using rr_topic with the same pool but different keys will end up sending the same number of messages to each member of the pool if they were using the same key anyway.

i.e., If you had 2 scripts and 4 proxies, and each script sent 4 messages:

If there was no key, and only a single rr_key_seq they would send messages like

The end result is the same number of messages sent to each proxy.

Jon Siwek
September 7, 2018, 6:50 AM

Yeah, I can see that having a well-defined order/distribution for messages of a given type is maybe not the common/critical case, so thinking to just make the key argument have an arbitrary default. e.g. new function being:

I'd maybe still find the key argument useful in very specific types of unit tests where I don't want anything else interfering with a baseline message distribution/order.



Robin Sommer


Jon Siwek



External issue ID



Fix versions