Hi Benjamin,
I noticed that the body attribute is always put as part of the message header when you use the stomp.send function. How can you ensure that message body should not be added in the header?

client.send({
'corellationid': '4376423-42384793274923-42423',
'destination': queue,
'persistent': 'true',
'body': datatoSend,
}, false );

here is the output

{ command: 'MESSAGE',
headers:
[ body: ' cfe1',
'message-id': 'ID:ctovm921-44693-1305919160222-4:148:-1:1:1',
corellationid: '4376423-42384793274923-42423',
destination: '/queue/BRUTUS.MTX',
timestamp: '1306191865238',
expires: '0',
session: 'ID:ctovm921-44693-1305919160222-4:148',
priority: '4' ],
body: ' cfe1\u0000\n' }

Stomp consumer doesn't support wildcards

var stomp_args = {
    host: "localhost",
    port: 61613,
    debug: false
}

var headers = {
    destination: "/queue/PRICE.STOCK.>",
    ack: "client-individual"
};

var client = new stomp.Stomp(stomp_args);

client.subscribe(headers, message_callback);

function message_callback(body, headers) {
    console.log('Message Callback Fired!');
    console.log('Headers: ' + sys.inspect(headers));
    console.log('Body: ' + body);
}

C:\Wildcards\consumer\node_modules\stomp\lib\stomp.js:299
if (subscription.enabled && subscription.callback !== null && typeof(subscription.callback) == 'function') {
^

TypeError: Cannot read property 'enabled' of undefined
at Stomp.should_run_message_callback (C:\Wildcards\consumer\node_modules\stomp\lib\stomp.js:299:25)
at Stomp.handle_new_frame (C:\Wildcards\consumer\node_modules\stomp\lib\stomp.js:315:22)
at Socket. (C:\Wildcards\consumer\node_modules\stomp\lib\stomp.js:160:19)
at emitOne (events.js:96:13)
at Socket.emit (events.js:188:7)
at readableAddChunk (_stream_readable.js:176:18)
at Socket.Readable.push (_stream_readable.js:134:10)
at TCP.onread (net.js:547:20)

I've noticed that ie8 fails when it tries to send a message.
When the function sizeOfUTF8 is called ie8 dies on the
encodeURI(s).split(/%..|./).length-1

When split is called it returns nothing.

client.js:121 Uncaught TypeError: net.createConnection is not a function
at StompClient.connect (client.js:121)
at new RequieComponent (requireComponent.js:52)
at eval (ReactCompositeComponent.js:294)
at measureLifeCyclePerf (ReactCompositeComponent.js:75)
at ReactCompositeComponentWrapper._constructComponentWithoutOwner (ReactCompositeComponent.js:293)
at ReactCompositeComponentWrapper._constructComponent (ReactCompositeComponent.js:279)
at ReactCompositeComponentWrapper.mountComponent (ReactCompositeComponent.js:187)
at Object.mountComponent (ReactReconciler.js:45)
at ReactCompositeComponentWrapper.performInitialMount (ReactCompositeComponent.js:370)
at ReactCompositeComponentWrapper.mountComponent (ReactCompositeComponent.js:257)

Hi,All:
I'm using activeMQ and this client, but time to time, I found that the client lost the connection without any notification, and I checked activeMQ doc ,it does support the reconnection,http://activemq.apache.org/how-can-i-support-auto-reconnection.html, but I did not see this feature in the nodejs client? Or there is some way that I don't know, thanks in advance.

As per instructions, http://stomp.github.io/stomp-specification-1.1.html#DISCONNECT

"To do a graceful shutdown, where the client is assured that all previous frames have been received by the server, the client should send a DISCONNECT frame with a receipt header set"

Without this, using ActiveMQ, you will receive the following message on the server:

[ActiveMQ Transport: tcp:///127.0.0.1:63893] INFO o.a.a.b.T.Transport - Transport failed: java.io.EOFException

Hi there:

I think there's a typo in stomp.js, parse_headers(...):

var these_headers = [],

I think must be

var these_headers = {},

Using the original way, I never receive the headers (well, I receive an empty array). With this fix I started to receive the full headers.

Good library BTW!

The following code will cause node to terminate on a TLS authentication error:

var stomp = new Stomp(args);
stomp.on('error', function (err) {
  console.error("Stomp Error: " + err);
});
stomp.connect()

I had to add the following (immediately after connect()) to be able to catch it:

stomp.socket.on('error', function (err) {
  console.error("Stomp TLS Error: " + err);
});

The reason for this is due to this code in stomp.js

stomp.socket = tls.connect(stomp.port, stomp.host, stomp.ssl_options, function() {
    log.debug('SSL connection complete');
    if (!stomp.socket.authorized) {
        log.error('SSL is not authorized: '+stomp.socket.authorizationError);
        if (stomp.ssl_validate) {
            _disconnect(stomp);
            return;
        }
    }
    _setupListeners(stomp);
});

_setupListeners(stomp); is only called after tls.connect() succeeds, in the callback.

According to http://nodejs.org/api/tls.html#tls_tls_connect_port_host_options_callback

the callback parameter will be added as a listener for the 'secureConnect' event.

Since there is no socket.on('error') handler when tls.connect fails, stomp never catches the error and never, subsequently, emits its own error.

I did find the above workaround, but it seems that stomp.on('error') should have worked the first time.

I'm sending the following bytes from java: 45,-113,4,-120 and on the node.js side I get:
45
65533
4
65533
for (i=0;i<message.body.length;i++) {
console.log(message.body.charCodeAt(i));
}

STOMP supports binary data, so I would expect it it be handled with Buffers instead of strings.

Hi,
I just tried this and its great.
But I enabled activemq.prefetchSize and set it to only fetch 1 item, but it still took all 35 msgs off the queue.
I thought it would only remove one? Am I not understanding this header?

The new version, that npm installed under "stomp" has this error.

Its a bit different to the previous "stomp-js" code.

When install the package using npm and loading it with webpack here is what I have:

Module not found: Error: Cannot resolve module 'net' in /Users/gottfrois/Code/TextMaster.com/node_modules/stomp/lib
 @ ./~/stomp/lib/stomp.js 24:10-24

Module not found: Error: Cannot resolve module 'tls' in /Users/gottfrois/Code/TextMaster.com/node_modules/stomp/lib
 @ ./~/stomp/lib/stomp.js 25:10-24

Wrong repo to raise an issue. Apologies.

Is there way to grantee that message send by returning callback

var client = new stomp.Stomp(stomp_args);
client.send(headers, true);

something like that

// callback
client.send(headers, true, function(err,reply) {
    if (err) {
        logger.error('[AMQ-producer] error : ' + err.message);
        logger.debug('[AMQ-producer] error stack : ' + err.stack);
    } else {
        logger.info(reply);
    }
});

Please release your latest changes on npm. The version available on npm breaks subscriptions if you follow the examples given on github, because they're not the same.

Hi,

I am a bit surprised that this is not working and I am wondering if it is me doing something wrong.

Problem is when receiving a large message (plain/text), information is processed and the Frame is created even if the message is not completed (the socket would have had received eventually all information as I have checked) but in the first data event is processed without contemplating the case of not being complete.

Is this some sort of configuration issue, or is it just not coded at the moment?

If it is the second case I would probably give it a go to try to fix it.

Regards,

Hi I am trying to connect to a TIBCO queue. I am using the below code as suggested by the documentation. But i am getting a error as shown below.Please let me know what is the problem with my code.

error: Error: write ECONNRESET
at exports._errnoException (util.js:837:11)
at Socket._writeGeneric (net.js:675:26)
at Socket._write (net.js:694:8)
at doWrite (_stream_writable.js:292:12)
at clearBuffer (_stream_writable.js:396:7)
at onwrite (_stream_writable.js:331:7)
at WritableState.onwrite (_stream_writable.js:89:5)
at Socket._writeGeneric (net.js:684:5)
at Socket. (net.js:630:12)
at Socket.g (events.js:260:16)error name: Error
{ [Error: write ECONNRESET] code: 'ECONNRESET', errno: 'ECONNRESET', syscall: 'w
rite' }

The code as below :

var stomp = require('stomp');
var stomp_args = {
port: 7222,
host:'localhost',
debug: true,
login: '',
passcode: '',
};
var client = new stomp.Stomp(stomp_args);
client.connect();
client.on('connected', function () {
num = num || 1000;
for (var i = 0; i < num; i++) {
client.send({
'destination': '/queue/testqueue',
'body': 'Testing\n\ntesting1\n\ntesting2 ' + i,
'persistent': 'true'
}, receipt);
//sleep(250);
}
console.log('Produced ' + num + ' messages');
client.disconnect();
});

client.on('receipt', function (receipt) {
    console.log("RECEIPT: " + receipt);
});

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

I've attempted to use this library to register a listener on ActiveMQ 5.6, and 5.8 and it appears to be problematic because the listener somehow just loses contact with the messaging server silently ( my client.on('error') handler is never called)... When these disconnects happen, any new messages to a topic or queue aren't picked up by the stomp-js listener until the process is restarted. Was wondering if using keep-alives, which I believe are available in version 1.1 of the Stomp protocol would fix this. Is that supported, and if so, how?

This client works with ActiveMQ, now the official spec doesn't say end of frame is

NULL+LF

but just NULL.

If we have a server that adheres to the exact standard, then the client will not work, because it will never see a ^@+\n

Was this done on purpose or incorrectly interpreted or copied ?

Or should it handle cases of just a NULL between frames?

The on('data') handler has apparent spec violation and subsequent fix that introduces a regression.

The body is then followed by the NULL octet. The examples in this document will use ^@, control-@ in ASCII, to represent the NULL octet. The NULL octet can be optionally followed by multiple EOLs.

    var frames = buffer.split('\0\n'); 

A fix was added that breaks pipelined frames, if frames arrive with mixed \0 and \0\n

    // Temporary fix : NULL,LF is not a guranteed standard, the LF is optional, so lets deal with it.  (Rauls)
    if (frames.length == 1) {  // N.B. == 1means only it the previous split did nothing.
        frames = buffer.split('\0');
    }

Side note: \0 is valid inside MESSAGE data if content-length was provided. But I guess thats a bigger issue.Its OK thatn stomp.js does not support binary. Should be in the docs tho.

I think just

var frames = buffer.split('\0');

Should suffice, I tested that and it seems OK.

Mixed \0 and \0\n terminations occur when \n heartbeats are added between frames that then get buffered.

Move extra logic from the Frame object into it's own, or into the Stomp object. Frame should only be an object representing a data frame.

This change should be transparent to the client interface.

Benjamin, you should use

Stomp.prototype.__proto__ = process.EventEmitter.prototype;

instead of

Stomp.prototype = new process.EventEmitter();

to proper processing of several simultaneous client connections.

In your case any event is emitted to all clients instead of the single one.

Hi,

your library seems to work really good. We are using it with ActiveMQ and didn't encounter any problems until now :)

We consume messages over stomp, the body of each message is a JSON string. Your library appends '\u0000\n' to that string which should not happen ;)

the below is the error code:

stomp.js:25 Uncaught Error: Cannot find module "tls"
    at webpackMissingModule (stomp.js:25)
    at eval (stomp.js:25)
    at Object.<anonymous> (bundle.js:2614)
    at __webpack_require__ (bundle.js:677)
    at fn (bundle.js:88)
    at new RequieComponent (requireComponent.js:103)
    at eval (

When a large queue is polled for data, only partial data is received when the 'data' event is fired. Likely due to an OS buffer limit.

Maybe need to buffer the partial data chunk and ensure we only parse complete frames. The rest of the messages should be left on the queue if not ack'd.

In the case of ActiveMQ, you can limit the number of messages that are returned by server with the 'activemq.prefetchSize' header when subscribing. That works around the problem there.

Make it actual software. Write some dang tests.

But seriously, just started a rewrite TDD'ing this. It will be loads better. Promise.

xoxo,

me

The reconnect pull request seems to be extremely useful to several people. Just wondering what the status of stomp-js is.

When connecting to a clean queue, everything works properly.

I purposefully commented the ack() line out to see if it handles it correctly, when I launch node again, it fails to parse the (same) message.

Here's the log:

Sams-MacBook-Pro:stomp-js samit$ ./examples/stomp-consumer.js 
Connected
Got message: 114
HEADERS: { timestamp: '1344654591258',
  redelivered: 'false',
  expires: '0',
  subscription: 'subscription/jms.queue.orders',
  priority: '4',
  'content-length': '84',
  'message-id': '114',
  'http_content$type': 'text/plain; charset=UTF-8',
  postedAsHttpMessage: 'true',
  'http_content$length': '84',
  destination: 'jms.queue.orders',
  bytes_message: true }
BODY: <order>
   <name>Monica</name>
   <item>iPad</item>
   <cost>$499.99</cost>
</order>
^C
Consumed 1 messages
Sams-MacBook-Pro:stomp-js samit$ ./examples/stomp-consumer.js 
Connected
Got message: 114
HEADERS: { timestamp: '1344654591258',
  redelivered: 'true',
  expires: '0',
  subscription: 'subscription/jms.queue.orders',
  priority: '4',
  'content-length': '347',
  'message-id': '114',
  'http_content$type': 'text/plain; charset=UTF-8',
  postedAsHttpMessage: 'true',
  'http_content$length': '84',
  destination: 'jms.queue.orders',
  bytes_message: true }
BODY: <order>
   <name>Monica</name>
   <item>iPad</item>
   <cost>$499.99</cost>
</order>kr jms.queue.orders�9��"http_content$type
Could not parse command: 2text/plain; charset=UTF-8&postedAsHttpMessage�&http_content$length
Could not parse command: 84�
^C
Consumed 1 messages
Sams-MacBook-Pro:stomp-js samit$

BTW, the message is created using the REST interface (which is why those odd headers are added) and I think something in those headers is what causing the issue but it does parse it correctly the first time.

http://registry.npmjs.org/stomp/-/stomp-0.0.6.tgz

is different to

https://github.com/benjaminws/stomp-js.git

even though it says .6 , the tgz version is May25.

thats the npm install which is old.

the git version is ok.

Can you syncronize please.

D:\snalla\nodejsexp\mqExp\node_modules\stomp\lib\stomp.js:54
headers[header[0].trim()] = header[1].trim() ^
TypeError: Cannot read property 'trim' of undefined
at parse_headers (D:\snalla\nodejsexp\mqExp\node_modules\stomp\lib\stomp.js:
54:46)
at parse_frame (D:\snalla\nodejsexp\mqExp\node_modules\stomp\lib\stomp.js:76
:15)
at Socket. (D:\snalla\nodejsexp\mqExp\node_modules\stomp\lib\stom
p.js:160:28)
at Socket.emit (events.js:107:17)
at readableAddChunk (_stream_readable.js:163:16)
at Socket.Readable.push (_stream_readable.js:126:10)
at TCP.onread (net.js:538:20)

I think that there is a bug in parse_frame(), as this line of code

the_rest = data.split('\n\n');

splits the body from the header.

body = the_rest[1];

However, if the body itself contains data with "\n\n" embedded (for example, a "readme" file) then only the first chunk of the body is saved - as the_rest[2 .. n] contains the "rest" of the body

Should you not grab the headers from the start to the index of the first \n\n ?