7.1. System information


All authenticated sessions are shown here


  • Info message: This message is presented to each user on the login screen. When logged in, the message disapears. Set an empty message to delete an existing message. When rebooting the server, the message persists.

  • Maintenance message: This message is presented on every page at the top of the screen. Using the maintenance message user can be notified about a server shutdown e.g. in 5 minutes. Users have then the change to finish their work and to log out cleanly. Set an empty message to delete an existing message. When rebooting the server, the message is automatically removed.

    The maintenance message can also be set by that runs on the same server as the OLAT server. This can be used to inform user about a daily backup procedure that includes a shutdown of the server. Schedule a maintenance message five minutes prior to the shudown.

    #wget "https://www.yourolat.com/olat/maintenanceMessage.html?token=xyz123&msg=Hello+world"

    The token parameter is set automatically the first time you start OLAT. You can lookup the value in the properties table (See properties section below). Search for a property that has the category "_o3_" and the name "maintenanceMessageToken".


A convenient way to quickly show an error with its stacktrace (e.g with id "E123", which shows up in the orange screen when an error occurs). For large logfiles it is a lot more efficient to use external tools like grep. The logfile is situated at olatdata/logs/olat.log

Hover with the mouse over the text Error number: and a tooltip appears with the actual max Exy number


To set the log4j-Loglevels on the fly. Loggers set to debug will of course fill the log quickly. The loggers show up on this screen only if the associated class has been loaded. (e.g. course loggers only show up if at least one person has entered a course since the startup of the server)


  • Display memory: (with option to garbage collect). Note that the information of free memory is only accurate after a garbage collection. But you are advised not to trigger a full garbage collection on a live system.

  • DefaultControllerCount: Number of org.olat.gui.control.Controller of all users. The instances are stored in a weakhashmap and are thus only accurate right after a garbage collection. The count is now generated by incrementing and decrementing instead a count over the collection.

  • Threads: thread dump. Note that five threads are needed for each authenticated user if you have instantmessaging enabled (Thread-XXXX, Smack Packet Writer, Smack Writer Listener Processor, Smack Packet Reader, Smack Listener Processor). Because of the large number of threads, it is thus adviceable to reduce the stack thread size which often defaults to 512kB per thread (use the -Xss option, e.g. /usr/local/opt/java-1.5/bin/java -server -Xss256k -Xms768m -Xmx768m -Djava.net.preferIPv4Stack=true)

  • Java Environment Properties: can be very useful


Dumps out all the information about your http-Request (similar to the famous Tomcat SnoopServlet)


User-session administration. Can be used to handle overload situations.

  • Block new logins. No new users can login anymore. Only administrators can further login.

  • Invalidate all sessions! All user except administrator will be logout.

  • Invalidate a certain number of sessions (ordered by last access).

  • Set session-timeout in sec.

  • Set maxium number of sessions. More sessions will be blocked.

For debugging only : Displays all UserSession objects with its Windows contained.


Certain actions (e.g. editing a certain course) can only be done by one person at a time. All locks are listed here. The locks are released when the usersession is unbound (session timeout or log-off). The locks are reentrant for a person: If you are in a course editor and your browser crashes, you can re-login (thus obtaining a new session) and still re-enter the editor.

Multi-user events

If a person enters e.g. a course, the Controller will register to listen to global event of interest. If you are currently working in a OLAT group which is deleted right at this time by an administrator of this group, the controller will receive a message that the OLAT group has been deleted and inform you on the screen.


Information about cluster when running in cluster-mode. This tab is disabled in single-VM mode.

  • Information about cluster-nodes like number of send/received messages. Link to change admin-console to an other cluster-node.

  • Start/stop performance monitoring. Reset performance monitoring. Table with performance statistic for all measure-points.

  • Link to release all locks without finishing user-sessions.

  • Last send and received cluster events.

  • List with registered cluster event-listeners.


Currenty there are to major caching mechanisms in OLAT active. First the EHCache (Easy Hibernate Cache) and the Softcache.The EHCache tries to minimize access to the database by caching queries recenty loaded from the database. The EHCache could be used for general purpose caching tasks but is actually mostly used as a database query cache. The softcache does caching for the needend data of a whole course with all properties and rights. The "soft" indicates that it uses javas soft keys for referencing to object on the heap and therefore the java memory manager can


Information about installed OLAT software version like :

  • version with build number

  • isClusterMode [true or false]

  • nodeId : current connected node-number

  • serverStartTime

  • baseDir


If you are in a clustered OLAT you can check your distributed filesystem with this simple test. The Test generates files on different nodes and checks if they are visible on every node. Do not run this in a production environment as it can produce some heavy load.