Dear Wiki user, You have subscribed to a wiki page or wiki category on "James Wiki" for change notification.
The following page has been changed by ChauLe: http://wiki.apache.org/james/ChauLe ------------------------------------------------------------------------------ - [sentialist AT NO SPAM gmail DOT COM] + [EMAIL PROTECTED] Hello! @@ -22, +22 @@ (which takes significant time). === Proposed solutions === - Following FastFail proposal by DannyAngus and NoelBergman I propose + Following FastFail proposal by DannyAngus and NoelBergman - to implement a drop-in replacement for - [http://james.apache.org/javadocs/org/apache/james/smtpserver/SMTPServer.html SMTPServer] - block. - - In spirit the new block will follow the design of - [http://james.apache.org/javadocs/org/apache/james/transport/JamesSpoolManager.html JamesSpoolManager]. - While the later hosts a family of matcher - mailet pairs forming a "tree of responsibility" the - new SMTP block will host a sequence of "protocolLets" - actors for line by line processing - of SMTP protocol messages. - - Technically however it is going to be a bit different. - - Firstly I intend to allow re-configuration, reordering, addition and removal of "protocolLets" via JMX. To facilitate this I'm going to find a way to map: - * "protocolLets" bean-style configuration interface - * JMX allowed CompositeData and TabularData - * XML representation thereof (xstream-style) - * possibly Phoenix configuration objects - onto each other. - - As configuration of "protocolLets" and their order is changed via JMX this immediately affects the running block - in fact I imagine that we would take down "protocolLets" configured with old values and instantiated "protocolLets" with new configuration to avoid concurrency issues. Same applies to the protocolLet[] array representing their sequence. Each protocolLet is going to be stateless and thus tread-safe. Perhaps we can design JMX configuration interface so that all the reordering and reconfiguration will take effect in a batch as partially configured "protocolLets" may cause server failures. - - A key point here is to let the "protocolLets" see other blocks visible to the new SMTP block itself. This will simplify implementing such features as communicating outer processes (perl-written policies taken from postfix) or talking TCP to outer world hosts (RBL) - none of these actions actually belongs to "protocolLets" - little stateless decision makers. - - Then I'm going to add a JMX method for saving this configuration on disk. (Does Tomcat do that already?). - One interesting possibility would be to allow new SMTP block to save directly to SVN - thus making - provision for possible failures. - - If timeframe permits we may consider doing beanshell integration - there's nothing impossible in "protocolLets" being written in beanshell, or probably jython, javascript. In this case the code of the "protocolLet" becomes its configuration. - - I believe that this "go from getter/setters via JMX CompositeData to XML will let some fresh wind into the old dynamic server reconfiguration problem. - - Technical implementation of these features still needs to be explored. In essence "protocolLets" are quite similar to blocks but Phoenix machinery most likely can not be reused as it is. I see the following options to investigate and choose from: - * go for some quirks and tricks and make use of existing Phoenix internals as they are - * create a patched Phoenix (and push for new version being rolled out with these patches) - * run.. say Fortress inside new SMTP block (I'm trying to pick a container living inside ASF) - * DIY container plumbing pico-container style (shouldn't be too much code) closely along the lines of the current [http://james.apache.org/javadocs/org/apache/james/transport/JamesSpoolManager.html JamesSpoolManager] implementation - === Advantages for ASF === * A solid foundation for implementing a feature heavily demanded by current internet realities - SMTP fast fail * Possible a new insight on the issue of reconfiguring components inside IoC containers
