Update docs#11009
Conversation
MarkvanMents
left a comment
MarkvanMents
left a comment
There was a problem hiding this comment.
- Is this still being reviewed technically?
- Are these changes in a particular version of Mx11 or were they incorrectly described before?
- I think that there is so much dependent on SessionTimeout that we need to add some description there.
I've responded to the comments because they are unclear and imply that these two settings are pretty much useless for long SessionTimeouts, if I'm reading them correctly.
Can you look at my questions above, and comments below and respond to them. Let me know if we need a call to clarify.
No, If a value is set, it is always used. But if the following conditions does not hold we give an error:
|
MarkvanMents
left a comment
MarkvanMents
left a comment
There was a problem hiding this comment.
Thanks for the clarification.
I've rewritten this and put the description of the default in the default column to clarify my concerns.
Please can you look at this, and confirm that this has always been the case and it isn't introduced in a specific version of Studio Pro?
Added some comments for the default column. For the StudioPro version. Changes in the default value calculation will be introduced with 11.11 and 10.24.19 (or 10.24.20). |
MarkvanMents
left a comment
MarkvanMents
left a comment
There was a problem hiding this comment.
Thanks for the response @emirmx.
I've made the suggested improvements and added a note about versions.
Approving this so it is ready for publication with 11.11.
Thanks, looks great! |
…ss runtime content
Reorganized the Advanced Custom Settings page to improve clarity and removed outdated information about stateless runtime (Mendix has been stateless for several years). Key improvements:
- Moved session-related settings into a dedicated "Session Duration" section with clear subsections for web client and general settings
- Restructured session timeout guidance with clearer explanations of memory, licensing, and security considerations
- Improved clarity on when and why to adjust ClusterManagerActionInterval
- Added warning callout about correct configuration requirements to prevent runtime startup failures
- Enhanced default value explanations for ClusterManagerActionInterval and SessionKeepAliveUpdatesInterval in Mendix 11.11.0+
- Fixed ambiguous reference ("the first case") to explicitly state "if the browser tab remains open"
- Updated cross-references in main custom settings page to link directly to session timing constraints section
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
MarkvanMents
left a comment
MarkvanMents
left a comment
There was a problem hiding this comment.
Looking good. But I've had another look at the whole advanced section and restructured it. Most of the info is the same - I removed one section about "Stateless".
I also think that there is one setting which shouldn't be in the Session Duration section.
Can you have a look?
| Configuring `SessionKeepAliveUpdatesInterval` to be longer than the `ClusterManagerActionInterval` or configuring `SessionKeepAliveUpdatesInterval` to be longer than the `SessionTimeout` will cause active sessions to be cleaned up. The Runtime will fail to start if these three settings are not configured correctly. | ||
| When increasing the session timeout, be aware of the user restrictions imposed by your Mendix license. Longer sessions might mean more concurrent users at any given time. This is something to keep in mind when deciding on the specifics of the license you will need to run your application. | ||
|
|
||
| With stateless runtime, the potential of memory usage leading to problems has been reduced for two reasons. The first reason is the ability to run in a horizontally scaled environment. Multiple runtimes will mean unintended memory usage is also divided over those runtimes, reducing the impact of any one idle user session. But the main (and second) reason is that most of the memory usage has been moved to the client. So instead of all entities in the memory ending up on the application node, a large share of them will end up in the browser of the client. This should significantly reduce the potential strain on the application node that can be caused by increasing the `SessionTimeout` default value to a much higher value. |
There was a problem hiding this comment.
Removed this whole section since the runtime has been stateless since Mx7 so no one will care about the fact that stateless is better.
| Changing these settings can have a significant impact on your app, particularly regarding memory usage, security, and user experience. Consider the following points carefully before altering any of these values. | ||
|
|
||
| Since the frequency of the session timeout checks and other important events is tied to the `ClusterManagerActionInterval`, it makes sense to not use the default of half the session timeout when the value is increased by a lot (for example, 24 hours or more). It might make sense to put a maximum value on `ClusterManagerActionInterval`, regardless of how high the value of `SessionTimeout` is set. An approximate figure is 15 minutes, but ultimately this will depend on the functional requirements of the application. | ||
| Increasing the session timeout can improve the user experience, especially on mobile devices. It is important to bear in mind that entities used to present data to the user or entities that are created or retrieved when a user executes a microflow are tied to that user's session, and those entities can remain in memory for long periods of time. These entities will be removed from memory when a user signs out, but if the user idles but does not sign out (for example, if they leave the browser tab open while executing other tasks or simply close the browser without signing out), the session timeout can act as a safeguard that prevents memory usage from being tied up by idle sessions. If the browser tab remains open, setting the `EnableKeepAlive` custom setting to false will ensure, in most browsers, that the session timeout will apply to any idle browser tab. |
There was a problem hiding this comment.
bear in mind that entities used to present data to the user or entities that are created or retrieved when a user executes a microflow are tied to that user's session, and those entities can remain in memory for long periods of time.
I am not sure if this is correct. We do not retain objects in memory between requests except the session cache (stateless runtime). It could be something to do with the native mobile but I don't have much knowledge on it.
There was a problem hiding this comment.
Looks like that should have been kicked out with the stuff about how great "stateless" is.
Yes, the objects are retained in the client, not the server. I'll have a look a this and propose an update.
3 participants
No description provided.