Hi, it is not that I am too keen on my code being included, but I am still glad to get some response. Maybe I didn't make clear what the intent of my patches was: I didn't want to add any feature. I just wanted to change JAMES a little bit to behave friendlier even in unexpected conditions.
> i) I don't think there should be a hardcoded 2 sec delay for > the bounce > window. The reason is that I wanted to forbid rebounces happening without user interaction or at least they should happen slowly (2 s). This is rather lax since one might argue that rebounces don't make sense at all. Maybe you have got a better solution? However, if you don't like this protection against rebouncing: leave it. > ii) I don't understand why the raiseHeader method is > returning "1" when > it is passed a null. To me this looks like an exceptional > condition. I > would expect the method to throw an exception to indicate > that something > unexpected happened. As you wrote in your second mail. Incoming mails will not posses a header of that kind (of course they could thats why negative header values may not be accepted) > iii) There is no javadoc provided for the new methods in NotifySender > and NotifyPostmaster contrary to Jakarta code standards. yeah. you are right. sorry. I will add some docs and repost the code. btw. i did diff the files with 'cvs diff'. thats not okay? > I'm less crazy about the sleeps, not because I think they'll have a > disastrous effect on performance, but rather because they > seem like the > wrong solution to the stated problem. Basically I have no idea what > makes these particular exceptions merit sleep calls, while others > throughout the system do not. Yes, they're in loops, but > that's hardly > unusual. Hmm, maybe you don't like this principle of mine. In these loops all exceptions are caught. You can try to determine every possible cause and still forget something, like it happend. The bug itself is minor in my reckoning. But its effect can be disastrous! At least on a machine where JAMES runs with root rights like it normally will. On our machine it doesn't, but we don't have quotas enabled. Soon the whole machine will crash or at least hang. Thus after dealing with the foreseen exceptions you should in an endless loop at least sleep after a not foreseen exception occurred before you try executing the same code again. The spots where I added the sleeps should never be reached as I understand the code. > It seems like the way to solve this is by handling the > NullPointerException in the initphase - not by adding a sleep > to the run > that makes it easier to kill the system once it's running and throwing > errors. Yes. But see my comments above. > And again, on the general principle that hard coded timeouts > are bad, if > we're going to put in these sleep calls I don't see why they'd be > hardcoded to a fixed 2 sec. These calls are kind of "infunctional". One would never hope them to be called. They are just a bit of garbage in the class file to protect you against something unkown. There is no need to argue about the value or its configurability. > > If you also want to explain how sleep is not going to affect > performance > > under high load I'll review that too, but seperatly. As I mentioned above. The sleeps should never be reached under foreseen circumstances. I will add some documentation and repost the files. Thank you, Marcus -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
