|
John, Good find on this one. Curiously, I searched my Hold folder for examples of this and could find none. I would expect to have seen some of these unless possibly the patterns are well tagged and scored too high. We have pretty high volume over here. I'm speculating here, but this might suggest something that could cause Declude to crash. In the old days where these files were mostly stored in the spool, Declude could crash gracefully. Now with Declude moving everything out of the spool, if it crashes, it will then start up and crash again. I believe that this is probably not a good way to construct the product if at all possible. In the older Decludes the crash recovery was automatic unless a message landed in overflow that could cause it to crash. I would recommend that Declude keep files in the spool if at all possible. This means instead of moving Q files to a proc folder, they just be locked and left in the spool folder. That way the chances of a crash taking down the system will be much less. I consider this to be very, very important if Declude is going to start running as a service. You can't create the possibility of a crash that can repeatedly take down the service if it is avoidable. If this crash was caused by Declude not being able to properly parse a malformed message, there are likely many other ways to also crash it even if this one issue is resolved. This might also be the reason why I am not seeing these in my Hold file...Declude 2.0.6.16 might be crashing when trying them, but it isn't a service so it chugs on. There are other possible solutions besides keeping things in the spool. One might also be changing the name of the Q file as a first step, and not bothering to reprocess files that don't appear with their original name. Naturally I'm not totally sure about how everything works, so I'm sure that there could be even other much better ways to resolve this. Declude as a service also could use a mechanism for restarting itself when called by IMail so that crashes are self-recoverable. I would imagine that if decludeproc.exe is called and it isn't running as a service, it should be able to start itself. Matt John Tolmachoff (Lists) wrote: Through a time consuming process, I have apparently identified the trigger for the problem with the decludeproc stopping and messages backing up.Attached are text files which are D files for messages that caused this. The 2 times in the last 4 days that the decludeproc has stopped. Each time, one of these files was in the work folder. After disabling the decludeproc, moving the entire contents of the work folder to a temp folder, then feeding one pair of files to the proc folder at a time, I was able to isolate it to these. Each one of the 3 is identical in the included characters and body formatting. I would ask that any one else having this problem please check and see if you have any of these kind of files stuck in the work folder. If you need any help in figuring this out, please let me know. If we can all confirm this, Declude will be able to fix the problem that faster. John T eServices For You |
- Re: [Declude.JunkMail] Beta 3.0.4.4 update 09/24... Matt
- RE: [Declude.JunkMail] Beta 3.0.4.4 update ... John Tolmachoff \(Lists\)
- Re: [Declude.JunkMail] Beta 3.0.4.4 upd... Matt
- RE: [Declude.JunkMail] Beta 3.0.4.4... John Tolmachoff \(Lists\)
- Re: [Declude.JunkMail] Beta 3.0.4.4 update ... Kim Premuda
- RE: [Declude.JunkMail] Beta 3.0.4.4 upd... John Tolmachoff \(Lists\)
