M
Matt Baker
Guest
The memory is allocated to the session. Some memory is shared with other sessions (parts of database connection information, shared procedure libraries and a few other things). A session is really just a blob(s) of memory (this is a gross over simplification). When a request comes in, a thread is assigned to the memory for the session, and the .p code is run within the context of that session. When the request completes, the memory (in state-free) is left more or less as-is, and the thread is freed back into the pool for further use by the next request that needs it. If a session isn't bound to a thread, then nothing is happening with that session. Any unpredictability with shutdown is only such in relationship to the clock on the wall. Shutdown is still done in an organized manner; shutdown procedures will run, database connections will be reaped and so on. If your app is truly state free then it shouldn't matter to the app as a whole if some memory that hasn't been used in a while is freed back to the system. A note here that memory free'd by an app, may still reside within the memory allocated to that app by the OS. The OS may not immediately reclaim the memory. The OS itself has heuristics based on memory pressure for when the memory is actually reclaimed for use by other processes. Each OS is a bit different in how this is handled. That is to say, terminating a session won't necessarily make the memory for the agent process shrink immediately (or at all). knowledgebase.progress.com/.../pas-mproapsv-doesn-t-release-memory-after-clients-disconnect
Continue reading...
Continue reading...