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.
>>> 
>> 
>> 

Reply via email to