[rabbitmq-discuss] rabbitmq with one producer no consumer

[Darius Damalakas]

Thanks for telling the story.

By the way, how much messages can now RabbitMQ handle easily?

2010/7/15 Ovidiu Deac <ovidiudeac at gmail.com>

> 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
> >>>
> >>
> >
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>



-- 
Linkėjimai, Best Regards

Darius Damalakas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100715/ab67894d/attachment.htm>