Hi Vincent, I'm apologize for not contacting with you to discuss this question (it was my plan, but I run out of time and unfortunately I forgot it). As you pointed out: in incubator there is a non-java based Kafka driver. My plan is to keep it in the incubator and give the choice to the users. If someone needs a non-java Kafka destination then we can say: we have such a driver in the incubator. On the other hand, if someone wants to use a Kafka dst which is built around the official Kafka java client library, then she/he can use it. (Kafka was a really good candidate for implement it on the basis of the new Java language binding.) L. On Mon, Aug 17, 2015 at 5:11 PM, Vincent Bernat <bernat@luffy.cx> wrote:
❦ 17 août 2015 16:45 +0200, "Budai, László" <laszlo.budai@balabit.com> :
ElastiSearch, Kafka and HDFS destination drivers are implemented by using the 'official' Java client libraries and syslog-ng provides a way to set their own, native configuration file. Log messages generated by the client Java libraries are redirected to syslog-ng via our own Log4JAppender which means that those logs are available as internal syslog-ng messages.
* ElasticSearch * Kafka * Hadoop/HDFS * HTTP
That's a great addition but there is a working Kafka driver not depending on JVM waiting in syslog-ng incubator. This JVM-based Kafka driver comes a bit as a surprise. What does it mean for the Kafka driver currently in the incubator? -- If one cannot enjoy reading a book over and over again, there is no use in reading it at all. -- Oscar Wilde