Query: Periodically purge mailbox/(es)

[niranjankhare]

Hi, I'd like to know how I can configure Greenmail Standalone to purge all mailboxes periodically. I saw some related issues :

1. https://github.com/greenmail-mail-test/greenmail/issues/62
2. https://github.com/greenmail-mail-test/greenmail/issues/99

But I'm unable to find such a configuration setting. (Which I'd like to believe exists). Maybe I missed it.

My use case is that I should be able to leave the Greenmail standalone server running over days (probably months) without 'actively' managing the Server to restart so that it does not run OOM.

Once a tester is done testing and viewed the email over IMAP, he shouldn't be needed to manually delete 'all' the mails for all the users (which is practically impossible when sending to hundreds of recipients.)

TIA!

[marcelmay]

Can you periodically/on demand restart GreenMail?

My thoughts on this feature:

• Purging should be externally triggered, to avoid breaking running tests. This is also a more flexible option, as whatever purging trigger - eg cron or manually - can be used. And it keeps GreenMail lean.
• External triggers would probably use some kind of remote API, eg #108 or maybe JMX. The standalone server could have a purge command line option (and would try to locate running instance, and trigger purge via remote API/JMX).

[niranjankhare]

@marcelmay Thanks for reviewing. First, to answer your query, yes, of-course it should be possible to do what you suggest, but to me these are more of 'work-arounds' Why? I see that via issue #99 we've already added the basic capability.

1. When we're projecting this (greenmail-standalone particularly) as an out of the box testing solution and standalone utility, this feature seems quite in line with the purpose of the utility.

2. Greenmail standalone seems something that test teams can use as part of their test environments. Also the war flavours deployed as webservices mean we expect it to be kept running over a period of time. As such the possibility of it going OOM should be 'handled' as part of the product. (Greenmail standalone / war in this case)

[niranjankhare]

Oops.. I didn't mean to close this.. hit the wrong button. Reopening

External triggers would probably use some kind of remote API, eg #108 or maybe JMX. The standalone server could have a purge command line option (and would try to locate running instance, and trigger purge via remote API/JMX).

I was thinking of an CommandLine param -DpurgePeriodically=true -DpurgePeriod=24h where purgePeriod could be h(hours)/ d(days)/m (minutes) and so on

[niranjankhare]

@marcelmay I have a proposed solution for this issue in the branch issue-266. Note that the changes are over the source branch of the releases/1.5.x branch.

Request a review and comments. I'd be nice if this can be accepted as a new feature for Greenmail!

Thanks,

[marcelmay]

@niranjankhare , thx for the work on this.

I will look at this at the weekend. My first feedback:

• Keep the purge trigger outside of core in the standalone part, as this is a feature extension of the standalone runner. The core focuses on mail (protocol) handling and unit testing.

• The purge should be primarily externally triggerable as mentioned above (generic purge), and the time base trigger should be a specialisation of this.

• Should the time based trigger rather run at a fixed time? Now it would run at startup time plus fixed hourly intervals? Would you not want to run it more cron like, like every day at midnight? Otherwise it will keep purging while testing? An alternative option to fixed time might be a time-to-live for a user after last access. This approach would auto-clean old accounts.

[niranjankhare]

@marcelmay thanks for your time. Some comments inline below:

@niranjankhare , thx for the work on this.

I will look at this at the weekend. My first feedback:

• Keep the purge trigger outside of core in the standalone part, as this is a feature extension of the standalone runner. The core focuses on mail (protocol) handling and unit testing. NK >> OK. I had thought of this, but then thought that keeping it in core would allow it to be reused across the projects rather than just the standalone runner. Also seeing as how the standalone runner was kept at bare minimum ... one class only, I wasn't sure if adding more classes there would be acceptable.
• The purge should be primarily externally triggerable as mentioned above (generic purge), and the time base trigger should be a specialisation of this. NK >> Agree, Then we can have different trigger types like purely periodic (current implementation) or Time-of-the-day trigger like you mention below.
• Should the time based trigger rather run at a fixed time? Now it would run at startup time plus fixed hourly intervals? Would you not want to run it more cron like, like every day at midnight? Otherwise it will keep purging while testing? An alternative option to fixed time might be a time-to-live for a user after last access. This approach would auto-clean old accounts. NK >>Hadn't thought of this... but the way you describe, it seems like auto-clean users feature should probably be in Greenmail irrespective of when and how periodic purge is implemented!!

Will await further comments,

[buildscientist]

Is there any way we can use some of the work done in #62? I like the simplicity of @niranjankhare implementation but allocating a thread to purge emails seems like we're opening the door for potential race conditions.

I skimmed over the code but didn't see anything that would lock the mailbox such that if email is being purged - any inbound emails won't be part of that purge. A background thread means a user has no control over when mailbox purging would occur.

#62 implemented an evicting queue - whereby given a configurable threshold emails would be removed from the mailbox.

[niranjankhare]

@buildscientist Noted! Will take a look at that as well.