I’ve noticed an annoying phenomenon that sometimes happens in the Java User Interface: while I am working with objects in an open Explorer window one or more of the following things will happen, without any action on my part:
Long ago, I enabled UCDJ tracing* to try to better understand what is going on. I found that the phenomenon was correlated to an event in the trace called kick. At the time, I did not completely figure out what this ‘kick’ did, but guessed that it had to do with some sort of synchronization activity to notify the GUI of changes in the AE.Yesterday I confirmed this hypothesis. I noticed several related new API classes added to the AE v12.0 Java Application Interface: IKickEventListener, KickEvent and KickEventType.Based on the documentation of the last of these classes, we can see that there are several types of kick event, and one of the types is TREE_CHANGED. This no doubt refers to changes to the AE folder structure (addition, modification, or deletion of folders). My guess is that the Java GUI runs an IKickEventListener, and listens for kick events from the Automation Engine. When a TREE_CHANGED kick event is received, the GUI automatically forces the folder tree to be reloaded from the AE in its entirety. This can take a few moments, during which the folder tree does not respond normally. The refresh of the window is also handled in a rather ungraceful way, and the GUI often fails to remember which folders were expanded prior to the reload.Anyway, that’s my best guess of what’s going on. It would be nice if the GUI handled this sort of thing in a more user-friendly way. I suppose it will not be fixed though, given that the Java GUI has been deprecated in v12.1. Also, I know the AWI works differently in this regard, caching data on the AWI server and loading only chunks of the folder tree at a time. (I suppose behind the scenes, the AWI still runs an IKickEventListener, and reloads the whole folder tree in response to these events, but it can shield the user from jarring UI changes.) * If you set the xml=3 trace option in uc4config.xml, you can see all of the XML traffic between the GUI and the AE.
I enabled xml=3 tracing for the GUI and then looked at the resultant trace file to see what the kick events looked like. Below are my best guesses:
<kick client="0001" idnr="0000000000" system="AE_SYS_1">OFS </kick>
(OFS is the table where the AE folder structure is stored.)
<kick client="0001" idnr="0000000000" system="AE_SYS1">EH </kick>
<kick client="0001" idnr="0001665002" system="AE_SYS_1">OH </kick>
OH is the table where the AE objects are stored; EH is the activity table. Why activity-list-changed kicks are labeled OH kicks in the UCDJ trace, instead of EH kicks, I do not know.
<kick client="0001" idnr="0000000000" system="AE_SYS_1">SYS_GO </kick>
<kick client="0000" idnr="0000000000" system="AE_SYS_1">SYS_STOP </kick>
<kick client="0001" idnr="0020619002" system="AE_SYS_1">PRMPT </kick>
<kick client="0000" idnr="0000000000" system="AE_SYS_1">EOI </kick>
<kick client="0000" idnr="0000000000" system="AE_SYS_1">HACL </kick>
<kick client="0000" idnr="0000000000" system="AE_SYS_1">UNDEFINED </kick>
Michael A. Lowry
...We are working with Support regarding various performance issues in general and with the Activity window in particular and this is a very interesting thread and some interesting findings you have come across...
2017-11-07 14:00:56,305 ionID=0000000002386086 [TRACE] NOSESSION/- NOUI [.aetracing.AutomationEngineTraceListener] - <uc-env session=""> <kick client="0001" idnr="0000000000" system="AE_SYS1">EH </kick></uc-env>