The Active Users view is available since version 220.127.116.11. You can see the active sessions the application accounts for, while those are not necessarily the real web server sessions – cause a potential session clear that is possible on this page would not reset the IIS session, rather then resetting the applications in memory objects.
Many moving parts
Confused about this? Don’t worry – it is not so complicated. The application holds various objects in RAM on a per user basis. This is so the search results can be processed faster while a user is accessing the search index. This information is as well cleaned out by various processes and further only hold in the application memory. It is not written to any log files or databases. An IIS or web server session on the other hand is independent from this – if you clear the in memory objects they will automatically start over, while it might cause the end user to see an error message that the search results are incomplete they simply can press F5 to refresh respective re-request the search provider or type in a new keywords and everything will be back to normal.
Of course, you shouldn’t just click on clear sessions – this is available to get an idea of what is going on and in the end was primarily necessary for debugging reasons.
The background and why this page exists
Let me explain this a bit further. We talk about a web-application that gets requests from a Windows Explorer. After each result Windows Explorer sends a new request for the next result to the web application – even creating a new session cause the session ID is not kept by Windows Explorer – till the web application indicates there are no further results.
While this is going on, there is a independent request to the search targets and their Windows Search Index databases that need to be kept in memory in order to process them, on a per user and keywords basis.
There is a bunch of more variable objects floating around and it partly even runs asynchronous and / or multi-threaded.
All of this adds layers and layers of information that are hard to see. While debugging the code and searching for issues, there needed to be a way for me to narrow this down and understand all the data I was seeing rather quick and accurate. It even had to be narrowed down to various requests and I had to account for multiple request caused by Windows Explorer while the user was typing his keywords or changing them and so on and so on and so on…
As you can see – hopefully – I needed to make some information more visible from a developer perspective in order to understand it and see the big picture. This is why this page was created.
Eventually I decided to give the administrators access to this very page cause having the web application out there, it might be valuable so they could provide me some information additional to what they see in the error log as well as just to give them and idea of what is currently going on.
The information is, as mentioned, only available in the web applications memory. It is not stored. This is not here in order to monitor and log what your users are doing, rather then resolving issues.
If you click on clear session respective clear all sessions, you might be able to temporarily help a user that reports an issue. There is a maximum error count that will automatically reset a user session as well at a certain point in order to avoid an overflow.
In general – don’t get scarred if you see errors, this is kind of expected due to many moving parts. I tried with various clear up mechanisms to account for most events, while I very proactively log them. An error does not necessarily mean there was a real issue, the application does not make a difference between an event that is more informational, a warning or a real error. It simply logs them all.