maxime - > From what I understand, the spool is like a producer/consumer queue, > .... >both have a small window where duplication can occur.
i have been carrying on a similar discussion over in developer's list which probably belongs here - thus this response and slight change of topic. the robustness of the *Processor Pipeline* is of great importance, especially to commercial IPSs and from what I have followed your discussions to date, my gut reaction is that 'Yes, there is a window in which the messaging services of James can fail.' but we first must review the term and concept of 'guaranteed messaging' and how it relates to the SMTP protocol - which unfortunately can not, does not and will not guarantee a delivery - though it does come close. for your scenario, the window of loss is rather small and well within the industry expected bounds of reliability - which is all any system can hope for. your main concern to how the spool processes the mail and how it may or may not be lost or doubled and what the chances are of that happening are. This becomes more of an issue between the queue and the targeted repository and any guarantees that may exist between the two - which i don't believe there are any though i may be mistaken. Implementing a messaging g service (JMS) between the two or introducing robust code to ensure a low percent of mail-loss possibility can be done though i suspect discussions of this will need to take place prior , etc. etc. anyway, how my discussion falls within your is that i am concerned about properly processing the SMTP protocol within the *Processor Pipeline* - where i have scenario that the sender receives a positive from James when it in fact cannot respond - positive or negative as the db is unavailable. different situations but similar concerns. thanks, alan -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
