Hello,
Thanks for opening the Jira ticket.
Anybody is free to open a pull request on GitHub, no specific rights are 
required.

-- 

Best regards,

Benoit TELLIER

General manager of Linagora VIETNAM.
Product owner for Team-Mail product.
Chairman of the Apache James project.

Mail: btell...@linagora.com
Tel: (0033) 6 77 26 04 58 (WhatsApp, Signal)


Le févr. 17, 2025 2:30 PM, de Søren Hjarlvig <s...@bluewhale.dk>Hi,
Just a quick follow up: I have created an issue for this one (JAMES-4115).
I don’t think I have the necessary rights to create a pull request.

Best regards

Soeren

Fra: Benoit TELLIER <btell...@linagora.com>
Sendt: 9. februar 2025 22:49
Til: server-user@james.apache.org; Søren Hjarlvig <s...@bluewhale.dk>
Emne: Re : SV: SV: Respooling messages - current best practice

Hello,

Yes I did came to the same conclusion : cache key is not shared Hence not 
updated by other repositories.

This indeed looks like a bug.

I think we would need to change the default option for CACHEKEYS to false, If 
not remove it entirely.

Do you think you can open a pull request regarding this?
--

Best regards,

Benoit TELLIER

General manager of Linagora VIETNAM<linagora.vn>.
Product owner for Team-Mail<github.com/linagora/tmail-flutter> product.
Chairman of the Apache James project<james.apache.org/>.

Mail: btell...@linagora.com<btell...@linagora.com>
Tel: (0033) 6 77 26 04 58 (WhatsApp, Signal)

Le févr. 8, 2025 5:04 PM, de Søren Hjarlvig 
<s...@bluewhale.dk<s...@bluewhale.dk>>

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"<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<btell...@apache.org>>
Sendt: 7. februar 2025 15:41
Til: server-user@james.apache.org<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 ?

issues.apache.org/jira/projects/JAMES<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<btell...@linagora.com>>
> Sendt: 7. februar 2025 11:02
> Til: server-user@james.apache.org<server-user@james.apache.org>; Søren 
> Hjarlvig <s...@bluewhale.dk<s...@bluewhale.dk>>
> Emne: Re: Respooling messages - current best practice
>
> Hello Søren,
>
> Now the standard way to do this is through webadmin cf
> james.staged.apache.org/james-project/3.9.0/servers/distribute<james.staged.apache.org/james-project/3.9.0/servers/distribute>
> d/operate/webadmin.html#_reprocessing_mails_from_a_mail_repository<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<linagora.vn<linagora.vn>>.
> Product owner for 
> Team-Mail<github.com/linagora/tmail-flutter<github.com/linagora/tmail-flutter>>
>  product.
> Chairman of the Apache James project<james.apache.org/<james.apache.org/>>.
>
> Mail: 
> btell...@linagora.com<btell...@linagora.com><btell...@linagora.com<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<s...@bluewhale.dk><s...@bluewhale.dk<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<server-user-unsubscr...@james.apache.org>
For additional commands, e-mail: 
server-user-h...@james.apache.org<server-user-h...@james.apache.org>

Reply via email to