On Tue, Aug 14, 2018 at 12:09 PM Jan Grashöfer <jan.grashoe...@gmail.com> wrote: > > On 13/08/18 18:24, Jon Siwek wrote: > > Old Worker: > > > > Cluster::relay_rr(Cluster::proxy_pool, my_event); > > > > New Worker: > > > > Broker::publish(Cluster::rr_topic(Cluster::proxy_pool), my_event); > > That doesn't look like an API simplification to me ;D
The goal here I imagine is rather to avoid releasing a function that we knowingly plan to remove later. A user would have to eventually port all Cluster::relay_rr() calls, but that Broker::publish() pattern remains valid. > > Even Newer Worker: > > > > Broker::publish(Cluster::worker_topic, my_event); > > > > See any problems there? > > For this case: Would it be easy to setup distinct pools for different > tasks? I could imagine a pool of proxies that is used explicitly for > intel distribution and one pool used for processing SumStats events. I > think we have discussed something like that before. Yeah, it would still be possible to define your own pool and use it for your own purposes and it looks similar to the call before: Broker::publish(Cluster::rr_topic(Cluster::my_pool), my_event); A difference in the context of our needs for the cluster communication is that the pool is being used as a means of achieving routing (in a load-balanced fashion) and so the call gets simplified once those mechanisms get built into Broker routing. In your case, you don't need the routing aspect, just the load-balancing provided by the "pool" concept. - Jon _______________________________________________ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
