I was investigating how to provide an error callback for functions like channel.bindQueue(...) because it isn't specified clearly in the jsdoc and I stumbled across the following issue.

AmqpChannel.js makes use of _enqueueAction(...) in many places. For example:

  AmqpChannel.prototype.bindQueue = function(
   queue,exchange,routingKey,noWait,arguments, callback) {
      var args = [ 0  , queue  , exchange  , routingKey  , noWait  , arguments   ];
      var methodName = 'bindQueue';
      var amqpMethod = _methodsByName[methodName];


      // TODO
      // This is a temporary workaround to get the value of the noack flag
      //   without knowing up front if the method has a noack parameter.
      //
      // This logic can be removed if a noack field is added to the codegen model
      var hasnowait = false;
          for (var i=0; i<amqpMethod.allParameters.length; i++) {
              var argname = amqpMethod.allParameters[i].name;
              if (argname = "noWait") {
                  hasnowait = true;
                  break;
              }
          }


      if(this._connection._readyState == this._connection.OPEN)
          this._enqueueAction(methodName, _channelWrite, [this, amqpMethod, this._id, args], callback);

      // need for conditional insertion of code while using string template
      // Below if condition should be added for funtions like declareExchange(), declareQueue(), bindQueue() and consumeBasic()
      // As of now they are added in all functions due to string template

      if (methodName == "flowChannel") {
          AmqpChannel.prototype.flowFlag = active;
      }

      // if there is a nowait param, and it is true, we need to get out of the waiting state
      if (hasnowait) {
          if (typeof(noWait) !== "undefined" && noWait) {
              this._enqueueAction("nowait");
          }
      }

      return this;
  };

However, it never passes more than 4 arguments to _enqueueAction(...), which means the defaultErrorCallable callback will always be used.

_prototype._enqueueAction = function _enqueueAction(actionName, func, args, continuation, error) {
    var action = {};
    action.actionName = actionName || "";
    action.func = func || nullCallable;
    action.args = args || null;
    action.continuation = continuation || nullCallable;
    action.error = error || defaultErrorCallable;

    this._actions.push(action);

    var context = this;
    var func = function(){context._processActions();};
    setTimeout(func,0);
};

In the guide it looks like the writer was expecting to be able to pass an error callback into these methods. For example:

channel.bindQueue(queueName, exchangeName, routingkey, noWait, null, function(e) { log(output, exchangeName + " bound");}, errorHandler(output));

I would expect to be able to provide an error callback parameter or for my callback parameter to be invoked with an error.

From @krismcqueen on December 9, 2014 21:48

I'm following the setup instructions in the README and one step is to "install bower" by doing an

npm install -g bower

but that exact command results in an error saying "Please try running the command again as root/Administrator." The instructions should be more clear about the need for elevated privileges by possibly saying something like "as root/Administrator execute npm install -g bower" or even "sudo npm install -g bower" which would've gotten the point across.

Copied from original issue: kaazing/kaazing-client-javascript#6

From @sanjay-saxena on October 22, 2015 18:44

When Gateway terminates a native connection, it sends 1000 as the CLOSE code as part of the CLOSE WebSocket frame. However, when Gateway terminates an emulated connection, it sends the CLOSE command frame that looks like this as per wseb/1.0:

0x01 0x30 0x32 0xFF

In wseb/1.0 protocol, we(Gateway and the clients) do not have the ability to send/receive the CLOSE code as part of CLOSE command frame. Since there is no CLOSE code available in wseb/1.0 CLOSE command frame, all the clients fallback to RFC 6455 mandated 1005 CLOSE code. This causes the behavior between native and emulated modes to be different.

If we have to fix this issue without going to wseb/1.1 in the short-term, then it has to be addressed in ALL the clients. When server terminates an emulated connection, the emulated client should report 1000 as the CLOSE code. However, when an emulated client initiates the closing handshake, it should use 1005 as the CLOSE code.

Copied from original issue: kaazing-private/gateway.client.javascript#12

Gateway with version:

Gateway 5.0

Can the bug be reproduced in a Kaazing demo out-of-the-box?

No.

Steps to reproduce:

Follow the instructions specified in Gateway sends response with invalid Sec-WebSocket-Protocol header #472

WebSocket connection to 'ws://localhost:8080/mqtt' failed: Error during WebSocket handshake: Sent non-empty 'Sec-WebSocket-Protocol' header but no response was received

Now, modify mqtt.html by adding the following lines above the <script src="mqttws31.js"></script> line:

<script src="http://cache.kaazing.net/bower/kaazing-websocket-client-javascript/5.0.0-50/WebSocket.js"></script>
<script>
    window.WebSocket = Kaazing.Gateway.WebSocket;
</script>

Open mqtt.html in a browser: http://localhost:8000/mqtt.html. Notice that the app succeeds, and the echoed message is written to the screen.

However this should not succeed because the server never send a Sec-WebSocket-Protocol header with the value of "mqtt". But it should have because the request contained the Sec-WebSocket-Protocol header with the value of "mqtt".

In the first case, the browser is enforcing the RFC 6455 spec. In the second case, the Kaazing client library should be doing the same enforcement, but is not.

Expected behavior:

In both cases, the handshake should fail.

Users of Amqp-0-9-1.js cannot use the default exchange or empty-string routing keys.

This is because the guards are too strict. For example in publishBasic(...):

if (!exchange || typeof exchange != 'string') {
    throw new Error("AmqpChannel.publishBasic(): String parameter \'exchange\' is required");
}
if (!routingKey || typeof routingKey != 'string') {
    throw new Error("AmqpChannel.publishBasic(): String parameter \'routingKey\' is required");
}

They are too strict because the empty-string '' is a falsy value in JavaScript (see: https://developer.mozilla.org/en-US/docs/Glossary/Falsy)

!'' === true

I would suggest changing guards, where the empty-string should be allowed, to something like the following:

if (exchange == null || exchange == undefined || typeof exchange != 'string') {
    throw new Error("AmqpChannel.publishBasic(): String parameter \'exchange\' is required");
}
if (routingKey == null || routingKey == undefined || typeof routingKey != 'string') {
    throw new Error("AmqpChannel.publishBasic(): String parameter \'routingKey\' is required");
}

From @bradjorgensen on March 2, 2015 19:21

rejectBasic() doesn't work because it is in the wrong state array in AmqpClient.js. It is in the array for synchronous methods but it is asynchronous so it throws an error.
qosBasic doesn't work because it is not in any of the state arrays in AmqpClient.js.
I am working on a patch to fix these issues.

Copied from original issue: kaazing/kaazing-amqp-0-9-1-client-javascript#16

There is an unmet dependency on fsevents. Since fsevents is dependent on OS X, it won't install... This is caused by the fact that we are dependent on grunt-karma.

In our system we have some messages that only contain headers. This works fine when only using RabbitMQ. However, in the Kaazing AMQP JavaScript API AmqpChannel.onmessage is not called when the payload of a message is empty.