Hi Vino, thanks for the clarification. One last question :-). Is there ever a situation when it’s desirable/possible for a Producer and Consumer to share a single RabbetMQ connection? e.g., a low throughput device wanting to minimize connections? If so, the separate Producer and Consumer split doesn't support that case.
> On Mar 22, 2018, at 9:39 PM, vino yang <yanghua1...@gmail.com> wrote: > > Hi Dale, > > When I wroted the RabbitMQ connector I followed the Kafka Connector's style > (and I also looked the MQTT connectors). And I chose the Kafka connector as > the implementation template. The reason is the two classes > (RabbitmqProducer and RabbitmqConsumer) should not share one rabbitmq's > connection and channel (implemented in RabbitmqConnector). The two classes > maybe use in one topology (as consumer and producer) and split the inner > connection and channel would be better. > > 2018-03-23 2:28 GMT+08:00 Dale LaBossiere <dlab...@apache.org>: > >> I see the new RabbitMQ connector followed the same API scheme as the Kafka >> connector. i.e., adding Rabbitmq{Consumer,Producer} for the source/sink >> respectively. It looks like it could have followed the MqttStreams >> approach instead. >> >> @yanghua, is there a reason you chose to offer >> o.a.e.connectors.rabbitmq.Rabbitmq{Consumer,Producer} >> instead of just RabbitmqStreams? >> >> — Dale >> >>> On Mar 22, 2018, at 1:11 PM, Dale LaBossiere <dml.apa...@gmail.com> >> wrote: >>> >>> Hi Chris. Hopefully the background provided some useful context. But >> like I said, I don’t feel strongly about some renaming if folks agree >> that’s the right think to do. >>> >>> — Dale >>> >>>> On Mar 22, 2018, at 12:56 PM, Christofer Dutz < >> christofer.d...@c-ware.de> wrote: >>>> It was just something I had to explain every time I showed the code for >> the currently by far most interesting use-case for my plc4x pocs at the >> moment (pumping data from a PLC to a Kafka topic) . So I thought, that if I >> have to explain it every time, cause people are confused, then probably we >> should talk about making things more clear. >>> >> >>