> Would it be a good idea in a future version to delete files > that are older than a certain date automatically?
I disagree. Having MessageSniffer delete the old files would hide the problem. With the messages left behind, you have a valuable symptom that something is wrong with your infrastrucure. If you ignore them, they are cosmetic and do not consume any disk space (relative to your normal disk space consumption of logging and spam holding). Andrew. > -----Original Message----- > From: Message Sniffer Community > [mailto:[EMAIL PROTECTED] On Behalf Of Jonathan Hickman > Sent: Thursday, March 08, 2007 11:19 AM > To: Message Sniffer Community > Subject: [sniffer] Re: Files in Sniffer Directory > > 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.Tech > nicalDetails.Peer-Server#What_file_extensions_that_are_used_fo r_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]> > > ############################################################# 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]>
