I am looking at james.core.MimeMessageInputStreamSource and have a question, perhaps for Serge since he is the author, but for anybody else who might know. This class copies an incoming message into a temporary file. I would like to know the motivation for this.
In my present level of blissful ignorance, I would have guessed that Java might keep a message for us in a byte array, even a huge byte array, that the JVM and OS would work out where to store it, on disk if necessary, and we happy application developers would only need to keep a pointer to the byte array.
But, since James has this class, there must be something I do not understand. I understand why it makes sense to write a message to a file when it is being stored in a mailbox. But can you explain what makes it useful to store a message in a file at this stage of the processing?
To start, you need to consider the context as to when you would use this. MimeMessageInputStreamSource may not be a great name... it basically is a resettable input stream to a MimeMessage.
If you are accessing a message from an existing mailbox (file or DB or wherever), you are handed a specific implementation of a MimeMessageInputStreamSource to that resource.
The class you are referring to is most often used during SMTP reception. In this case, you do not want to store it immediately into the processing queue until complete. If the queue was a database, this means you'd have an open database connection as the message was being received over SMTP.. possibly several minutes.
So you need to spool that data temporarily, and then if everything's good, you stick it in the proper message queue. Yes, we could just store it in memory, but then when you run out of memory and start swapping to disk, the ENTIRE mail server gets slowed by this large message. This is incredibly inefficient. Instead, this large message alone gets put on disk and so it can scale without negatively impacting the rest of the server.
-- Serge Knystautas President Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
