- Edited
[SOLVED] Mail delivery issues for POP/IMAP in latest Grommunio releases
- Edited
I updated to the latest Cummunity Edition today. Now I also have the problem with the massively delayed IMAP synchronization. :-(
EDIT:
Grommunio appliance (SuSE iso) on Proxmox/qemu vm with 16G RAM
gromox 2.32.0.ge7685dd-lp155.12.1
grommunio-imapsync 2.264-lp155.1.1
@crpb do you have the tools to do a bisect?
Maybe that could tell us, where to look, but I bet it might be extremely difficult now, to build such an old gromox version?
6 days later
Please note: if you have IMAP issues with iOS 18, this is an iOS issue.
6 days later
Hi together... same problems here... sometimes IMAP messages are show up fast, sometimes after a few minutes and sometimes only if i restart gromox-midb.service and gromox-imap.service.
Testing if midb_reload_interval=1minutes helps... somehow... The messages are shown after 7min with that.
But im never realy sure if messages never show up so i double check the mailboxes very often now... puh...
No SQL Warnings here. "Only" the problematic IMAP communiation.
morbificagent Last night a new community edition 2.33 was released. Please test if this release solves this issue?
I have tested it and it does not change this behavior...
morbificagent This are bad news for the developers.
I'm sorry... I would be happy to send better news ;-)
- Edited
Well maybe these are better news: Please check gromox-2.33.30.x0db9c00 from devel repositories (https://download.grommunio.com/devel/). A simple rpm -Uvh of only the gromox package should do.
The devel branch currently boasts a (yet unpublished) relevant fix which whould solve this issue, commit message:
midb: resolve "inside a readonly TXN" warnings during message deletion
An implicitly started transaction stays open until the cursors have
reached the end of the data set. Just like e.g. fread(3), it is not
sufficient to read the exact number of rows/bytes — it really takes
that final step()/fread() call for the end-of-data/end-of-file flag
to be set.
References: GXL-537, GXF-1738, GXF-1769, DESK-2301, DESK-2311
References: DESK-2402, DESK-2421, DESK-2436, DESK-2449It specifically deals with the notification and stems from our full-transaction-based rebuild.
Please let us know of any results from your side.
Yea, this looks better!
Even if i tested it only for an hour now... but at the moment the imap delivery looks stable and instant!
But for everyone with the setting:
midb_reload_interval=Xminutes
This destroys the good running imap delivery to the time set here!
Dont know why but i had to remove this one and the cache interval setting.
Will take a second look tomorrow but glad to send happy news before the day ends ;-)
mwilliams
Would it please be possible, that you build it for aarch64 as well, so I can test?
- Edited
Unfortunately, everything is back to (bad) "normal" this morning. For some reason, it seems worse now. I'm currently only receiving one email via IMAP, and then it's dead silence. Restarting the services gives me emails for ohne time and then... again dead.
As a workaround i have made a cronjob to restart
gromox-midb.service gromox-imap.service
Every few minutes... not great but so i get mails.
Yes, we have identified another case in the meantime, hang tight.
GeneralProbe @jengelh can you please comment on this?
I don't follow the fourm—there is just too much noise in it.
Current hypothesis is that notifications are getting emitted too early, and midb/imap tries to read a message right then before the message data has made it to the database. All per-mbox operations were previously serialized, but have gained read concurrency in 2.30.
workaround: gromox.cfg: exmdb_force_write_txn=1