Re: Anyone else mis-interpret the "KafkaConsumer" and "KafkaProducer" all the time?

Hi Dale, The producer and consumer do not share one connection, just avoid they are both used in one topology (if we share the connection, the producer and consumer which close the connection would trigger another failure). Actually, this case I just described rarely occurs(that means the most of

Re: Anyone else mis-interpret the "KafkaConsumer" and "KafkaProducer" all the time?

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

Re: Anyone else mis-interpret the "KafkaConsumer" and "KafkaProducer" all the time?

Hi guys, I also agree change the connectors renaming. When I wrote the RabbitMQ connector, I watched the Kafka connector's implementation. There are two communication pair : KafkaPublisher / KafkaSubscriber and KafkaConsumer / KafkaProducer. I feel confused about them. I think this mode would be

Re: Anyone else mis-interpret the "KafkaConsumer" and "KafkaProducer" all the time?

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

Re: Anyone else mis-interpret the "KafkaConsumer" and "KafkaProducer" all the time?

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

Re: Anyone else mis-interpret the "KafkaConsumer" and "KafkaProducer" all the time?

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 > wrote: > It was just something I had

Re: Anyone else mis-interpret the "KafkaConsumer" and "KafkaProducer" all the time?

Hi Dale, Happy to read from you :-) 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

Re: Anyone else mis-interpret the "KafkaConsumer" and "KafkaProducer" all the time?

A bit of background… The Kafka connector is two classes instead of a single KafkaStreams connector (with publish(),subscribe()) because at least a while ago, don’t know if this is still the case, Kafka had two completely separate classes for a “consumer” and a “producer" each with very

Re: Anyone else mis-interpret the "KafkaConsumer" and "KafkaProducer" all the time?

Hi Chris, All data processing framework could think it as a *pipeline . *The Edgent's point of view, there could be two endpoints : - source : means data injection; - sink : means data export; There are many frameworks use this conventional naming rule, such as Apache Flume, Apache