[rabbitmq-discuss] Experimenting with release candidates: RabbitMQ 2.7.9
James Carr
james.r.carr at gmail.com
Thu Mar 15 19:37:37 GMT 2012
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 at dc2rabbitmq3">>,
<<"federation: usage -> rabbit at 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.
Thanks,
James
On Thu, Mar 15, 2012 at 12:00 PM, Simon MacMullen <simon at 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...
>
>
> Cheers, Simon
>
> --
> Simon MacMullen
> RabbitMQ, VMware
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
More information about the rabbitmq-discuss
mailing list