[erlang-questions] monitor message queue of a process

[Evans, Matthew]

I mean "Where Name is the pid or registered name of the process that received the message but was too busy".



-----Original Message-----
From: erlang-questions@REDACTED [mailto:erlang-questions@REDACTED] On Behalf Of Evans, Matthew
Sent: Thursday, April 22, 2010 2:10 PM
To: Roberto Ostinelli; Ulf Wiger
Cc: Erlang
Subject: RE: [erlang-questions] monitor message queue of a process

Another suggestion would be the possibility to provide a max_message_queue_size option when you start a process (i.e. in spawn, gen_server:start etc)..

When this size is exceeded new messages are rejected. Of course, the sender needs to be aware that this has occurred, perhaps by sending a message of type:

{error,sender_busy,Name,OriginalMessage}

Where Name is the pid or registered name of the sender. That way the producer can invoke any kind of recovery it sees fit. Of course, if the message is sent via a gen_server:call then the call would return with an exception.

We recently ran into a problem where an application was sending too many error/log messages which caused our event manager process' (gen_event) message queue to fill up. We eventually ran out of memory causing the VM to grind to a halt and die.

We fixed this by applying a form of asynchronous back pressure to the producer to prevent this.

Regards

Matt


-----Original Message-----
From: erlang-questions@REDACTED [mailto:erlang-questions@REDACTED] On Behalf Of Roberto Ostinelli
Sent: Thursday, April 22, 2010 7:49 AM
To: Ulf Wiger
Cc: Erlang
Subject: Re: [erlang-questions] monitor message queue of a process

2010/4/22 Ulf Wiger <ulf.wiger@REDACTED>:
> I think the high-level way to approach this problem is to have
> job-based rate regulation at the inputs of the system.
>
> I have been working on such a component, which I am now getting
> very happy with. Our own tests have been extremely promising, and
> overall, it builds on our experiences from the AXD 301 and its
> derivatives, our instant messaging systems.
>
> BR,
> Ulf W

hi ulf,

would you care to expand a little? of course, if this is compatible
with your time/nda.

i, for one, believe your experience could enlighten quite a lot in this domain.

cheers,

r.

________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED


________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED