Hi garry, I think this concern is more valid for the retirement of the maildir[1] implementation (mailbox) than for the mailqueue. I don't think messages are expected to remain in the mailqueue for a very long time, which is why the advocated migration path includes downtime : - stop accepting new email traffic - let the mailqueue process in-flight messages - switch mailqueue implementation - start accepting traffic again
for maildir (fs based mailbox implementation) it is more tricky as you need to do a data migration : read the whole mailbox content and rewrite it in the new store [1] http://mail-archives.apache.org/mod_mbox/james-server-dev/202109.mbox/browser On Tue, Sep 7, 2021 at 3:19 PM Garry Hurley <garry.hurley...@gmail.com> wrote: > My only concern would be those people who are still, for some reason, not > yet ready to move to James 3.x - yes, there are still some out there. They > are more likely to be using the file repo than 3.x users. If they are > using a file repo, we might want to keep a migration tool around to migrate > their 'old messages' to one of the newer repos. I know we don't always > think about it, but some organizations (particularly government ones) have > a records retention policy that mandates they keep old emails for years > rather than days. Those users need a - maintained - way of migrating from > the file repo to the newer one. > > > Just my two cents. > > On Mon, Sep 6, 2021 at 10:18 AM Raphaël Ouazana-Sustowski < > rouaz...@apache.org> wrote: > > > +1 > > > > Le 06/09/2021 à 14:54, Jean Helou a écrit : > > > awesome :) > > > > > > On Mon, Sep 6, 2021 at 1:52 PM btell...@apache.org < > btell...@apache.org> > > > wrote: > > > > > >> Hello Jean, > > >> > > >> On 06/09/2021 18:42, Jean Helou wrote: > > >>> Hello benoit, > > >>> > > >>> > > >>>> There are some alternatives: embedded activeMQ has zero > dependencies. > > >>>> Furthermore migrating is easy: just migrate with an empty queue - > > which > > >>>> can be done easily with a SMTP downtime. > > >>>> > > >>>> Also the component is deprecated for 1.5 years, given the many flows > > it > > >>>> have, given that no contributors shows up to keep it alive, I > advocate > > >>>> removal. > > >>>> > > >>> Sounds fine to me. Maybe make sure the documentation/sample server > > >> explains > > >>> how to properly configure activemq to have filesystem based msg > > >> persistence > > >>> (https://activemq.apache.org/kahadb) as an inmemory only activemq > > would > > >>> reduce the safety of the mailqueue ? > > >> KahaDB with an embedded AcctiveMQ is already the default for MailQueue > > >> (ActiveMQMailQueueFactory) for Spring and JPA-guice products. > > >> > > >> Regards > > >>> > > >>> jean > > >>> > > >> > > >> --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org > > >> For additional commands, e-mail: server-dev-h...@james.apache.org > > >> > > >> > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org > > For additional commands, e-mail: server-dev-h...@james.apache.org > > > > >
