Return-Path: Delivered-To: apmail-jakarta-james-dev-archive@apache.org Received: (qmail 43286 invoked from network); 8 Mar 2002 15:22:03 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 8 Mar 2002 15:22:03 -0000 Received: (qmail 27262 invoked by uid 97); 8 Mar 2002 15:22:02 -0000 Delivered-To: qmlist-jakarta-archive-james-dev@jakarta.apache.org Received: (qmail 27175 invoked by uid 97); 8 Mar 2002 15:22:01 -0000 Mailing-List: contact james-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "James Developers List" Reply-To: "James Developers List" Delivered-To: mailing list james-dev@jakarta.apache.org Received: (qmail 27159 invoked from network); 8 Mar 2002 15:22:00 -0000 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.1 Date: Fri, 08 Mar 2002 15:18:31 +0000 From: "Gordon Ross" To: Subject: Re: Sticking with one undeliverable message Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Ok, got another problem then. I inserted a System.out statement to do some quick and dirty logging in the deliver() method, but I'm getting nothing back. Any ideas ? Thanks, GTG >>> sergek@lokitech.com 08/03/2002 14:51:36 >>> The linear processor (I guess what you're seeing in JamesSpoolManager) does not handle mail delivery. It handles moving messages through the various processors, and there's really no reason to delay that. Remote delivery is handled by a mailet called RemoteDelivery and that does use the accept(delay) method. The store method in the mail repositories should be setting last updated each time. RemoteDelivery also handles counting the number of retries (you'll find the settings to change both the # of retries and the delay to take in the configuration of the RemoteDelivery mailet) Serge Knystautas Loki Technologies - Unstoppable Websites http://www.lokitech.com/ ----- Original Message ----- From: "Gordon Ross" To: Sent: Friday, March 08, 2002 3:41 AM Subject: Sticking with one undeliverable message > Hi, > > You've probabley seen me open my big mouth in the users forum, so here > I am to make a complete fool of myself... > > I've had a look at the source for the "current" version of James > (2.0a2) to look at the problem of the smtp mailer sticking with one > undeliverable message. (which incidently is the bug that I logged on > bugzilla) > > From what I can see, in the JamesSpoolManager run() method, a message > is obtained via accept(), and then delivery attempted for that message. > (Fair enough) and if delivery fails, the exception is trapped. However, > nothing else happens when this exception is caught. Also, as accept() > provides no guarentee as to the order in which messages are retrieved > from the spool, then there is every chance that the faulty message will > be returned straight away. > > My Suggestion, is that: > > 1) Instead of using accept(), accept(delay) should be used. > > 2) If the message cannot be delivered, then it should be updated via > setLastUpdated(), so that accept(delay) won't retireve it straight > away. > > However, before I try this, one question I have is: > > How/where does the system check whether a message has exceeded is > re-try count and bouce it back ? > > GTG > > Gordon Ross, > Network Manager, > Countryside Council for Wales -- To unsubscribe, e-mail: For additional commands, e-mail: -- To unsubscribe, e-mail: For additional commands, e-mail: