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

[vino yang]

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
the scenario there is only one connection) . So I think we should take it
easy about the case you described.

Vino yang.
Thanks.

2018-03-27 4:27 GMT+08:00 Dale LaBossiere :

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

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

[Dale LaBossiere]

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