kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ewen Cheslack-Postava <e...@confluent.io>
Subject Re: Kafka dotnet SDK suggestion
Date Thu, 08 Oct 2015 01:53:47 GMT
The project doesn't make official recommendations about third party
clients. The only client directly supported is the Java/Scala library
included in the project's source repository.

However, the community does maintain a list of third-party clients here:
https://cwiki.apache.org/confluence/display/KAFKA/Clients Since it is
community maintained, we rely on people telling us about new libraries to
get them on there. I've just added the second library you mentioned to the
.net section.

As for which you should use, you'll have to evaluate the functionality of
both and which fits your needs best. The first one looks much more active
(the second hasn't had any commits since 2014), but that doesn't
necessarily say anything about their relative maturity.

If you're not sure about the quality of either of them, another option is
to use a REST proxy. Shameless plug since I work on it -- Confluent has one
as part of its platform (and it's open source). Since it uses the Java
clients, it covers all the functionality provided by them.


On Wed, Oct 7, 2015 at 8:51 AM, sugumar analysis <sugumar.analysis@gmail.com
> wrote:

> Hi All,
> We are developing Messaging system with Kafka using DotNet (C#).
> We found there are 2 different SDK available for Dotnet
> 1. https://github.com/Jroland/kafka-net/
> 2. https://github.com/ExactTargetDev/kafka-net
> First one is officially referred by Apache Kafka. But It is an initial
> stage, there are some functionalities not available ex. ConsumerGroup,
> AutoCommit features.
> In Second one it has all the features but its not referred by Apache Kafka
> *Can we choose second one for our development? *
> *      or *
> *should we use official SDK which is mentioned in Kafka site.?*
> Please give us your suggestions.
> Thanks,
> Sugumar J


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message