Hi Benoit,
I took a look at the FileMailRepository source and the behavior seems to be
caused by the cache being populated at startup and never refreshed from the
filesystem.
If I disable the FileMailRepository cache in the config, manually added
messages are registered as expected:
<mailrepository
class="org.apache.james.mailrepository.file.FileMailRepository">
<protocols>
<protocol>file</protocol>
</protocols>
<!-- Set CACHEKEYS to false to register manually added messages -->
<config FIFO="false" CACHEKEYS="false"/>
</mailrepository>
I'm not sure if this behavior is by design or a bug.
However, disabling the cache is fine for my use case.
Thanks,
Soeren
-----Oprindelig meddelelse-----
Fra: Benoit TELLIER <btell...@apache.org>
Sendt: 7. februar 2025 15:41
Til: server-user@james.apache.org
Emne: Re: SV: Respooling messages - current best practice
Hello
That's clearly a bug of the FileMailRepository.
Would you agree opening a bug report for it in JIRA ?
https://issues.apache.org/jira/projects/JAMES
In the meantime you can consider using the JPAMailRepository. It had been
contributed recently and shall be more reliable.
Best regards,
Benoit
On 07/02/2025 15:27, Søren Hjarlvig wrote:
> Hi Benoit,
>
> Thank you for swift response.
> The approach seems to be working, however, when I copy a new message into a
> retry-repository, which I have created, it seems that a service restart is
> required before James sees it.
> Is there a way to have James reload the content of a mailstore?
>
> Order of events:
>
> 1. Message FileObjectStore and FileStreamStore is copied to
> /var/mail/retry/
> 2. curl -XGET
> http://127.0.0.1:8000/mailRepositories/var%2Fmail%2Fretry%2F/mails
> 3. []
> 4. Service restart
> 5. curl -XGET
> http://127.0.0.1:8000/mailRepositories/var%2Fmail%2Fretry%2F/mails
> 6. ["Mail1738937327729-b8303e94-f959-420a-9d18-f6adccf132fa"]
> 7. curl -XPATCH
> http://127.0.0.1:8000/mailRepositories/var%2Fmail%2Fretry%2F/mails?action=reprocess
> 8. {"taskId":"ff8c877b-8a62-44b8-ba63-64cfb722c785"}
>
>
> Best regards
>
> Soeren
>
> Fra: Benoit TELLIER <btell...@linagora.com>
> Sendt: 7. februar 2025 11:02
> Til: server-user@james.apache.org; Søren Hjarlvig <s...@bluewhale.dk>
> Emne: Re: Respooling messages - current best practice
>
> Hello Søren,
>
> Now the standard way to do this is through webadmin cf
> https://james.staged.apache.org/james-project/3.9.0/servers/distribute
> d/operate/webadmin.html#_reprocessing_mails_from_a_mail_repository
> (Implemented for Guice wich shall be, except for binding the jdbc
> driver a drop in replacement from Spring app)
> --
>
> Best regards,
>
> Benoit TELLIER
>
> General manager of Linagora VIETNAM<https://linagora.vn>.
> Product owner for Team-Mail<https://github.com/linagora/tmail-flutter>
> product.
> Chairman of the Apache James project<https://james.apache.org/>.
>
> Mail: btell...@linagora.com<mailto:btell...@linagora.com>
> Tel: (0033) 6 77 26 04 58 (WhatsApp, Signal)
>
> On Feb 7, 2025 10:38 AM, from Søren Hjarlvig
> <s...@bluewhale.dk<mailto:s...@bluewhale.dk>>
>
> Hello there,
>
> I'm wondering what the best practice is for manually respooling messages on
> newer version of James.
> Ideally, I would like to manually respool messages by moving them from the
> error repository (e.g. file://var/mail/error/) to a watched folder.
> Old posts on this list suggest that the FromRepository mailet could be used
> for this, but from the 2006 thread is not clear how FromRepository should be
> triggered.
>
> Thanks and kind regards
>
> Soeren
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org
For additional commands, e-mail: server-user-h...@james.apache.org
