no callback called when xmpp server down

[shobhitsinghal624]

I am stuck in the case when there is no reply from the xmpp server, as the callback is never called.

socket.client.send('xmpp.ping', {}, function(err, success) {
  console.log("HERE");
  console.log(err, success);
});

Here is what I get on console.log(client.tracking);

[ '61985b73-3294-4397-96b7-f7a0b82d57f3': { callback: [Function], jid: [ 'example.com' ] },
  'e1965f90-733e-4f1c-8ab9-804a5de0b8b9': { callback: [Function], jid: [ 'example.com' ] } ]

Shouldn't the callback be called with a no-response error. Or is there another way to handle no response from the xmpp server.

[lloydwatkin]

If the server isn't there then it can't respond with an error response. You should have received an event on xmpp.error when the server went away.

Or are you in the situation where the server is up and you are connected but the server isn't responding to pings?

[shobhitsinghal624]

Didn't receive the xmpp.error event. Let me give a full context, please bear with the lengthy reply

I am writing an admin bot in a node.js app to communicate with my ejabberd xmpp server. The xmpp server is not trustable and it restarts frequently. These admin tasks are very important, so I have to make sure that there is an active connection before making the calls. For this I want to use xmpp.ping before every call. Most likely case would be that the xmpp server is restarted and running, but the original connection from my node.js app is lost. I was hoping that when I send a xmpp.ping event, I would receive an error which I can use to reconnect.

I am also open to an alternative solution, if you can suggest something.

[lloydwatkin]

Ahh ok.

When the XMPP server dies it should inform clients and this will be passed down as an xmpp.error. If the socket just dies then this will fire an XMPP logout. This will close your websocket (presumably you are doing this from a browser?). You could check for close/end/disconnect events on your websocket?

Maybe you aren't seeing either of these events? Or are you running this from a server entirely? (i.e. no browser)

If there's more for discussing I'm happy to set up a chat to help you sort out your issues here.

I've also created https://github.com/lloydwatkin/xmpp-command-bot if that's of any use?

[shobhitsinghal624]

When the XMPP server dies it should inform clients and this will be passed down as an xmpp.error.

Most likely this isn't happening, I'll need to check.

Or are you running this from a server entirely? (i.e. no browser)

Exactly. Its a node.js server, which is also a backend api for a mobile app.

If there's more for discussing I'm happy to set up a chat to help you sort out your issues here.

This would be great. Let me know how you want to do this.

I've also created https://github.com/lloydwatkin/xmpp-command-bot if that's of any use?

Looks interesting, right now I am handling all the tasks via xmpp calls with admin user. But this would also mean that the node app should be running on the same instance as the xmpp server, which may not be very comfortable.

[lloydwatkin]

The command bot can live anywhere, you can make command requests to a remote server using ssh.

But anyway feel free to IM me at lloyd@evilprofessor.co.uk and we'll chat through your issues.

[lloydwatkin]

Exactly. Its a node.js server, which is also a backend api for a mobile app.

How have you implemented your server side socket (the one you give to xmpp-ftw)? Do you have 'end' or 'close' events you are listening on?

[shobhitsinghal624]

I am using the one given on the wiki page -

var Socket = function() {
  this.server = new Emitter();
  this.client = new Emitter();
  var self = this;
  this.server.send = function(event, data, rsm, callback) {
    self.client.emit(event, data, rsm, callback);
  };
  this.client.send = function(event, data, callback) {
    self.server.emit(event, data, callback);
  };
};
Socket.prototype.on = function(event, data, rsm) {
  this.server.on(event, data, rsm);
};
Socket.prototype.send = function(event, data, callback) {
  this.server.send(event, data, callback);
};
Socket.prototype.removeAllListeners = function(event) {
  this.server.removeAllListeners(event);
};
Socket.prototype.end = function() {
  this.server.emit('end', 'connection closed', function() {});
};

var socket = new Socket();

added the end prototype after reading your comment. Already listening to end and close events. Still not getting disconnect messages. On a different note, would you recommend using primus / socket.io ? I thought this is simple and would be just fine for my use.

[lloydwatkin]

Could you just add a console.log in 'on' method and see if anything comes through when your server dies.

[shobhitsinghal624]

Tried with the onAny() listener of eventemitter2. Nothing comes through when server dies.

[shobhitsinghal624]

Okay. I got a workaround for this. Posting it here for anyone who comes searching for a solution.

xmppClient.client.once('offline', function(data) {
  console.log("disconnected");
  // reconnect logic goes here
});

where xmppClient is the result of new xmppFtw.Xmpp(socket). Also, this listener needs to be attached after the original connection is made, since xmppClient.client is false originally. Note the use of once instead of on as any disconnect will create a new xmppClient.client. Got hint from here if anyone wants to explore and find a better solution.

[shobhitsinghal624]

Leaving the issue open since the original problem is still not solved - no callback is called when xmpp server is down. Here are my views on this.

• Not calling the callback leads to memory leakage - client.tracking keeps accumulating callbacks.
• Intuitively a ping request should throw an error if server is down which is not happening here.

@lloydwatkin Please close the issue if you feel differently.

[lloydwatkin]

Actually this should be incorporated into xmpp-ftw, a fix here (using your update) and a trigger to report no connection would fix both these issues at once.

[lloydwatkin]

@shobhitsinghal624 the first part of this is fixed and pushed as 1.14.6. This covers the offline event. Will look at 'not connected' reporting next.

[shobhitsinghal624]

Thanks @lloydwatkin . Just tested the new version, works as expected except for the stack overload issue for which I have raised a small PR - xmpp-ftw/xmpp-ftw#79

[lloydwatkin]

Thanks for the PR, now merged and published, I'll get on with a method to report the lack of a connection in the next few days.