2023.2 System Monitor Behavior Change

Hey all – I would like to highlight a behavioral change made in 2023.2 that some of you may be interested in.

Across all systems – on-prem, hosted, Cloud, etc. – the “GetRowsKeepIdle” calls (GetRowsKeepIdleTime and GetRowsKeepIdleTimeWithBallonInfo [sic]) are by far the most frequently made calls to the Server. As measured by frequency, those calls typically account for 40% or more of the calls made to the Server. By default, those calls are made by the Client every 30 seconds – more frequently after a report has been submitted.

As a refresher, the KeepIdle calls are “polling” calls made by the Client System Monitor (both Smart Client and Browser) to see if there has been any Report or Task activity completed on the Server that the Client needs to action – show a Report Preview or pop the information Balloon for Task completion. The KeepIdle in the Method name is a reference to keeping the users license “idle”, so it is eligible to be reused after the defined period of user inactivity.

While the KeepIdle methods are light weight, there is a fair amount of data transferred to and from the Server with each call and in 95+% of the calls, the data does not change. In 2023.2, we are starting to performance optimize this area and the Smart Client will use a new polling method – CheckForTaskUpdatesKeepIdleTime. That method passes a Boolean rather than any real data and if the “Check” returns True, a follow-up call to get the updated Report / Task information will be made by the Client. The Browser Client System Monitor update to follow the new pattern is in the development backlog.

So… you power users that have “hooked” the KeepIdle methods should review the changes made in this area to ensure any “adjustments” you have made will still function as needed.

For the engineering crowd that is questioning why we use Polling vs. Push notifications - we did implement Push notification for the System Monitor, but our Azure SignalR Service costs were higher than expected so we will revisit the Push model in the future.


@Rich Do we have the ability or can we have the ability to exclude these calls from the server trace log? It is a lot to wade thru them to find my messages or exceptions.


Thanks @Rich , I will make adjustments.

Have to make some adjustments to shared code too. :rofl:

Hey Greg - The most obvious way to exclude them from tracing is to turn the System Monitor off while you are doing a tracing session. Right Click on the Sys Mon Icon in the Windows System Tray and “Exit”.
Using the PDT to analyze the log files can also help with the KeepIdle calls - get the data into Excel and delete the KeepIdle entries.
That said, your request is a good one for any tooling we add for viewing the Web Browser activity. I will pass it along.

Thanks for the suggestion.


Hi @Rich We have a customer that recently upgraded to 2032.2 and is seeing a lot of 401 and 410 authentication failures for this particular method in their IIS logfiles. And they are seeing random smart client authentication prompts, to which they cannot successfully authenticate, as they use AzureAD / Entra ID exclusively.

I have not yet been able to match the authentication prompts with the 401/410 statuses but it’s very likely they are related. What do you think?

We recently found that the Smart Client was not correctly handling Invalid Session Exceptions - mostly against the KeepIdle method as that is long running and more likely to have the session / authentication timeout or expire. As a result, you may see more exceptions related to the KeepIdle calls.

This has been corrected in 2024.1 and patched back into 2023.2.19 under Development reference ERPS-253219.

1 Like