One advantage that I can see to having multiple realms per router is if
transports are configured on a router by router basis. So if you had 100
realms, you could easily deploy them all under a common transport or set
Exactly. And the overhead in CB of running another realm is minimal. You can run 10s of thousands realms. Think: multi-tenancy. You can't configure those realms using a static node config, but you will be able to script/API control CB to fire up those realms. You will be able to have a "meta App component", which fires up realms when tenants (of your app) sign up. etc etc.
We already did the hard groundwork in CB .. the bits are there. Need to connect the dots. But as these are all quite new and advanced concepts, we (the CB community) need to make sure to gradually introduce those things to let users grok those concepts.
E.g. the idea, that _CB_ itsef has a meta API (I am not talking about WAMP meta API - which CB also has), which is also WAMP, and where CB talks to uplink management CB - on another level - might come as a surprise to some. It's like a "self hosting compiler" - or recursive WAMP. CB has passed that stage early this year. It's just that we are not yet talking much about it.
of transports. Where in a 1:1 type of relationship you would need to
configure 100 different routers/transports. The same would be true of
application components and any other resources owned by a router. So
from a resource and configuration standpoint this makes sense. If
you desired a 1:1 type of relationship you can still have that as well.
Yep. And you can also mix that.
E.g. you could have a dedicated router process with only a single realm, where you give that process appropriate RAM resources (cgroups) to "guarantee" a certain QoS. And then you can have another router process that runs 1000 "best-efforts" realms.
Am 10.09.2015 um 17:46 schrieb David Chappelle: