thx Noel. Sounds like you've hit the nail on the head, I'd be *really* grreatful if you did find time to implement the change you suggest, as I've got a big deadline for M-o-n-d-a-y ..aaarghh.
d. > -----Original Message----- > From: Noel J. Bergman [mailto:[EMAIL PROTECTED] > Sent: 16 August 2003 20:05 > To: James Users List > Subject: RE: POP3Fetcher leaving open connections? > > > Danny, > > You implemented a fix last October (FetchPOP.java v1.5), but that has been > in all released versions of James v2.1.x. Brian indicates that he is > running v2.1.3, and there have not been any updates since then. > > Looking over the current code, there is a try {} around the entire > transaction, and a try {} inside the for-loop. However, the latter isn't > the entire block. The pop.retrieveMessage() call isn't protected, so any > exception occuring during that operation would cause the process > to exit to > the outer try {}, which would terminate the task. > > It seems to me that the try {} should be expanded to include the few > statements not already in it, and later in the code, pop.logout and > pop.disconnect should be moved to a finally {}. > > Steve Brewin, since he's currently working in Fetchmail, should > also review > that code. It appears at first glance to have the same problem, although > expressed differently. There is no protection at all for an exception in > the message processing loop, nor anything to ensure that folder.close() is > called. > > If neither one of you wants to get to it, I'll do it later. > > --- Noel > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
