Hello Jonathan Hickman, The next version (currently in alpha testing) does not use job files. It makes a local TCP connection through the loopback interface.
_M Thursday, March 8, 2007, 2:19:22 PM, you wrote: > 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]> -- 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]>
