[rabbitmq-discuss] rabbitmq with one producer no consumer

[Ovidiu Deac]

There is one thing though which is wrong: if a memory limit is given
rabbitmq should manage its memory such that it can continue working
properly but doesn't accept any more messages. If the memory limit is
above a certain level the queues should be closed and all the messages
published become unroutable.

This way it would accept connections which extract messages and thus
would free that memory.

On Thu, Jul 15, 2010 at 10:51 PM, Ovidiu Deac <ovidiudeac at gmail.com> wrote:
> I found the problem: the memory limit was the default one which is 1.6
> i.e. 40% out of 4GB. It seems the OS installed is 32bits and this is
> why erlang doesn't see the full 6GB RAM.
>
> Of course the system didn't work if it ran out of memory.
>
> As soon as I changed vm_memory_high_watermark to 0.98 by putting
> [{rabbit, [{vm_memory_high_watermark, 0.98}]}].
> ... in /etc/rabbitmq/rabbitmq.config the problem was fixed
>
> Thanks for the help.
>
> ovidiu
>
> On Thu, Jul 15, 2010 at 8:50 PM, Scott Brooks <scott at beamdog.com> wrote:
>> 200k messages, @ 300 bytes a piece is nothing.
>>
>> I just ran a test and everything is fine for me.
>>
>> Can you re-do the test?  Also what are the specs on the server you are
>> running the test on?
>>
>> Scott
>>
>>
>> On Thu, Jul 15, 2010 at 11:33 AM, Ovidiu Deac <ovidiudeac at gmail.com> wrote:
>>> First of all thanks for the answers. Second I'll explain the situation
>>> a little better.
>>>
>>> The big picture is like this: we receive orders from outside and they
>>> are put in rabbit by our "gateway" and then routed by rabbit to the
>>> processing modules. The whole business is about handling those
>>> messages and if we are unable to receive messages from outside is very
>>> bad so basically our gateway should be up all the time.
>>>
>>> Normally all the orders coming in should be handled smoothly BUT if
>>> something happens to the consumers and they have a downtime the
>>> producer has no way to stop the incoming messages. Also we always want
>>> to be able to accept messages because we are payed for each incoming
>>> message.
>>>
>>> Normally the system admin should handle the problem and restart the
>>> consumers. As I was saying before, we are testing for the worst case
>>> scenario, to see what the limits of RabbitMQ are. We want to see how
>>> can we extend these limits to increase the time we have until the
>>> queues get full.
>>>
>>> From our calculations if rabbitmq could hold 500k messages up to
>>> 300bytes each we would be pretty safe as that would give us enough
>>> time to react. The 200k limit is a little tight.
>>>
>>> ovidiu
>>>
>>>> @Ovidiu:
>>>> BUT, are you really sure you want what you are asking for? If I understand
>>>> you correctly you want to allow outside producers (not under your control)
>>>> to send persistant messages directly into your RabbitMQ and not have those
>>>> producers back off?
>>>>
>>>> Personally, I think that is not achievable. At some point your server ii>
>>>>
>>>> _______________________________________________
>>>> rabbitmq-discuss mailing list
>>>> rabbitmq-discuss at lists.rabbitmq.com
>>>> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>>>>
>>>>
>>>
>>> s
>>>> going to reject messages, and your producers must be able to deal with that,
>>>> if, as you say, no messages are allowed to be lost.
>>>>
>>>> Robby
>>> _______________________________________________
>>> rabbitmq-discuss mailing list
>>> rabbitmq-discuss at lists.rabbitmq.com
>>> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>>>
>>
>