james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Short" <ssh...@postx.com>
Subject RE: Synchronization Fix
Date Thu, 08 Aug 2002 04:29:35 GMT
Noel,

JamesSpoolManager always adds the Null mailet to all processors, this
will ensure that all mails with unprocessed recipients will always get
GHOSTed.

                //Add a Null mailet with All matcher to the processor
                //  this is so if a message gets to the end of a
processor,
                //   it will always be ghosted
                Matcher matcher = matchLoader.getMatcher("All",
mailetcontext);
                Mailet mailet
                    = mailetLoader.getMailet("Null", mailetcontext,
null);
                processor.add(matcher, mailet);


Cheers
Steve

> -----Original Message-----
> From: Noel J. Bergman [mailto:noel@devtech.com] 
> Sent: Wednesday, August 07, 2002 9:18 PM
> To: James Developers List
> Cc: farsight@alum.mit.edu
> Subject: RE: Synchronization Fix
> 
> 
> LinearProcessor.java:
> 
> This is wrong, AIUI:
> 
> -    private List mailets;
> -    private List matchers;
> +    private final List mailets;  // The list of mailets for 
> this processor
> +    private final List matchers; // The list of matchers for this 
> + processor
> 
> +    public LinearProcessor() {
> +        matchers = new ArrayList();
> +        mailets = new ArrayList();
> +    }
> 
> The reason I think it is wrong is that I believe that the 
> approach preferred by the Avalon developers is for those 
> assignments to be in initialize(); that is what it means to 
> be Initializable.
> 
> It would be nice to be able to tell James to reload the 
> configuration, so that we don't have to stop and restart when 
> changing config.xml.  I suspect that this is something that 
> we'd need to take up with the Avalon developers.
> 
> Anyhow, I do think that I am seeing an error ... what happens 
> if there is an error in either configuration or 
> implementation, and the last matcher/mailet neither consumes 
> all recipients nor sets the state to someplace new?  What 
> cleans up that message?  I don't see the path by which the 
> message is removed from the spool.  Furthermore, this:
> 
>     unprocessed[i + 1].add(mail);
> 
> will end up throwing an out of bounds exception.  Am I 
> missing something, or do we need to handle the boundary case 
> for the end of the processor list? It used to work because 
> JamesSpoolManager always removed the message.
> 
> JamesSpoolManager.java:
> -                spool.remove(key);
> -                getLogger().info("==== Removed from spool mail "
> -                                 + mail.getName() + " ====");
> +                // Only remove an email from the spool is 
> processing is
> +                // complete, or if it has no recipients
> +                if ((Mail.GHOST.equals(mail.getState())) ||
> +                    (mail.getRecipients() == null) ||
> +                    (mail.getRecipients().size() == 0)) {
> +                    spool.remove(key);
> +                    if (infoEnabled) {
> +                        StringBuffer infoBuffer =
> +                            new StringBuffer(64)
> +                                    .append("==== Removed from spool 
> + mail
> ")
> +                                    .append(mail.getName())
> +                                    .append("====");
> +                        getLogger().info(infoBuffer.toString());
> +                    }
> +                }
> 
> The new approach is more efficient, but by removing the 
> side-effect, we've exposed something that needs to be handled.
> 
> Thoughts?
> 
> 	--- Noel
> 
> -----Original Message-----
> From: Peter M. Goldstein [mailto:peter_m_goldstein@yahoo.com]
> Sent: Wednesday, August 07, 2002 20:24
> To: 'James Developers List'
> Subject: Synchronization Fix
> 
> 
> 
> All,
> 
> Attached is a modified version of a performance enhancement 
> to the LinearProcessor class.  It is a modified version of a 
> fix submitted by Steve Short roughly a month ago.
> 
> The fix has two parts:
> 
> i) The synchronization of the LinearProcessor service method 
> has been removed, and the class has been adjusted to be 
> thread-safe in this situation.
> 
> ii) The mail is not renamed on each pass of the 
> LinearProcessor. Rather, the JamesSpoolManager is modified so 
> that it only removes mail from the spool when the processing 
> state is finished or when the recipient list is empty.  
> (Thanks to Shilpa Dalmia)
> 
> Note that the diffs also include the String=>StringBuffer changes.
> 
> As users of this relatively minor fix have experienced a 30% 
> increase in throughput, I'd like to get this into the code 
> base ASAP.  So if I don't hear any objections I'll be 
> submitting these sometime tomorrow.
> 
> Please feel free to respond with comments, questions, or critiques.
> 
> --Peter
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:james-dev-> unsubscribe@jakarta.apache.org>
> For 
> additional commands, 
> e-mail: <mailto:james-dev-help@jakarta.apache.org>
> 
> 

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


Mime
View raw message