I want the speed of asynchronous messages but still have some flow control. How can I accomplish this in Erlang?
Asked
Active
Viewed 869 times
2 Answers
7
There is no process memory limit right now -- it is discussed on mailing list etc. You can look at those threads.
On the up side, when you use OTP patterns implementation like gen_server you have a lot of freedom in retrieving messages from process queue and measuring the length of the queue.
gen_server2 used in rabbitmq used to optimize that by moving messages to internal data structure. Having that you can discard any new incoming message when internal queue is too long. You can do it silently or notify sender that the message rejected.
All of that is on very low level.
RabbitMQ will provide this functionality on AMQP level.
user425720
- 3,578
- 1
- 21
- 23
-
Does gen_server2 implement windowing? – Eric des Courtis May 31 '13 at 00:07
-
I am not sure what is current status of gen_server2 implementation. It might be somehow merged with main one, after introducing non-linear matching of messages in message queues in OTP gen_server. – user425720 May 31 '13 at 05:19
6
A common and quite good way of enforcing flow control is to make well selected messages into calls which limits how much load each client can load the server to one, effectively providing force feed back in an extremely simple way. The trick is of course to pick which communications uses synchronous calls :-)
Jan Henry Nystrom
- 1,045
- 5
- 8
-
This would be my solution as well. Basically build in some flow control on the line. There are more advanced solutions to this as well. – I GIVE CRAP ANSWERS May 30 '13 at 20:54
-
1I am not sure if I understand. You propose sync calls over async which guarantees that messages are queued on client side? I think it depends on use case. If client is transient, we may not afford this solution. – user425720 May 31 '13 at 05:09
-
The core of the problem is that to have any form of flow control you will in the end have have some form of synchronization. If the client providing the flow simply do drive by message passing, we cannot limit it in any way. The answer to that is quite often to limit the number of client in the first place but that will require some form of centralized knowledge of the number of clients, which require synchronization. So in the end it boils down to where do we synchronize. A common solution in telcom apps is too simply shed at the interfaces, but have to know when to shed :-) – Jan Henry Nystrom May 31 '13 at 05:25
-
@JanHenryNystrom I am aware of `gen_server:call` but I was more interested in a middle ground between the two. – Eric des Courtis May 31 '13 at 19:14