Hi, On Thu, Oct 9, 2008 at 11:26 PM, Bernd Fondermann <[EMAIL PROTECTED]>wrote:
> [...] So the requirement is to have those large parts stored on disk. > > The current mime4j implementation uses "temporary storage", making use of > temporary files as supported by the JDK. > > This is a choice made easy by the JDK, yet it has its shortcomings. > Tempory files of this kind might not be so temporary. They are collected > only on JVM termination. For long running applications, where JVM > termination happens not that often, its easy to run out of disk space and > file descriptors. > Thus it was proposed to extend the mime4j API to dispose of temporary > files, make them shorter lived. > > Another requirement voiced is to be able to copy emails. To save resources, > it was proposed to implement this by re-using (not deep-copying) those > objects which are not altered, including possibly reusing one temporary file > for more than part. We totally agree on the requirements so far.. > I don't think that JDK temp files are neccessarily a good choice. I can > imagine different implementations using a specific disk partition, user > account, quota, directory - anything where the developers can take more > control about the storage. An optimization would be to keep parts up to a few KB in memory and only > starting to write out to disk if a part grows beyond that point (or > available heap drops below a threshold). > All this would require a more sophisticated resource management than what > we have now. There are already two ways to accomplish this now. 1) implement TempStorage however you want and activate it globally with TempStorage.setInstance() (as I have already mentioned) or 2) subclass MessageBuilder, override body() and use your own custom Body implementations there. So I don't see how this is strongly related to our current discussion.. What we have now (without dispose()) is a more or less immutable, > threadsafe, kind-of-idempotent object model. This did fundamentally changes > with introducing dispose(). Not neccessarily a bad thing, but worth noting > and discussing. @idempotency, I already commented on that. Thread-safety.. How is Multipart.addBodyPart() thread-safe, for example? Markus
