[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 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]
[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 sniffer@sortmonster.com 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 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] # 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]
[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? 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 sniffer@sortmonster.com 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 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
[sniffer] Re: Files in Sniffer Directory
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 sniffer@sortmonster.com 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 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] # 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] -- Pete McNeil Chief Scientist, Arm Research Labs, LLC. # This message is sent to you because you are subscribed to
[sniffer] Re: Sniffer as passthrough filter
Yes, it is called email gateway service and many of us do that and it is fairly straightforward to setup but there are a number of steps. John T -Original Message- From: Message Sniffer Community [mailto:[EMAIL PROTECTED] On Behalf Of K Mitchell Sent: Thursday, March 08, 2007 6:16 PM To: Message Sniffer Community Subject: [sniffer] Sniffer as passthrough filter I've been running Message Sniffer here with IMail and mxGuard for a number of the domains we service. I have another customer that runs their own Exchange server, and wishes to continue doing so, but inquired as to the possibility of us doing pass-through filtering for them. Is this possible with the setup I have? Thanks, -- Kirk Mitchell-General Manager[EMAIL PROTECTED] Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net # 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] # 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]
