Error handling on connection

[AndrewKeig]

Hi

I noticed a recent issue #103, which I think attempted to resolve this issue. When kafka is not available, or the host provided to kafka.client is wrong, how can I detect this? The error handlers in this example are never hit.. The example below creates a topic; it will not time out, and no error is reported; it simply repeats the process of trying to create a topic. If kafka fails for whatever reason we cannot recover on the application side, the application will never know.

var kafka = require('kafka-node'),
    Producer = kafka.Producer,
    client = new kafka.Client('wrong'),
    producer = new Producer(client);

    client.on('error', function (err) {
        console.log(err);
    });

    producer.on('error', function (err) {
        console.log(err);
    });

    producer.createTopics(['some-topic'], true, function (err, data) {
      console.log(data);
    });

[haio]

Hi, do you get the same problem? For producer, every thing should be done after it get a ready event, which means client connect zookeeper and load broker info successfully. I also wonder why node-zookeeper-client doesn't emit any event even I give it a wrong connection string.

[AndrewKeig]

Fair point, but it still just hangs if I add the ready event, and nothing is emitted. So I think your right its possibly zookeeper not emitting events.

var kafka = require('kafka-node'),
    Producer = kafka.Producer,
    client = new kafka.Client('127.0.0.1'),
    producer = new Producer(client);

    client.on('error', function (err) {
        console.log(err);
    });

    producer.on("ready", function () {

      producer.on('error', function (err) {
          console.log(err);
      });

      producer.createTopics(['some-topic'], true, function (err, data) {
        console.log(data);
      });
    });

[haio]

Yeah, even I explicitly set a timeout option for zk, it still doesn't emit any event

[tekny]

I've found that kafka-node works with zookeeper via ConnectionManager which will try to reconnect forever no matter what.

https://github.com/alexguan/node-zookeeper-client/blob/master/lib/ConnectionManager.js#L269

I assume it may be a serious design problem. IMO it should at least notify about those errors.

[alph486]

bump. I'm able to connect to a local Kafka instance via shell but the library will not. I'd love to debug but I don't get any notifications if ZK connect fails.

[mwaarna]

bump!
This is a critical issue.

the on error event should be triggered or a new event added when connection fails.

Issue needs to be resolved in the Connection Manager:
alexguan/node-zookeeper-client#30

[perpective2410]

+1

[reemdiab]

+1

[naderchehab]

+1

[estliberitas]

Fix was proposed long long time ago and no changes since then: alexguan/node-zookeeper-client#16

[samypr100]

+1

[Petrox]

+1

[codeofsumit]

+1

[Infra-dev]

+1

[linxuanwei]

+1

[Insferatu]

+1

[danielnuriyev]

+1

[vivekpathak]

One way to handle this situation is to open a timeout with setTimeout before you send. The timeout would close the connection (and wait for callback) and then reconnect before calling send with the same parameters. This way you dont hang and come out even if kafka/zookeeper are down.

On the non error side, once the (original) send completes, the timeout should be cleared with clearTimeout because there is no need to resend.

It seems to work well when kafka/zk are up and recovers nicely from a restart.

[gnitsenko93]

@vivekpathak despite it is quite smart way this is still a workaround!

+1 for a native support

[respinha]

+1

[ayZagen]

+1

[benitojcv]

+1

[jean507]

+1

[AndrewKeig]

lol, 3 years and counting... I hear RabbitMQ is pretty good...

[jogaklaa]

+1

[mihaimm]

+1

[clodio]

+1

[peterbabinec]

+1

[amirabiri]

@AndrewKeig - It's not related to Kafka. It's not even node. This library needs a lot of work still and it has many small gotchas. And at the same time for some reason no other alternative has emerged.

[vivekpathak]

One way to handle this situation is to open a timeout with setTimeout before you send. The timeout would close the connection (and wait for callback) and then reconnect before calling send with the same parameters. This way you dont hang and come out even if kafka/zookeeper are down.

On the non error side, once the (original) send completes, the timeout should be cleared with clearTimeout because there is no need to resend.

It seems to work well when kafka/zk are up and recovers nicely from a restart.

Workaround is robust even on planetary scale iot data transfer being done through kafka

Because its an underlying node library issue to do with one sided socket close, it should be Ok to use workaround (which can be considered to be the right way to do things since node socket close is one sided).