RabbitMQ 2.0.0 is out. This is a major release and introduces several new features. http://www.rabbitmq.com/news.html#2010-11-30T00:00:00Z Reproducible: Always
You probably wanted to say 2.2.0 is out :)
(In reply to comment #1) > You probably wanted to say 2.2.0 is out :) > Ah, right. Thanks.
Upstream release is 2.3.1 currently.
Created attachment 261997 [details] rabbitmq-server-2.3.1.ebuild This works for me. A simple rename, but I elected to rework the python dependency to require at least python 2.6. Since Python 2.6 includes simplejson, that dependency was dropped.
*** Bug 343269 has been marked as a duplicate of this bug. ***
RabbitMQ 2.4.0 is out: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2011-March/011985.html Releases 2.2.0-2.4.0 introduced quite a few nice features: http://www.rabbitmq.com/changelog.html It would be nice if we had a more recent RMQ in Portage.
(In reply to comment #6) Previous release were easy to bump, but 2.4.0 removed the rabbitmq-multi startup script in favor of only having a single rabbitmq-server script, which also does not fork. This means that the really nice multi-node-capable startup handling introduced previously needs to be "ported". :/ Since I personally don't need multiple nodes on the same host I have rigged up a working fix for 2.4.0 using start-stop-daemon for start and rabbitmqctl for stopping, but it feels hackish. Other than that it works fine, just as usual. My modified startup script is attached.
Created attachment 267049 [details] Modified init script for rabbitmq-2.4.0
(In reply to comment #7) > (In reply to comment #6) > > Previous release were easy to bump, but 2.4.0 removed the rabbitmq-multi > startup script in favor of only having a single rabbitmq-server script, which > also does not fork. This means that the really nice multi-node-capable startup > handling introduced previously needs to be "ported". :/ > Since I personally don't need multiple nodes on the same host I have rigged up > a working fix for 2.4.0 using start-stop-daemon for start and rabbitmqctl for > stopping, but it feels hackish. Other than that it works fine, just as usual. > My modified startup script is attached. Hold on. Isn't "rabbitmq-server -detached" good enough? That's what "rabbitmq-multi start_all N" effectively did when N == 1.
(In reply to comment #7) > (In reply to comment #6) > > Previous release were easy to bump, but 2.4.0 removed the rabbitmq-multi > startup script in favor of only having a single rabbitmq-server script, which > also does not fork. This means that the really nice multi-node-capable startup > handling introduced previously needs to be "ported". :/ Yes, being able to start up multiple nodes with one command was useful, but it's been broken for quite a bit (since 2.3.0 at least). Rabbitmq-multi had a tendency to break in unexpected ways either when starting the nodes or when shutting them down. There's a new "reference" init script that does not use rabbitmq-multi: http://hg.rabbitmq.com/rabbitmq-server/file/rabbitmq_v2_4_0/packaging/common/rabbitmq-server.init
(In reply to comment #9) > Hold on. Isn't "rabbitmq-server -detached" good enough? That's what > "rabbitmq-multi start_all N" effectively did when N == 1. I don't see that flag anywhere; was probably removed too.
(In reply to comment #11) > (In reply to comment #9) > > Hold on. Isn't "rabbitmq-server -detached" good enough? That's what > > "rabbitmq-multi start_all N" effectively did when N == 1. > > I don't see that flag anywhere; was probably removed too. http://www.rabbitmq.com/man/rabbitmq-server.1.man.html
(In reply to comment #12) > (In reply to comment #11) > > (In reply to comment #9) > > > Hold on. Isn't "rabbitmq-server -detached" good enough? That's what > > > "rabbitmq-multi start_all N" effectively did when N == 1. > > > > I don't see that flag anywhere; was probably removed too. > > http://www.rabbitmq.com/man/rabbitmq-server.1.man.html man pages can be wrong ;) -detached is a standard erl flag, not part of the script where I looked. But that does not really fix the original problem either. Maybe I'll take a look at the reference script tomorrow.
(In reply to comment #13) > (In reply to comment #12) > > (In reply to comment #11) > > > (In reply to comment #9) > > > > Hold on. Isn't "rabbitmq-server -detached" good enough? That's what > > > > "rabbitmq-multi start_all N" effectively did when N == 1. > > > > > > I don't see that flag anywhere; was probably removed too. > > > > http://www.rabbitmq.com/man/rabbitmq-server.1.man.html > > man pages can be wrong ;) -detached is a standard erl flag, not part of the > script where I looked. But that does not really fix the original problem > either. > Maybe I'll take a look at the reference script tomorrow. They can be wrong, but this one isn't. The script works as expected both in 2.4.0 and on the default hg branch. I'm not sure I understand the problem, then. Rabbitmq-server -detached starts up a rabbitmq node detached from the current terminal. It starts the erlang runtime as a daemon. Isn't this what we want?
(In reply to comment #14) > I'm not sure I understand the problem, then. Rabbitmq-server -detached starts > up a rabbitmq node detached from the current terminal. It starts the erlang > runtime as a daemon. Isn't this what we want? Yes, sorry for not being more clear. What I meant was that the calling init script should have a way to properly detect startup failures instead of just doing a blind fire-and-forget start. It seems that the init script in hg does that.
(In reply to comment #15) > Yes, sorry for not being more clear. What I meant was that the calling init > script should have a way to properly detect startup failures instead of just > doing a blind fire-and-forget start. It seems that the init script in hg does > that. Ah, sorry for misunderstanding; I don't usually have to deal with init scripts.
2.4.0 in cvs, thanks
(In reply to comment #17) > 2.4.0 in cvs, thanks 2.4.1 is coming out in about an hour and it fixes some really nasty upgrade bugs present int 2.4.0. Ah well, I'll file a new bug for that. Cheers.
