Theory of Operation

Log Dispatcher operates a timer whose terminal count is set by the /POLL= parameter at startup or specified by Right Clicking on one of the running monitors and selecting Polling Interval from the popup menu that appears. The values are given as whole numbers that represent milliseconds of time. There are 1000 milliseconds in 1 second. This parameter sets the timers interval. When the timer counts down to 0, it initiates a terminal event that interrupts current processing. The interrupt code disables the timer and checks the monitored file for any intervening file size changes. The file is positioned to its END OF FILE marker upon opening it. If the file has a different size then previous timer interval samples, reads are issued against the file, shifting the data into Log Dispatcher until the END OF FILE marker is once again sensed.

If there are entries in the Log Dispatchers Filters List, the list is retrieved and each entry is compared to the current monitored file sample. If the filter string appears anywhere in the the sample then the corresponding commands associated with the filter are invoked by exercising the Windows asynchronous shell facility using the user roles assigned to Log Dispatcher. The timer is then re-enabled and Log Dispatcher reverts to a ready state. Timer activity is controlled by how much a monitored file changes.

If a user decides to detach a monitored file from the MDI parent window, a SDI version of the monitor is created. The MDI properties and filter lists are copied to the new SDI version. The MDI monitor is then destroyed.

Log Dispatcher creates and then silently monitors a control file named after the Log Dispatcher Process ID. External processes can use this control file to cause Log Dispatcher to automatically open and begin monitoring files at run time by appending the desired file name into a given Log Dispatchers control file.

Known Problems and Workarounds:

o     Files that change in the middle and not the end will enable the timer interrupt code but that may cause unpredictable Log Dispatcher updates until the next terminal interrupt finds file size changes that occurred near the EOF marker. If a file has data deleted at the middle, it does not matter to Log Dispatcher because there are no commands to dispatch. If a file has inserted data in the middle while being monitored, Log Dispatcher will miss it. The intent of Log Dispatcher is to monitor files that are written to by resident services or applications that report their status in log files as the application is running. Log Dispatcher hopes that this is accomplished thru log file appends and not inserts or updates into the middle of a file.

o     I might think about what to do if a file size increases yet the last line does not change. This may imply activity well before the EOF marker and not immediately adjacent to it. Yet the detection would not be useful unless one knew where the file changed. Again, none of these thoughts were in my mind when I wrote Log Dispatcher and they are not the intended purpose of it (to track file changes, Log Dispatcher is a command listener node in a possible network of them. The communication path is remote SMB file appends. The file itself could be meaningless and is used solely to employ OS managed SMB in order to invoke commands on remote nodes).

o     The default polling interval (750 milliseconds) seems reasonable for most settings. If there is an application that is able to flush messages rapidly to a file system, and you`re concerned about capturing them when they arrive as fast as possible, then you may want to speed the timer up a bit. Anything under 50 milliseconds becomes dangerously close to receiving read requests out of order across network latencies or flooding the network with silly SMB traffic (file size queries).

o     Log Dispatcher attempts to create a control file named after Log Dispatchers' Process ID.  Log Dispatcher monitors this file for internal Log Dispatcher commands.  Log Dispatcher can't access the local Windows Process List unless the Log Dispatcher user is a local Windows Administrator. Log Dispatchers started by a user who isn't a local Administrator can't be sent any internal Log Dispatcher command by an external process.

o     If a monitored file is detached from the parent, and then the parent is exited, a Log Dispatcher Process ID will remain in the Windows Process List but the detached Log Dispatcher will have no Control File associated with it. Only parent Log Dispatchers can create internal Control Files that may be accessed by external processes.Remote Batch Copy is an example of an external process that might be affected by this. Remote Batch Copy looks in the Windows Process List for the Process ID of any running Log Dispatchers.  It then opens a file made from the running Log Dispatchers Process ID to send it internal commands in order to cause it to monitor various Remote Batch Copy logs. If a Log Dispatcher has been detached and then its parent exited, Remote Batch Copy will timeout (32 seconds) before reporting that no Log Dispatcher could be found.  Exit the detached Log Dispatcher to cause Remote Batch Copy to start a new Log Dispatcher parent.

Find any new ones?

jeffreymartinj@yahoo.com