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
--
Hello!
- I'm Sergey Lubinskiy. I study at http://www.msu.ru/en/ deparmant of physics.
+ I'm Sergey Lubinskiy. I study at http://www.msu.ru/en/ department of physics.
- I'm keen of programming although I don't specialize in it and posess certain
+ I'm keen of programming although I don't specialize in it and posses certain
load of knowledge on Java, internet standards and protocols, general rules
of open source software development, design patterns.
I tend to think and code a bit too academically but I hope this will only
- help me to participate in the summer of code programm. Here's my proposal.
+ help me to participate in the summer of code program. Here's my proposal.
=== Problem ===
James mail server performs reasonably well under normal load but heavy
spam traffic and dos attacks significantly degrade performance. Under
the current design the main process of decision making about each particular
- mail message happens after the message has been fully recieved and filed
+ mail message happens after the message has been fully received and filed
to disk or database. Combating spam requires us to adopt an alternative
- strategy - we may wish to just cut tcp connections short based on ip and
+ strategy - we may wish to just cut TCP connections short based on IP and
- smpt commands given before we even start to accept the message.
+ SMTP commands given before we even start to accept the message.
- Another issue is that under the current desing very little control
+ Another issue is that under the current design very little control
is possible over a running instance of James mail server - the main
- configuration method is to edit config manually and then restart
+ configuration method is to edit configuration manually and then restart
(which takes significant time).
=== Proposed solutions ===
@@ -33, +33 @@
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
+ new SMTP block will host a sequence of protocolLets - actors for line by
line processing
- of smpt protocol messages.
+ 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 facilate this I'm going to find a way to map:
+ 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)
+ * 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.
+ 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 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.
+ A key point here is to let the protocolLets see other blocks visible to the
new SMTP
