Hi Peter, thanks for your comments. Just for the notice: My firstname is Marcus.
> As my email makes clear, I don't object to the bounce window itself, I > just want it to be configurable. That is, a hard coded 2 second > parameter is not acceptable for an enterprise piece of software. It's > not flexible. I think the bounce window is a nice addition, > so long as > you can adjust the window. There is nothing special about 2 seconds. Okay. In this case configurability could make sense to some. I did not really think about making such a big change to JAMES. After all the question, if you want to mess up the configuration rather than not having the "bounce window" in this particular function, would be ansered with no by me. Since there are many more possibilities to bounce a message in the JAMES code alone and you can write your own still. This particular function has been choosen by me because the RemoteDelivery Mailet uses it. > Nope, I don't like that principle at all. As I said, there isn't much > special about the particular points where you're inserting the sleeps. These are the two main loops as I found them. The one handling spooled mail and the one sending outgoing mail. > Moreover, the above principle makes an assumption that I really don't > like - that there are no side effects associated with the exception. > For example (and there are a couple of examples of this in the current > code base), I could catch an exception, deal with the > troublesome issue > (remove it from the spool, etc.) and re-throw the exception to notify > the error handler up above. In that case you'd have the thread sleep > unnecessarily for two seconds. Waste of resources. Hmm, actually in my personal opinion I would rather not have catched these exceptions (just like I understand you), but they are being catched. I supposed that the original programmer favoured a server still running with an exception thrown in every cycle over a stopped server. I didn't dare to change this behaviour. Just that I wanted it not to run too fast in failure conditions. With a sufficiently large harddisk it should take days to crash your server. So a 'df' from time to time will be enough protection. > I disagree. If we're going to add the sleeps then these > values have to > be configurable. They're system level parameters that fundamentally > affect the error handling. You can't just hard code them to > some magic > value that works in one environment. I would exchange 'one' by 'virtually all' and as I said these sleeps are not really part of the errorhandling even as I see it. However, as I get it the sleeps will not be included in JAMES. But what would you say if I change the loops to exit in case of such an unexpected exception? I withdraw my proposal of the bounce window if you really want it to be configurable. (I will leave it in my running instance though.) The raise header extension to the notify mailets and the couple of matchers I will repost after I added some docs (with cvs diff -u ;). Right? Cheers, Marcus -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
