@crpb I created a ticket a while ago and linked some threads from the forum into it.
But the response time is quite slow.
[SOLVED] Mail delivery issues for POP/IMAP in latest Grommunio releases
Nothing new on the topic?
A customer using IMAP told me: Last weekend's "supported update" fixed this.
But, big question, which code change in grommunio introduced this issue?
well, it is not fixed on my side.
Rocky Linux 9 - Aarch64 - up to date supported release
Same here, issue still persists
Debian 12 - Supported Repo
gromox 2.30.85.4d271dc-1+2.1 amd64
- Edited
- 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?
Please note: if you have IMAP issues with iOS 18, this is an iOS issue.
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-2449
It specifically deals with the notification and stems from our full-transaction-based rebuild.
Please let us know of any results from your side.