Where is this project going?

[KimSchneider]

Hi,

I played around with the module a bit and nothing really seems to work. None of the examples work out of the box. To subscribe to a destination using the ChannelFactory a call to channel() is required. Consuming messages results in a maximum call stack size exceeded message and the following error:

(node) warning: Recursive process.nextTick detected. This will break in the next version of node. Please use setImmediate for recursive deferral.

The base code and idea look good, but please bring this project to production ;)

[gdaws]

I'm currently using node 0.12 and RabbitMQ 3.2 and all the examples are working for me. It's been a while since I last tested other brokers. I'm hoping to perform tests with ActiveMQ soon when I can get past the nightmare of installing and configuring it.

Please provide details of your environment and I'll try to replicate your issues.

When you run command "npm test" in stompit directory do all the tests pass?

[KimSchneider]

We are using Apollo which works just like ActiveMQ. Installing is really easy ;)

All our systems are running on the newest ubuntu, nodejs 0.10.36, two cores, two GB of RAM. It's pretty basic, but we consume about 100msg/sec on each consumer.

I can't run the tests because I have no machine with mocha available.

[gdaws]

Sorry, I was testing an old version of stompit by mistake. The code examples are out of date and some of them are no longer compatible with stompit's api. I plan to update the code examples soon.

I'm now testing with node 0.10.36 and Apollo 1.7.1

I've noticed a problem with Apollo when testing fast (100ms) heart-beating. When disconnecting, Apollo goes silent which causes the heart-beating to timeout and triggers a reconnect. Apollo isn't handling disconnect correctly. To close the connection the client sends TCP FIN but the server appears to ignore it and a second or two later the server sends TCP RST. During this disconnect pending time Apollo isn't sending heart beats.

There is a workaround available in stompit; use the undocumented connect option resetDisconnect: true. This option tells the client to close the connection with TCP RST which when used immediately closes the connection and stops heart beating.

I'm going to review how stompit implements heart beating as I've realised there's another potential problem with it.

Besides the heart-beating problem, I haven't noticed any other problems. You experienced stack overflow with a stompit code example or was it with your own code?

[KimSchneider]

Hey Graham, thanks for your efforts.

The stack overflows happened with my own code. It is possible that I’ve implemented stompit the wrong way, but I am not really sure.

I will check out your fixes and re-implement stompit. Due to CeBIT this will take a week or two, sorry.

[gdaws]

Version 0.21 of stompit resolves the issues raised here. The code examples have been updated. There is a workaround to avoid the nextTick warning. Abortive disconnect is now the default behaviour. Heart beating now stops as soon as the transport closes on the client side.

To reproduce the stack overflow issue my use case is simple, have one producer and one consumer; first send more than a thousand messages to the message broker and then startup the consumer. The consumer crashes after processing some of the messages. What I believe is happening is the consumer receives a large enough input at once from the transport socket to create many frame streams consecutively without leaving the nextTick callback loop, and after the nextTick loop is extended 999 times (or whatever is the value of process.maxTickDepth) Node begins outputting the warning message. It's wrong for Node to complain about excessive nextTick recursion and the warning message was removed in Node v0.11.10

The cause of the crash or stack overflow is the nextTick warning message. As the warning message is written to the stdout stream another nextTick warning is triggered because process.nextTick function is called again from Node's stream.Writable class. This issue is reported at nodejs/node-v0.x-archive#6065

[KimSchneider]

Thanks for your information and the bugfixing!

This seems to target our problem, because if we restart our connections we already have about 5000 messages in the queues. Will give stompit another try in the next weeks!