Hi Jerry, It's a common need for big mail providers, and it make complete sense to have cold/hot storage depending on the access pattern.
There are several solutions to that problem. One is to implement your business logic (about what is hot or cold) in your mailbox implementation and delegate to the right components. Another is to introduce an Archive concept in james and define a new interface for that in a way that doesn't hide that concern: it's probably a much better idea to be able to handle archiving process, etc. In both solution, you need to instanciate more than one MailboxManager to handle the different kind of storage. We once implemented an archive tool (it's here https://github.com/linag ora/OBM/tree/master/java/sync/imap-archive ) that handle the process of taking emails from people imap tree and put them into an "archive/year" tree that is stored on a cheaper storage. It's not as simple as it seems so I would be more confident doing it as a first class concept in James. My 2 cents. -- Matthieu On Tue, 2018-05-08 at 14:08 -0500, Jerry Malcolm wrote: > I realize this is a completely off-the-wall question... but has > there > been any discussion about breaking the JAMES db into multiple > databases? I have a bunch of clients, each with a bunch of > accounts. > And they all want to archive all of their mail and be able to access > it > through the same mail client. As the years go by, the db just keeps > growing and growing. This became acutely obvious when I was > recently > forced by my server provider to migrate to newer hardware, and I > realized I had to have mail down for a long time while I transferred > a > 60gB+ file across a slow connection to the new server. The db size > is > also making daily backups a problem. > > The reality is that 90% of the mail is archived into 'year' folders > for > each of the accounts which are basically "read-only" now. Only a > relatively small amount of mail is truly in dynamically updated > folders. If there was a way to store "/archives/2002" folders > through > "/archives/2017" folders in one db and all of the other folders in > another db, it would make backup and migration a much simpler task. > > Ok, I'm pretty sure that isn't in the immediate plan. But just let > me > put my vote in. Alternatively, is there any alternative to having > one > ever-growing mail db? Is there some trick with the db server that > can > present one logical db from multiple db files? (I know a lot about > databases... but there's still a bunch I don't know). Has anyone > else > faced/addressed this problem? Or is the answer to just live with it? > > Thanks. > > Jerry > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org > For additional commands, e-mail: server-user-h...@james.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org For additional commands, e-mail: server-user-h...@james.apache.org
