james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Markus Wiederkehr" <markus.wiederk...@gmail.com>
Subject Re: [mime4j] Storage resource management [long]
Date Thu, 09 Oct 2008 23:02:46 GMT

On Thu, Oct 9, 2008 at 11:26 PM, Bernd Fondermann <bf_jak@brainlounge.de>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?


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message