Hello Keith Johnson, Thursday, March 8, 2007, 10:55:27 AM, you wrote:
> Periodically I will check the Sniffer directory for misc. files that may > be there and remove them. These files include .FIN .ERR .WRK, etc. I > only remove those that have older time stamps on them. Yesterday when I > logged in, I had well over 150 of .AMT files. Does anyone know what > these files are and what causes them? By them being present as well as > old .FIN, etc., would it have an impact on Sniffer's processing > performance? Thanks for the aid on this. .AMT ?? Could you mean .ABT ? If so - then .ABT indicates a job that was aborted by a client instance of SNF. The extensions to SNF job files change to represent the status of the job. http://kb.armresearch.com/index.php?title=Message_Sniffer.TechnicalDetails.Peer-Server#What_file_extensions_that_are_used_for_the_various_temporary_files_that_are_created_in_the_Sniffer_folder.3F <explanation about="where these files come from and how cellular peer-server technology works"> When an SNF instance is launched it looks to see if there are any instances currently acting as servers. If there is a server present then it will submit it's job to be processed (.QUE) -- it has become a client instance. It takes a look around to see how busy the system is by checking the number of job files present and the information in the .stat file (if present). Based on what it sees it sets an alarm clock and goes to sleep - expecting to find it's job has been completed when it wakes up. If it wakes up and the job is not done - it will give it another try, maybe a few,... but if it decides it's waited too long then it gives up-- (ABT). An aborting SNF instance will try to take out the server instance that failed to respond by changing that server's job file from .SVR to .ERR -- this prevents other instances from seeing that server instance and trying to use it; and it lets the server instance know that it's got a problem (if it is still alive). Next, the client instance will load the rulebase itself and scan it's own message. After that - it _SHOULD_ remove it's job file. HOWEVER -- if something kills off the instance before it has a chance to finish then the .ABT file will be left behind (if it's gotten to this stage). (In some cases, Windows will fail to delete the file at all even though it will tell the client instance it has deleted the file!) When a system gets too busy to handle the load it may start to kill off SNF instances before they are finished - this leaves orphaned job files in the workspace. </explanation> Deleting old job files that have been left behind is a good thing. It shouldn't be necessary on most systems. However, as long as you only delete older files that are not active you will not get into any trouble. If you leave orphaned job files to build up in the SNF workspace then SNF client instances will sleep longer than they should because they will see the extra files as evidence of a heavy traffic load. This can effect performance by increasing the number of active processes on the system. Also, the extra files slow down directory scanning and this can also reduce performance and bring the system closer to having a problem. Hope this helps, _M -- Pete McNeil Chief Scientist, Arm Research Labs, LLC. ############################################################# This message is sent to you because you are subscribed to the mailing list <sniffer@sortmonster.com>. To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
