[rabbitmq-discuss] Erlang has closed?

[Brian_Fox]

Matthew Sackman wrote:
> 
> On Wed, May 19, 2010 at 11:06:23AM -0400, Tyler Williams wrote:
>> =INFO REPORT==== 17-May-2010::14:24:30 ===
>>     application: rabbit
>>     exited: {{timeout_waiting_for_tables,[rabbit_disk_queue]},
>>              {rabbit,start,[normal,[]]}}
>>     type: temporary
>> 
>> =ERROR REPORT==== 17-May-2010::14:24:30 ===
>> Error in process <0.100.0> on node 'rabbit at echonest03' with exit
>> value:
>> {badarg,[{ets,insert,[rabbit_disk_queue,[{dq_msg_loc,{{resource,<<1
>> byte>>,queue,<<9 bytes>>},553567},false,true,<<16
>> bytes>>},{dq_msg_loc,{{resource,<<1 byte>>,queue,<<18
>> bytes>>},563611},false,true,<<16 bytes>>},{dq_msg_loc,{{resource,<<1
>> byte>>,queue,<<18 bytes>>},80964},false,true,<<16
>> bytes>>},{dq_msg_loc,{{resource,<<1 byte>>,queue...
>> 
>> 
>> =INFO REPORT==== 17-May-2010::14:24:33 ===
>>     application: mnesia
>>     exited: stopped
>>     type: temporary
>> 
>> =INFO REPORT==== 17-May-2010::14:24:33 ===
>>     application: os_mon
>>     exited: stopped
>>     type: temporary
>> 
>> Can you shed any light on this error?
> 
> I might have been able to last October when I was writing that code. So
> much has changed since then that I really can't remember too much about
> what was going on back then.
> 
> Also, pyamqplib does not support channel.flow. Even with the new
> persister, there are times where rabbit gets overwhelmed (disks just
> aren't fast enough most of the time) and so needs to temporarily stop
> publishers. It does this by using channel.flow. Given that pyamqplib
> doesn't support channel.flow, you are very likely to run into problems.
> There's a highly experimental patch by Tony (search the mailing list for
> it) which adds support for channel.flow, but you might also try looking
> at the other python clients such as txamqp and pika.
> 
> Matthew
> 

(Sorry to resurrect an older thread)

Has this rabbitmq + pyamqplib problem ever been resolved?  

Our group is experimenting with bringing up a massive amount of AMQP clients
using EC2.  And we're running into the same error described above,
presumably slamming memory on the broker.  It seems like we have a few
choices: bump up the memory (8GB currently), choose a different library with
flow control, or choose a different strategy to rapidly boot several hundred
clients.  Of the three, the last would be the least attractive option.

Any suggestions on the best alternative lib to avoid this error?  I'm
hearing mixed things about txAMQP's support of channel flow.  

Would clustering help the issue or make it worse?  (we're currently a single
broker on a development platform)

Thanks much,
Brian  
-- 
View this message in context: http://old.nabble.com/Erlang-has-closed--tp28600093p29827331.html
Sent from the RabbitMQ mailing list archive at Nabble.com.