[rabbitmq-discuss] Experimenting with release candidates: RabbitMQ 2.7.9

Thu Mar 15 19:44:41 GMT 2012

Upgraded to 2.7.9 on the upstream and the problem persists.

Here's my configuration file for the downstream server:

[
        {rabbit, [
            {cluster_nodes, ['rabbit at dc2rabbitmq3',
'rabbit at dc2rabbitmq4', 'rabbit at dc2rabbitmq5', 'rabbit at dc2rabbitmq6']}
        ]},
        {rabbitmq_federation,
            [ {exchanges, [[{exchange,     "usage"},
                            {virtual_host, "/"},
                            {type,         "topic"},
                            {durable,      true},
                            {auto_delete,  false},
                            {internal,     false},
                            {upstream_set, "remotes"}]
                          ]},
              {upstream_sets, [{"remotes", [
                 [{connection,  "dc2tcserver1"},
                   {exchange,    "usage"},
                   {max_hops,    5}],
                 [{connection,  "dc2tcserver2"},
                   {exchange,    "usage"},
                   {max_hops,    5}]]}]},
              {connections, [
                {"dc2tcserver1", [
                    {host, 'dc2tcserver1'},
                    {heartbeat,       1},
                    {queue_expires,   30000},
                    {message_ttl,     10000},
                    {ha_policy,       "all"}]
                },
                {"dc2tcserver2", [
                    {host, 'dc2tcserver2'},
                    {heartbeat,       1},
                    {queue_expires,   30000},
                    {message_ttl,     10000},
                    {ha_policy,       "all"}]
                }]}
        ]}
].

Is there anything here I might just have off?

Thanks,
James

On Thu, Mar 15, 2012 at 2:38 PM, James Carr <james.r.carr at 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.carr at 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:
>>
>> ** 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