Pub/Sub example in docs does not work as indicated.

[javadevmtl]

Hello,

Using 2.0.8

There's few things:

1. Multiple bus.subscribe('sameName'); Only creates 1 queue sameName.[SOME RANDOM STRING]. No matter how many processes you run.
2. Subscribe should create a fanout exchange by default (I think this is already recorded as an issue).
3. Furthermore combining 1 and 2 above, the consumers get messages in round robin fashion. So assuming you publish 2 messages and you have 2 consumers, then each consumers gets 1 message. They should have gotten 2 messages each and a total of 4 messages. I.e: A fanout exchange writing to 2 queues.
4. Based on what is explained above, the test case for pub/sub is not correct. You create 4 consumers and publish 4 messages the total of messages received should be 16 total (4 each) and not 1 each of total 4.
5. The following app.js: http://pastebin.com/1Ab4JCVL for what ever reason, when you use the RabbitMQ management interface to send a test message, causes the application to exit. Seems to happen when any external application publishes a message. It also did it with a sample Java client publishing to Rabbit.

[mateodelnorte]

You're running all of your processes from a single directory. If you're letting servicebus define the queue name that will be provided to your process from rabbitmq, all of your processes are going to serialize that queue name to the same .queues file for persistence. This is done because, if your process crashes and restarts, and you didn't provide a specific queue name, your process needs to know what the random was last time.

Either run your processes from different directories, pass on different .queueFileLocations to each, or manually specify the queueName on your subscriptions and add a unique identifier per process which will survive a restart.

[mateodelnorte]

I need to update the docs to make the relationship between all these more clear. Happy to field any PRs for that.

[javadevmtl]

Btw same happened in docker containers.

Ok I'll see if I can do PR.

[mateodelnorte]

Guessing the docker containers were linking to the same location on disk?

[mateodelnorte]

You can give each a different queuesFile name when instantiating your bus: https://github.com/mateodelnorte/servicebus/blob/900ad5a77985425f2a172bf5bc67bdad18944376/bus/rabbitmq/bus.js#L34

const bus = require('servicebus').bus({
  queuesFile: `.queues.${process.env.WORKER_ID}`
})

This is useful when you start doing worker pools and need to shard subscribes and listens.

You can provide an exact queue name on subscribe:

bus.subscribe({
  routingKey: 'my.event',
  queueName: `${process.env.PROCESS_NAME}.my.event`
}, (msg) => {
...
})

or you can run from different directories, one per logical project.

[mateodelnorte]

If you want better convention to help guide you toward clean, simple services, use https://github.com/mateodelnorte/servicebus-register-handlers.

[javadevmtl]

My bad! I copied the .queues file into the Docker image :P I now have an entry in .dockerignore

Thanks for the help so far.

[javadevmtl]

Btw the node.js app still exits when it receives a message from the rabbitmq management front end.

http://pastebin.com/1Ab4JCVL

It's dead simple.

[mateodelnorte]

That's because it's not sending JSON and it's causing the JSON parsing code in servicebus to blow up. This is a known architectural issue I'd like to fix in the next version.

On Tue, Feb 28, 2017, 3:35 PM javadevmtl notifications@github.com wrote:

Btw the node.js app still exits when it receives a message from the rabbitmq management front end.

http://pastebin.com/1Ab4JCVL

It's dead simple.

— You are receiving this because you modified the open/close state.

Reply to this email directly, view it on GitHub https://github.com/mateodelnorte/servicebus/issues/89#issuecomment-283153165, or mute the thread https://github.com/notifications/unsubscribe-auth/AAh3X7gfA5TsU_cDVAzLvs4pdgcqIrFgks5rhIUqgaJpZM4MObNQ .

[mateodelnorte]

There's actually an issue for this already, if you want to +1 it.