Labib,
I did review your suggested patches although I didn't post a reply to the lists. The raise header code looks mostly ok, with a couple of caveats. i) I don't think there should be a hardcoded 2 sec delay for the bounce window. 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. iii) There is no javadoc provided for the new methods in NotifySender and NotifyPostmaster contrary to Jakarta code standards. 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. >From your email: "2. I added a sleep in the catch block in the main loop of RemoteDelivery.java (I indeed got a endless loop here producing 40MB of logs after startup till I was able to stop James again. How? I forgot to add the dbSPOOL repository type to the mailstore blocks configuration. Which led to a NullPointerException in the loop since the exception in the initphase is being catched.)" 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. 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. So my comments are +1 on the raise header stuff once the above caveats are addressed, -1 on the sleeps. --Peter > -----Original Message----- > From: Danny Angus [mailto:[EMAIL PROTECTED]] > Sent: Monday, July 29, 2002 4:46 AM > To: James Developers List > Subject: RE: Inactivity > > Marcus, > > I believe your patches were in the wrong format, and to be honest I'd have > to understand what implications your addition of a sleep call would have > on > perfomance before I added that. > > If you want to re-send diff -u output for the traps you made for loops > I'll > gladly review and commit them. > If you also want to explain how sleep is not going to affect performance > under high load I'll review that too, but seperatly. > > Appologies again for sticking myself with an unmanageable back log. > > d. > > > -----Original Message----- > > From: Labib Iskander, Marcus [mailto:[EMAIL PROTECTED]] > > Sent: 29 July 2002 09:32 > > To: 'James Developers List' > > Subject: RE: Inactivity > > > > > > I posted some minor changes some time ago and nobody did actually > > answer in > > any way. > > In fact I would have prefered beeing told it is all crap, but I think it > > isn't: I am using JAMES with my patches applied (in production). > > > > Marcus > > > > > -----Original Message----- > > > From: Danny Angus [mailto:[EMAIL PROTECTED]] > > > Sent: Saturday, July 27, 2002 9:58 AM > > > To: James Developer List > > > Subject: Inactivity > > > > > > > > > Everyone, > > > > > > Just a few words regarding inactivity. > > > > > > If no-one is participating on the users list, or the dev list, if the > > > commiters are commited elsewhere, and happy that James is > > > good enough for > > > their own uses then the project will be quiet. > > > > > > Apache projects move forward because people tend to get fed > > > up asking for > > > fixes, and submit them themselves. > > > > > > If you want to start contributing to James, to revitalise the > > > project, then > > > do just that contribute. We have a TODO in xdocs todo.xml, > > > and there's 14 > > > open bugs in bugzilla, and the documentation needs work. > > > Alternatively make > > > something new and offer it up. We're always happy to receive > > > contributions > > > of any kind. > > > > > > d. > > > > > > > > > > > > > > > > > > -- > > > To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > > > > > -- > > To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > > -- > To unsubscribe, e-mail: <mailto:james-dev- > [EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:james-dev- > [EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
