self.createActor() with globalName from inisde an ActorTypeDispatcher increases size of self

[gerowam]

self.createActor() with globalName from inisde an ActorTypeDispatcher increases size of self

[kquick]

Hi @gerowam , thanks for the report and the corresponding analysis. I can confirm that I see just over 800 bytes of consumption for each createActor() call with a globalName specified.

The increased memory consumption is a necessity of the distributed nature of the Actor environment. In concordance with your concern about storing the global address locally, the Thespian implementation must check with the Admin each time a "new" address is requested, and there must be local storage associated with this new address; any attempt to locally cache that information would suffer the same out-of-date issue you noted.

Probably a better way to address this situation is to have an Actor that provides management capabilities for other Actors (let's call this the "Maker" actor in the following discussion, and the term "Global" refers to the corresponding global actor, while the term "Client" refers to an actor wishing to communicate with the global actor). In this configuration, the Thespian globalName is not necessarily needed, and the system will operate as described below:

• Client needs to communicate to Global, so Client issues a (user-defined) "GetGlobalAddress" message to Maker. In this situation, Maker may have a globalName that identifies it, but since the functionality provided by Maker is very limited, it is fairly safe and not expected to crash or otherwise fail, thus the client can issue a single createActor(Maker, globalName = "maker") call and save the resulting address on self.
• When Maker receives the "GetGlobalAddress", it checks an internal dictionary (on self) to see if it has an address for Global. Initially, it does not, so it will then issue a createActor(Global) call (here no globalName is needed). It then adds the address obtained from that createActor to the internal dictionary and then returns the address to the Client in the response to the "GetGlobalAddress" message.
• The Maker also records in another self dictionary the address of each Client that it gave the global address to.
• Subsequent Client "GetGlobalAddress" calls can be handled directly by the Maker from the main self dictionary.
• If the Global Actor crashes or otherwise exits, the Maker will handle the ChildActorExited message by removing the self dictionary entry containing the address of Global. It may optionally send a (user-defined) "GlobalAddressNoLongerValid" message to the Client actors that were registered in the secondary self dictionary; this is optional but can make recovery faster, since this tells the Client actors that they should also flush any local copies of the Global actor address they are maintaining.
• The next time a Client issues a "GetGlobalAddress" to the Maker, the self dictionary will not contain an address for Global, so it will re-perform the createActor process for Global to get a new instance.
• If the Client Actors have cached the Global actor address, and the "GlobalAddressNoLongerValid" is not used, the clients will eventually receive a PoisonMessage on their attempts to send to the (no longer running) Global. At that point they should discard their local address for Global and re-issue a "GetGlobalAddress" to Maker.

In the above scenario, Maker is a very simple implementation, but since Maker also acts as the parent actor for Global (or any number of Global actors), it will actively know when Global exits and another version needs to be created. The Client actors require a slightly longer protocol to get the address of Global from Maker, but they don't need any additional complexity. In this scenario, the growth of memory needed for actor address management should be limited to only those cases where the Global actor exits and needs to be re-created.