[rabbitmq-discuss] Maximum erlang processes & dead channels

[Ben Hood]

Alex,

On Fri, Nov 21, 2008 at 9:57 AM, Alex Graul <alex.graul at bloomsburyqi.com> wrote:
> Default. I could up it with the flag in that previous conversation but that
> feels like a band-aid, not a solution.

I don't necessarily agree. The default of 32768 is just a number and
I'm not aware of it's actual significance. The effect that it has is
to put an upper bound on the amount of memory that the VM uses to
manage concurrent processes. For all we know, it may well have been
some arbitrary limit that the original Erlang interpreter had back in
the eighties. Maybe an Erlang historian can fill us in on this.

I think that this setting is analogous to way that you configure
memory management in an interpreted language. For example, in many
Java applications, if you don't give the interpreter more heap than
the default, you will run out of memory. The practice of configuring
the heap size is not frowned upon in Java circles, as, IMOH, upping
the maximum number of processes is not frowned upon in Erlang circles.

Moreover, Rabbit uses a process per queue, so if you want to use 10
Million queues, you'll have to allow Erlang to use 10 Million+
processes. I've tested Rabbit with 10 Million queues (and stopped
there because I got bored) and it was fine.

> Am I right in that in an unexpected
> client failure scenario the channel (and thus process) does remain open?

No. If a client goes AWOL, the server will reclaim all resources that
were directly attributed to it.

If I want to speculate, I can imagine a scenario whereby you are
declaring either non-exclusive or non-auto-delete queues, doing some
stuff with them and nuking the client without removing the queue.
Because your declaration semantics forbid the server from cleaning
stuff up, in this scenario you will be left with a process for each
queue that you created.

However, this is pure speculation. It would be more objective if you
could send us some code that illustrates the behaviour you are
experiencing.

HTH,

Ben