New version

[andresberrios]

New version

[squaremo]

I've seen some interesting and very useful changes in the master branch and I'm wondering when
they will be released, are you close to a new release?
Or otherwise, would you say it's safe to point npm to the master branch directly in the meantime?

I don't think it's safe to point npm at a git repo in general. Lately I've changed my mind back and forth in the master branch, which I ought to have done in a feature branch, so there's an illustration of why not!

I'm not sure about the "resume" stuff yet, so I'll probably not release that for the time being. I may make a release without it, though.

[andresberrios]

Great, thanks!

[squaremo]

I should say that while I don't recommend using git master in your production system, I would be grateful for any reports of using the new features in development

[andresberrios]

Well, for example, we wanted to use one PUB socket to publish messages to different topics according to the current action our application is performing. We were reading the readme in the repo and tried it but later realised that in 0.4.0 it wasn't possible to use them this way. So now we are switching into creating different sockets for the different topics, and closing them after we don't need them anymore. I'm not sure but I think it shouldn't be that bad, since the real connection to the server is actually established when creating the context, right?
Any advice on this?

[andresberrios]

Another thing is that we need our published messages to be stored in a queue so that they are not lost if the SUB socket hasn't connected yet before the PUB socket starts publishing. For now, we are using the HTTP API of RabbitMQ to create the queue (or make sure it's there) when the application starts. Is there a way we can manage queues and/or bindings from rabbit.js? It's not critical, just want to know haha
Thanks!

[squaremo]

So now we are switching into creating different sockets for the different topics, and closing them after we don't need them anymore.

Right, yes that is just the thing #publish and the 'topic' option are designed for.

var pub = ctx.socket('PUBLISH', { routing: topic });
pub.connect('events');
// ...
pub.publish('component.warning', JSON.stringify({foo: "bar"}), 'utf8');

Another thing is that we need our published messages to be stored in a queue so that they are not lost if the SUB socket hasn't connected yet

You would have to create a queue per subscriber, before starting any publishers, which is effectively the same as opening the sub sockets before you start any publishers. There's synchronisation required whatever you do.

RabbitMQ and AMQP won't help you with this, or not much. There's no provision for consumers catching up with old messages. If you cannot miss messages, better to stick them in a database and replay them for new subscribers, although you still have a kind of synchronisation problem (that is, figuring out when to switch from the replayed messages to the freshly-published messages).

[andresberrios]

I see. For now we switched to creating and closing sockets for different topics until there's a new release. Do you think this is going to be a problem in terms of performance or anything like that?
Thanks a lot for the help.

[squaremo]

For now we switched to creating and closing sockets for different topics until there's a new release. Do you think this is going to be a problem in terms of performance or anything like that?

You are right that the connection is created just once; but, each socket still uses its own channel and may require some round-trips to declare various queues and what-have-you, so creating sockets is a little expensive too.

Perhaps I should roll a release with the topic stuff, and put the resume stuff on a branch for later.

[andresberrios]

I see. Well that would be really awesome :D let me know if you do it, since we would change our code accordingly as soon as possible.

[squaremo]

v0.4.1 is published to npm. It has the topic stuff and the persistent option, but not the subscription resume stuff.

[andresberrios]

Amazing! Thanks a lot!