Automatic reconnects

[Dave Syer]

If you're not using RabbitAdmin how do you know the queues and bindings are declared? It's fine if you want to go that way (and want to fail if the queue is missing), but I'm just pointing out that it's there and has very low overhead and few side effects (beyond declaring stuff that you know you are going to use anyway). One of the main features of AMQP is supposed to be that the clients control the broker.

If you manually create a tag, you have to use "git push tag <tag name>" or "git push --tags". Only branches are pushed if you don't specify tag or --tags.

I know. Maybe you have to fetch the tags (git fetch --tags) as well, or if you haven't even got that commit then you probably haven't fetched it either. There's no branch, so maybe git doesn't fetch it by default? I see it on github, so I know it's there. If we need to create a branch we can do that.

[zzantozz]

If you're not using RabbitAdmin how do you know the queues and bindings are declared? It's fine if you want to go that way (and want to fail if the queue is missing), but I'm just pointing out that it's there and has very low overhead and few side effects (beyond declaring stuff that you know you are going to use anyway). One of the main features of AMQP is supposed to be that the clients control the broker.

Okay, I'll look into that. Thanks for the tip. I've only been doing some testing against a local RabbitMQ server that I'm running, and I've been declaring and removing queues myself with the RabbitMQ Java client to figure out how things work. I don't know what the real, production instance is going to look like yet or what I'm supposed to or have permission to do on it.

I know. Maybe you have to fetch the tags (git fetch --tags) as well, or if you haven't even got that commit then you probably haven't fetched it either. There's no branch, so maybe git doesn't fetch it by default? I see it on github, so I know it's there. If we need to create a branch we can do that.

You're right. I was only fetching branches. Is there a particular reason that 1.0.0.M3 isn't merged into master? I wasn't expecting a tag that wasn't merged into mainline development. Before we go there, though, there's a bigger problem: your tag doesn't match your artifacts. I assume that you did the maven release and moved the tag manually afterward, since the maven release happened at 83f0f48db2471cfcf9035dca4849029924d4f27c, and the artifacts look like they match that commit. Why isn't the tag there? If it was moved to include some critical fixes, which seems likely from the apparent rebase of several commits, then those fixes didn't make it into the artifacts, and the tag is just misleading. If you need to get more fixes out, make a 1.0.0.M4. Whatever the case, I strongly recommend moving the tag back to its correct location--where the artifacts were actually released--to avoid more confusion in the future.

[Dave Syer]

The tag was moved after the artifacts were first deployed but before the release was announced. If you don't have artifacts that match that commit then you must have downloaded them before the announcement. I know it's not perfect, and we wouldn't have done it if it wasn't a milestone.

[zzantozz]

The tag was moved after the artifacts were first deployed but before the release was announced. If you don't have artifacts that match that commit then you must have downloaded them before the announcement. I know it's not perfect, and we wouldn't have done it if it wasn't a milestone.

I see. That means it's cached in our Nexus repo as well... Is M4 or RC1 coming soon? I'd as soon just move on as have to go clean up. Besides, the auto-reconnect isn't working in M3, and it'd be nice to have a release to point at for my own upcoming release instead of working from a snapshot.

[Dave Syer]

RC1 will be as soon as we get the issues cleared away (all contributions gratefully accepted). We aim to do it by end of March at the latest.