We'll be making a 2.8.0 release of RabbitMQ soon (hopefully early next week), but I'd like to experiment with making preview or RC releases. So here's one.
The version is marked as 2.7.9 just because there are all sorts of restrictions on how we can number things (e.g. IIRC 2.8.0rc1 or whatever I think would stop the Windows installer from working). But think of it as a release candidate.
The intent is that this will be really quite close to the final release - this isn't so much a beta as a search for last minute showstoppers. If there aren't any such showstoppers then this may be identical to the 2.8.0 release. But I wouldn't put it into production myself. You might be braver ;-)
On Thu, Mar 8, 2012 at 6:55 PM, Simon MacMullen <si...@rabbitmq.com> wrote: > Hi all.
> We'll be making a 2.8.0 release of RabbitMQ soon (hopefully early next > week), but I'd like to experiment with making preview or RC releases. So > here's one.
> The version is marked as 2.7.9 just because there are all sorts of > restrictions on how we can number things (e.g. IIRC 2.8.0rc1 or whatever I > think would stop the Windows installer from working). But think of it as a > release candidate.
> The intent is that this will be really quite close to the final release - > this isn't so much a beta as a search for last minute showstoppers. If > there aren't any such showstoppers then this may be identical to the 2.8.0 > release. But I wouldn't put it into production myself. You might be braver > ;-)
On Fri, Mar 9, 2012 at 6:55 AM, Simon MacMullen <si...@rabbitmq.com> wrote: > Hi all.
> We'll be making a 2.8.0 release of RabbitMQ soon (hopefully early next > week), but I'd like to experiment with making preview or RC releases. So > here's one.
> The version is marked as 2.7.9 just because there are all sorts of > restrictions on how we can number things (e.g. IIRC 2.8.0rc1 or whatever I > think would stop the Windows installer from working). But think of it as a > release candidate.
> The intent is that this will be really quite close to the final release - > this isn't so much a beta as a search for last minute showstoppers. If > there aren't any such showstoppers then this may be identical to the 2.8.0 > release. But I wouldn't put it into production myself. You might be braver > ;-)
On Thu, Mar 8, 2012 at 6:55 PM, Simon MacMullen <si...@rabbitmq.com> wrote: > Hi all.
> We'll be making a 2.8.0 release of RabbitMQ soon (hopefully early next > week), but I'd like to experiment with making preview or RC releases. So > here's one.
> The version is marked as 2.7.9 just because there are all sorts of > restrictions on how we can number things (e.g. IIRC 2.8.0rc1 or whatever I > think would stop the Windows installer from working). But think of it as a > release candidate.
> The intent is that this will be really quite close to the final release - > this isn't so much a beta as a search for last minute showstoppers. If there > aren't any such showstoppers then this may be identical to the 2.8.0 > release. But I wouldn't put it into production myself. You might be braver > ;-)
On Thu, Mar 8, 2012 at 18:55, Simon MacMullen <si...@rabbitmq.com> wrote: > Hi all.
> We'll be making a 2.8.0 release of RabbitMQ soon (hopefully early next > week), but I'd like to experiment with making preview or RC releases. So > here's one.
> The version is marked as 2.7.9 just because there are all sorts of > restrictions on how we can number things (e.g. IIRC 2.8.0rc1 or whatever I > think would stop the Windows installer from working). But think of it as a > release candidate.
> The intent is that this will be really quite close to the final release - > this isn't so much a beta as a search for last minute showstoppers. If > there aren't any such showstoppers then this may be identical to the 2.8.0 > release. But I wouldn't put it into production myself. You might be braver > ;-)
Simon MacMullen <si...@rabbitmq.com> writes: > Please, have a play with this and let us know if anything goes wrong > for you...
One more problem: I get random failures with a test using STOMP and one topic.
Here is the test scenario: - two consumers (independent processes) are started on one topic - after a bit of time (to get the SUBSCRIBE+RECEIPT frames): two producers (independent processes) are started and send 5 messages each to the same topic - consumers end when they stop receiving new messages for several seconds - each consumer should have received 15 messages
Sometimes both consumers do get 15 messages but sometimes they get less. The number of messages received varies: 15, 13, 12, 9... The same test seems to work fine against RabbitMQ 2.7.1.
FWIW, I included a trace of what happens (including STOMP frames) for one failure.
Cheers,
Lionel
# 2012/03/12-14:04:34 msak[10628]: incoming = broker (stomp://mybroker:6163) # 2012/03/12-14:04:34 msak[10628]: Net::STOMP::Client->connect() # 2012/03/12-14:04:34 msak[10628]: encoded CONNECT frame # 2012/03/12-14:04:34 msak[10628]: H passcode:guest # 2012/03/12-14:04:34 msak[10628]: H accept-version:1.0,1.1 # 2012/03/12-14:04:34 msak[10628]: H login:guest # 2012/03/12-14:04:34 msak[10628]: H host:rabbitmq # 2012/03/12-14:04:34 msak[10628]: sent 74 bytes # 2012/03/12-14:04:34 msak[10629]: incoming = broker (stomp://mybroker:6163) # 2012/03/12-14:04:34 msak[10628]: received 100 bytes # 2012/03/12-14:04:34 msak[10628]: decoding CONNECTED frame # 2012/03/12-14:04:34 msak[10628]: H session:session-glmUUf49by_vwgLIsfaaQ6 # 2012/03/12-14:04:34 msak[10628]: H heart-beat:0,0 # 2012/03/12-14:04:34 msak[10628]: H server:RabbitMQ/2.7.9 # 2012/03/12-14:04:34 msak[10628]: H version:1.1 # 2012/03/12-14:04:34 msak[10629]: Net::STOMP::Client->connect() # 2012/03/12-14:04:34 msak[10629]: encoded CONNECT frame # 2012/03/12-14:04:34 msak[10629]: H passcode:guest # 2012/03/12-14:04:34 msak[10629]: H accept-version:1.0,1.1 # 2012/03/12-14:04:34 msak[10629]: H login:guest # 2012/03/12-14:04:34 msak[10629]: H host:rabbitmq # 2012/03/12-14:04:34 msak[10629]: sent 74 bytes # 2012/03/12-14:04:34 msak[10629]: received 100 bytes # 2012/03/12-14:04:34 msak[10629]: decoding CONNECTED frame # 2012/03/12-14:04:34 msak[10629]: H session:session-A8juhJ2SqmlAJcIkjrdiS2 # 2012/03/12-14:04:34 msak[10629]: H heart-beat:0,0 # 2012/03/12-14:04:34 msak[10629]: H server:RabbitMQ/2.7.9 # 2012/03/12-14:04:34 msak[10629]: H version:1.1 # 2012/03/12-14:04:34 msak[10628]: Net::STOMP::Client->subscribe() # 2012/03/12-14:04:34 msak[10628]: encoded SUBSCRIBE frame # 2012/03/12-14:04:34 msak[10628]: H destination:/topic/test.mbtf.bb.d9d20365 # 2012/03/12-14:04:34 msak[10628]: H id:94e6630-4f5df462-2984-6902-2 # 2012/03/12-14:04:34 msak[10628]: H receipt:94e6630-4f5df462-2984-6902-1 # 2012/03/12-14:04:34 msak[10628]: sent 122 bytes # 2012/03/12-14:04:34 msak[10628]: now waiting for the missing receipts # 2012/03/12-14:04:34 msak[10629]: Net::STOMP::Client->subscribe() # 2012/03/12-14:04:34 msak[10629]: encoded SUBSCRIBE frame # 2012/03/12-14:04:34 msak[10629]: H destination:/topic/test.mbtf.bb.d9d20365 # 2012/03/12-14:04:34 msak[10629]: H id:8978630-4f5df462-2985-ab87-2 # 2012/03/12-14:04:34 msak[10629]: H receipt:8978630-4f5df462-2985-ab87-1 # 2012/03/12-14:04:34 msak[10629]: sent 122 bytes # 2012/03/12-14:04:34 msak[10629]: now waiting for the missing receipts # 2012/03/12-14:04:34 msak[10628]: received 50 bytes # 2012/03/12-14:04:34 msak[10628]: decoding RECEIPT frame # 2012/03/12-14:04:34 msak[10628]: H receipt-id:94e6630-4f5df462-2984-6902-1 # 2012/03/12-14:04:34 msak[10628]: start # 2012/03/12-14:04:34 msak[10629]: received 50 bytes # 2012/03/12-14:04:34 msak[10629]: decoding RECEIPT frame # 2012/03/12-14:04:34 msak[10629]: H receipt-id:8978630-4f5df462-2985-ab87-1 # 2012/03/12-14:04:34 msak[10629]: start # 2012/03/12-14:04:35 msak[10628]: received 0 bytes # 2012/03/12-14:04:35 msak[10628]: got no message (no frames received) # 2012/03/12-14:04:35 msak[10629]: received 0 bytes # 2012/03/12-14:04:35 msak[10629]: got no message (no frames received) # 2012/03/12-14:04:36 msak[10632]: incoming = generator # 2012/03/12-14:04:36 msak[10632]: outgoing = broker (stomp://mybroker:6163) # 2012/03/12-14:04:36 msak[10628]: received 0 bytes # 2012/03/12-14:04:36 msak[10628]: got no message (no frames received) # 2012/03/12-14:04:36 msak[10632]: Net::STOMP::Client->connect() # 2012/03/12-14:04:36 msak[10629]: received 0 bytes # 2012/03/12-14:04:36 msak[10629]: got no message (no frames received) # 2012/03/12-14:04:36 msak[10632]: encoded CONNECT frame # 2012/03/12-14:04:36 msak[10632]: H passcode:guest # 2012/03/12-14:04:36 msak[10632]: H accept-version:1.0,1.1 # 2012/03/12-14:04:36 msak[10632]: H login:guest # 2012/03/12-14:04:36 msak[10632]: H host:rabbitmq # 2012/03/12-14:04:36 msak[10632]: sent 74 bytes # 2012/03/12-14:04:36 msak[10632]: received 100 bytes # 2012/03/12-14:04:36 msak[10632]: decoding CONNECTED frame # 2012/03/12-14:04:36 msak[10632]: H session:session-wUavc52XJm4ReMchKZVtor # 2012/03/12-14:04:36 msak[10632]: H heart-beat:0,0 # 2012/03/12-14:04:36 msak[10632]: H server:RabbitMQ/2.7.9 # 2012/03/12-14:04:36 msak[10632]: H version:1.1 # 2012/03/12-14:04:36 msak[10632]: start # 2012/03/12-14:04:36 msak[10632]: got message 1 # 2012/03/12-14:04:36 msak[10632]: outgoing message <no-message-id> # 2012/03/12-14:04:36 msak[10632]: encoded SEND frame # 2012/03/12-14:04:36 msak[10632]: H destination:/topic/test.mbtf.bb.d9d20365 # 2012/03/12-14:04:36 msak[10632]: H content-length:1 # 2012/03/12-14:04:36 msak[10632]: B 0000 31 1 # 2012/03/12-14:04:36 msak[10632]: sent 66 bytes # 2012/03/12-14:04:36 msak[10632]: got message 2 # 2012/03/12-14:04:36 msak[10628]: received 188 bytes # 2012/03/12-14:04:36 msak[10629]: received 188 bytes # 2012/03/12-14:04:36 msak[10628]: decoding MESSAGE frame # 2012/03/12-14:04:36 msak[10629]: decoding MESSAGE frame # 2012/03/12-14:04:36 msak[10628]: H subscription:94e6630-4f5df462-2984-6902-2 # 2012/03/12-14:04:36 msak[10629]: H subscription:8978630-4f5df462-2985-ab87-2 # 2012/03/12-14:04:36 msak[10628]: H destination:/topic/test.mbtf.bb.d9d20365 # 2012/03/12-14:04:36 msak[10629]: H destination:/topic/test.mbtf.bb.d9d20365 # 2012/03/12-14:04:36 msak[10628]: H message-id:T_94e6630-4f5df462-2984-6902-2@@session-glmUUf49by_vwgLIsfaaQ6@@ 1 # 2012/03/12-14:04:36 msak[10629]: H message-id:T_8978630-4f5df462-2985-ab87-2@@session-A8juhJ2SqmlAJcIkjrdiS2@@ 1 # 2012/03/12-14:04:36 msak[10628]: H content-length:1 # 2012/03/12-14:04:36 msak[10629]: H content-length:1 # 2012/03/12-14:04:36 msak[10628]: B 0000 31 1 # 2012/03/12-14:04:36 msak[10629]: B 0000 31 1 # 2012/03/12-14:04:36 msak[10628]: incoming message T_94e6630-4f5df462-2984-6902-2@@session-glmUUf49by_vwgLIsfaaQ6@@1 # 2012/03/12-14:04:36 msak[10629]: incoming message T_8978630-4f5df462-2985-ab87-2@@session-A8juhJ2SqmlAJcIkjrdiS2@@1 # 2012/03/12-14:04:36 msak[10628]: got message 1 # 2012/03/12-14:04:36 msak[10629]: got message 1 # 2012/03/12-14:04:36 msak[10632]: outgoing message <no-message-id> # 2012/03/12-14:04:36 msak[10632]: encoded SEND frame # 2012/03/12-14:04:36 msak[10632]: H destination:/topic/test.mbtf.bb.d9d20365 # 2012/03/12-14:04:36 msak[10632]: H content-length:1 # 2012/03/12-14:04:36 msak[10632]: B 0000 32 2 # 2012/03/12-14:04:36 msak[10632]: sent 66 bytes # 2012/03/12-14:04:36 msak[10632]: got message 3 # 2012/03/12-14:04:36 msak[10632]: outgoing message <no-message-id> # 2012/03/12-14:04:36 msak[10632]: encoded SEND frame # 2012/03/12-14:04:36 msak[10632]: H destination:/topic/test.mbtf.bb.d9d20365 # 2012/03/12-14:04:36 msak[10632]: H content-length:1 # 2012/03/12-14:04:36 msak[10632]: B 0000 33 3 # 2012/03/12-14:04:36 msak[10632]: sent 66 bytes # 2012/03/12-14:04:36 msak[10632]: got message 4 # 2012/03/12-14:04:36 msak[10632]: outgoing message <no-message-id> # 2012/03/12-14:04:36 msak[10632]: encoded SEND frame # 2012/03/12-14:04:36 msak[10632]: H destination:/topic/test.mbtf.bb.d9d20365 # 2012/03/12-14:04:36 msak[10632]: H content-length:1 # 2012/03/12-14:04:36 msak[10632]: B 0000 34 4 # 2012/03/12-14:04:36 msak[10632]: sent 66 bytes # 2012/03/12-14:04:37 msak[10632]: got message 5 # 2012/03/12-14:04:37 msak[10632]: outgoing message <no-message-id> # 2012/03/12-14:04:37 msak[10632]: encoded SEND frame # 2012/03/12-14:04:37 msak[10632]: H destination:/topic/test.mbtf.bb.d9d20365 # 2012/03/12-14:04:37 msak[10632]: H content-length:1 # 2012/03/12-14:04:37 msak[10632]: B 0000 35 5 # 2012/03/12-14:04:37 msak[10632]: sent 66 bytes # 2012/03/12-14:04:37 msak[10632]: stop # 2012/03/12-14:04:37 msak[10632]: received 0 bytes # 2012/03/12-14:04:37 msak[10632]: Net::STOMP::Client->disconnect() # 2012/03/12-14:04:37 msak[10632]: encoded DISCONNECT frame # 2012/03/12-14:04:37 msak[10632]: sent 13 bytes # 2012/03/12-14:04:37 msak[10628]: received 188 bytes # 2012/03/12-14:04:37 msak[10628]: decoding MESSAGE frame # 2012/03/12-14:04:37 msak[10629]: received 376 bytes # 2012/03/12-14:04:37 msak[10628]: H subscription:94e6630-4f5df462-2984-6902-2 # 2012/03/12-14:04:37 msak[10629]: decoding MESSAGE frame # 2012/03/12-14:04:37 msak[10628]: H destination:/topic/test.mbtf.bb.d9d20365 # 2012/03/12-14:04:37 msak[10629]: H subscription:8978630-4f5df462-2985-ab87-2 # 2012/03/12-14:04:37 msak[10628]: H message-id:T_94e6630-4f5df462-2984-6902-2@@session-glmUUf49by_vwgLIsfaaQ6@@ 2 # 2012/03/12-14:04:37 msak[10629]: H destination:/topic/test.mbtf.bb.d9d20365 # 2012/03/12-14:04:37 msak[10628]: H
...
> Unfortunately you can't see the 2.8.0 website :-(
Maybe it should be exposed to help people testing your pre-releases?
> You will need to set {ssl_cert_login, true} in your rabbitmq_stomp > configuration and make sure the client does not send login and passcode > headers.
> Maybe it should be exposed to help people testing your pre-releases?
Yes, just another thing for the TODO...
> > You will need to set {ssl_cert_login, true} in your rabbitmq_stomp > > configuration and make sure the client does not send login and passcode > > headers.
> Done. I still get the same error :-( <snip> > Any hint?
Damn, it looks like you need some default_user details defined for this to work. (They can be invalid credentials: they will not be used, they just need to exist.)
> Damn, it looks like you need some default_user details defined for this > to work. (They can be invalid credentials: they will not be used, they > just need to exist.)
Indeed, adding a default_user seems to work. It would be nice if this "hack" could be removed.
However, I've only progressed a tiny bit. I now get:
This is perfect... I just setup three clusters that will be federated amongst each other for experimentation and discovered I needed x-ha-policy queues. This release has support for that! :)
I just upgraded all 9 boxes and will be setting up my test runs soon, I'll let you know how it goes. :)
On Wed, Mar 14, 2012 at 9:25 AM, Simon MacMullen <si...@rabbitmq.com> wrote: > On 14/03/12 14:09, Lionel Cons wrote:
>> Maybe it should be exposed to help people testing your pre-releases?
> Yes, just another thing for the TODO...
>> > You will need to set {ssl_cert_login, true} in your rabbitmq_stomp >> > configuration and make sure the client does not send login and >> passcode >> > headers.
>> Done. I still get the same error :-(
> <snip>
>> Any hint?
> Damn, it looks like you need some default_user details defined for this to > work. (They can be invalid credentials: they will not be used, they just > need to exist.)
The "hack" will no longer be required in the next release; thanks for spotting this.
Logging ssl detail is a little scary; though the log could add some more information. We'll improve that.
The DN/CN issues were discussed recently, but I'll leave it to Simon to explain our position on that.
Cheers,
Steve Powell (a cheery bunny) ----------some more definitions from the SPD---------- chinchilla (n.) Cooling device for the lower jaw. socialcast (n.) Someone to whom everyone is speaking but nobody likes.
> Simon MacMullen writes: >> Damn, it looks like you need some default_user details defined for this >> to work. (They can be invalid credentials: they will not be used, they >> just need to exist.)
> Indeed, adding a default_user seems to work. It would be nice if this > "hack" could be removed.
> However, I've only progressed a tiny bit. I now get:
> Logging ssl detail is a little scary; though the log could add some more > information. We'll improve that.
Bah. I thought this was getting pushed through a generic login function that would log failures. But no. Clearly the username should end up somewhere.
> The DN/CN issues were discussed recently, but I'll leave it to Simon to > explain our position on that.
It defaults to doing the best impersonation it can of a DN produced by the OpenSSL's -nameopt RFC2253, and can be switched to using (a concatenation of) the CN(s) with:
{rabbit, [{ssl_cert_login_from, common_name}]}
So if there's one thing I've learnt from this preview release thing, it's that we also need a preview release of all the documentation. Hmm...
Not sure if this is a bug in the 2.7.9 release or not, but I am having some problems consuming messages sent on an upstream broker by the downstream broker cluster. Here is the error log I keep getting:
** Generic server <0.12040.0> terminating ** Last message in was {{'basic.deliver', <<"amq.ctag-QLSHVB2QsF_PaKWvb99rv1">>,1,true, <<"usage">>,<<"foo.bar">>}, {amqp_msg, {'P_basic',undefined,undefined,[],1,undefined, undefined,undefined,undefined,undefined, undefined,undefined,undefined,undefined, undefined}, <<"Hello!">>}} ** When Server state == {state, {upstream, {amqp_params_network,<<"guest">>,<<"guest">>, <<"/">>,dc2tcserver2,undefined,0,0,1,infinity,none, [#Fun<amqp_auth_mechanisms.plain.3>, #Fun<amqp_auth_mechanisms.amqplain.3>], [],[]}, <<"usage">>,none,5,1,none,10000,"all", "dc2tcserver2"}, <0.12054.0>,<0.12064.0>, <<"federation: usage -> rabbit@dc2rabbitmq3">>, <<"federation: usage -> rabbit@dc2rabbitmq3 A">>, {0,nil}, 2, {dict,1,16,16,8,80,48, {[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[]}, {{[],[],[],[],[], [[{<<"#">>,[]}| {set,1,16,16,8,80,48, {[],[],[],[],[],[],[],[],[],[],[],[],[],[],[], []}, {{[],[],[],[],[], [{resource,<<"/">>,queue,<<"pit.stop">>}], [],[],[],[],[],[],[],[],[],[]}}}]], [],[],[],[],[],[],[],[],[],[]}}}, <0.12042.0>,<0.12049.0>, {resource,<<"/">>,exchange,<<"usage">>}, {0,nil}} ** Reason for termination == ** {badarg,[{erlang,list_to_binary,[dc2tcserver2]}, {rabbit_federation_upstream,to_table,1}, {rabbit_federation_link,handle_info,2}, {gen_server2,handle_msg,2}, {proc_lib,init_p_do_apply,3}]}
Only difference is the upstream server is running 2.7.1.
On Thu, Mar 15, 2012 at 12:00 PM, Simon MacMullen <si...@rabbitmq.com> wrote: > On 15/03/12 11:44, Steve Powell wrote:
>> Logging ssl detail is a little scary; though the log could add some more >> information. We'll improve that.
> Bah. I thought this was getting pushed through a generic login function that > would log failures. But no. Clearly the username should end up somewhere.
>> The DN/CN issues were discussed recently, but I'll leave it to Simon to >> explain our position on that.
> It defaults to doing the best impersonation it can of a DN produced by the > OpenSSL's -nameopt RFC2253, and can be switched to using (a concatenation > of) the CN(s) with:
> {rabbit, [{ssl_cert_login_from, common_name}]}
> So if there's one thing I've learnt from this preview release thing, it's > that we also need a preview release of all the documentation. Hmm...
On Thu, Mar 15, 2012 at 2:37 PM, James Carr <james.r.c...@gmail.com> wrote: > Not sure if this is a bug in the 2.7.9 release or not, but I am having > some problems consuming messages sent on an upstream broker by the > downstream broker cluster. Here is the error log I keep getting:
> Only difference is the upstream server is running 2.7.1.
> Thanks, > James
> On Thu, Mar 15, 2012 at 12:00 PM, Simon MacMullen <si...@rabbitmq.com> wrote: >> On 15/03/12 11:44, Steve Powell wrote:
>>> Logging ssl detail is a little scary; though the log could add some more >>> information. We'll improve that.
>> Bah. I thought this was getting pushed through a generic login function that >> would log failures. But no. Clearly the username should end up somewhere.
>>> The DN/CN issues were discussed recently, but I'll leave it to Simon to >>> explain our position on that.
>> It defaults to doing the best impersonation it can of a DN produced by the >> OpenSSL's -nameopt RFC2253, and can be switched to using (a concatenation >> of) the CN(s) with:
>> {rabbit, [{ssl_cert_login_from, common_name}]}
>> So if there's one thing I've learnt from this preview release thing, it's >> that we also need a preview release of all the documentation. Hmm...
On Thu, Mar 15, 2012 at 2:38 PM, James Carr <james.r.c...@gmail.com> wrote: > FYI, I will try upgrading the upstream and see if the problem persists.
> Thanks, > James
> On Thu, Mar 15, 2012 at 2:37 PM, James Carr <james.r.c...@gmail.com> wrote: >> Not sure if this is a bug in the 2.7.9 release or not, but I am having >> some problems consuming messages sent on an upstream broker by the >> downstream broker cluster. Here is the error log I keep getting:
>> Only difference is the upstream server is running 2.7.1.
>> Thanks, >> James
>> On Thu, Mar 15, 2012 at 12:00 PM, Simon MacMullen <si...@rabbitmq.com> wrote: >>> On 15/03/12 11:44, Steve Powell wrote:
>>>> Logging ssl detail is a little scary; though the log could add some more >>>> information. We'll improve that.
>>> Bah. I thought this was getting pushed through a generic login function that >>> would log failures. But no. Clearly the username should end up somewhere.
>>>> The DN/CN issues were discussed recently, but I'll leave it to Simon to >>>> explain our position on that.
>>> It defaults to doing the best impersonation it can of a DN produced by the >>> OpenSSL's -nameopt RFC2253, and can be switched to using (a concatenation >>> of) the CN(s) with:
> Here's my configuration file for the downstream server: > {host, 'dc2tcserver1'},
This is, I'm afraid, the problem.
In the configuration file, single and double quotes have different meanings - double quotes delimit strings, while single quotes optionally delimit atoms. You need a string there.
Yes, this is confusing. Not sure what the solution is.
James FWIW an thing to be mindful of in Erlang code or terms is that double quotes, e.g. "foo", get used for strings, or lists of characters, while single quotes are used for Erlang atoms, e.g. 'foo'.
You could write 'foo' as just foo with no adornment... you typically use the single quotes if your atom name contains characters that are allowed in atom names, but that would otherwise trip up the Erlang parser.
For e.g. foo-bar will look like an arithmetic operation trying to nonsensically subtract atom bar from atom foo, while if you wrap it as 'foo-bar' you disabuse the parser of its base instincts.
These are really easy to not spot when one's either sleepy, or feeding data to something whose expectations aren't yet familiar...
----- Original Message ----- From: "Simon MacMullen" <si...@rabbitmq.com> To: "James Carr" <james.r.c...@gmail.com>
Cc: rabbitmq-disc...@lists.rabbitmq.com Sent: Friday, March 16, 2012 3:46:53 AM Subject: Re: [rabbitmq-discuss] Experimenting with release candidates: RabbitMQ 2.7.9
On 15/03/12 19:44, James Carr wrote: > Here's my configuration file for the downstream server: > {host, 'dc2tcserver1'},
This is, I'm afraid, the problem.
In the configuration file, single and double quotes have different meanings - double quotes delimit strings, while single quotes optionally delimit atoms. You need a string there.
Yes, this is confusing. Not sure what the solution is.
> > The DN/CN issues were discussed recently, but I'll leave it to Simon to > > explain our position on that. > > It defaults to doing the best impersonation it can of a DN produced by > the OpenSSL's -nameopt RFC2253 [...]
Simon,
I confirm that this works fine in 2.8.0. However, the user that is required (which name is the DN) also allows to login without SSL.
One solution would be to generate long random passwords for these dummy users indicating which DNs are allowed but this looks like bricolage. What about using the (currently underused) tags for this purpose? We could imagine an "ssl" tag meaning "this user can only login via SSL"...
> I confirm that this works fine in 2.8.0. However, the user that is required > (which name is the DN) also allows to login without SSL.
You can disable password-based login for a user altogether, for exactly this reason. Either select "No password" in mgmt, or use "rabbitmqctl clear_password".
> On Thu, Mar 8, 2012 at 6:55 PM, Simon MacMullen <si...@rabbitmq.com> > wrote:
>> Hi all.
>> We'll be making a 2.8.0 release of RabbitMQ soon (hopefully early next >> week), but I'd like to experiment with making preview or RC releases. So >> here's one.
>> The version is marked as 2.7.9 just because there are all sorts of >> restrictions on how we can number things (e.g. IIRC 2.8.0rc1 or whatever >> I >> think would stop the Windows installer from working). But think of it as >> a >> release candidate.
>> The intent is that this will be really quite close to the final release - >> this isn't so much a beta as a search for last minute showstoppers. If >> there aren't any such showstoppers then this may be identical to the >> 2.8.0 >> release. But I wouldn't put it into production myself. You might be >> braver >> ;-)
