Would it be a good idea in a future version to delete files that are older than a certain date automatically? For example, if the file date is older than the current date minus [Insert Number of Days Here] days, it could automatically remove it.
----- Original Message ----- From: "Pete McNeil" <[EMAIL PROTECTED]> To: "Message Sniffer Community" <[email protected]> Sent: Thursday, March 08, 2007 12:24 PM Subject: [sniffer] Re: Files in Sniffer Directory > 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 <[email protected]>. > 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]> > ############################################################# This message is sent to you because you are subscribed to the mailing list <[email protected]>. 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]>
