RabbitMQ In-Process?

I’d really like to know myself. I don’t see much use in a storage mechanism written in Erlang/Elixir if I can’t use it in-process, especially with having in mind how mature and serious storage engines exist out there outside the BEAM ecosystem.

Hi there, what’s your use case? Queuing and messaging are usually naturally handled within a node using processes. If pub sub is the feature you’re looking for have a look at the Registry module, and if backpressure is what you’re after have a look at GenStage. My point is that it’s a pretty uncommon request on first look, perhaps you could give us some more details to better help you.

Why uncommon? Sqlite for example is always run in-process.

Uncommon? Consider: ETS vs Redis, Cowboy vs. NGINX

In-process apps like ETS and Cowboy can simplify testing, deployment, monitoring and recovery.

The use case is for AMQP clients to attach to my in-process RabbitMQ (if possible).

Hi, I think I see where you’re going with this; TLDR is I haven’t had any experience with such a setup and I’m sorry I can’t be of more help here.

But perhaps the other examples you mentioned are not directly comparable with this use case:

• Cowboy / NGINX: HTTP is stateless, so shutting the server down should not impact your business other than availability of that node during restarts (like when deploying)
• ETS / Redis: I assume that since you mention ETS and not DETS data stored there is transient (eg. like a cache) and you would not care about them being lost, so again node restarts should not have too much of an impact on your business other than perhaps minor hiccups while the caches are warmed up

But I’m not sure what guarantees one should expect from an in-proc RabbitMQ instance that maybe restarted at any time. Because in that case that would probably mean that you do not care about messages being lost on restarts, which is perhaps valid in IOT scenarios but then you might not need to carry around RabbitMQ as a dependency. If you do care about preserving messages, then you’d need to provide access to some type of permanent storage (eg. disk) for your nodes, which can be pretty limiting when deploying/scaling containers for example, and would be better off perhaps having a stable RabbitMQ VM / cluster that you’d setup once and then forget about it.

Anyway, sorry for the rant. I hope someone else here who has more experience in this matter can chime in.