james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Labib Iskander, Marcus" ...@cm4all.com>
Subject RE: Inactivity
Date Tue, 30 Jul 2002 09:00:22 GMT
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

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?


To unsubscribe, e-mail:   <mailto:james-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@jakarta.apache.org>

View raw message