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 SergeyLubinskiy: http://wiki.apache.org/james/SummerOfCode2005/SergeyLubinskiyFastFail ------------------------------------------------------------------------------ [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 smpt block will host a sequence of "protocolLets" - actors for line by line processing + of smpt 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 facilate this I'm going to find a way 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 instantiate "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 iteself. This will simplify implementing such features as cammunication outer processes (perl-written policies taken from postfix) or talking TCP to outerworld 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 beleive 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 opitions to investigate and choose from: + * do so 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 smpt block (I'm trying to pick a container living iside 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 + + + +
