Bug 1650665
Summary: | Copy messages within mail filters immediately | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Paulo Zanoni <przanoni> | ||||
Component: | evolution-data-server | Assignee: | Milan Crha <mcrha> | ||||
Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | unspecified | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 29 | CC: | caillon+fedoraproject, john.j5live, lucilanga, mcrha, przanoni, rhughes, rstrode, sandmann | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | x86_64 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | evolution-data-server-3.30.3 | Doc Type: | If docs needed, set a value | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2018-11-27 07:37:42 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Paulo Zanoni
2018-11-16 19:01:42 UTC
Created attachment 1506549 [details]
Filter
Here's the filter I'm currently using (this is not what I was using on F28, since I deleted all my F28 filters and recreated them on F29 in an attempt to see if the problem went away). I manually edited the filter to anonymize it so I won't leak anything I shouldn't. Hopefully I was able to just edit the domains and names.
So the thing about this filter is, if I use it:
- Messages that arrive on "0 debug copied" have the "important" label, while they really shouldn't because they were moved to "0 debug copied" in a previous rule.
- Messages that were supposed to arrive on "0 - In" (local) simply never arrive it. But they do get copied to "0 Inbox" (exchange) folder with the "meu" label, and the debug logs do say they were copied.
- The first 3 rules are created for debugging. They are supposed to be self-contained and not interfere with the other rules due to the "stop" rule that gets applied to those messages and the fact that nothing else acts on score -2 or the xdebugx subject line. The interesting thing is that if I remove those rules, then the messages that were supposed to arrive "0 - In" (local) now will start arriving it! Although they will arrive with the "meu" label, which is something they shouldn't.
I hope that helps trying to reproduce the problem.
Thanks in advance.
Thanks for a bug report. The 3.30.x has a change in filtering, where it piles copy/move operations into bulks and does that at the end, not after each message. It speeds filtering significantly. On the other hand, it misbehaves for your use case, which is completely correct (your use case is completely valid, not the broken behaviour). As long as the move-to-folder also means to stop processing of other rules, it might be sufficient to do copy-to-folder immediately and bulk only the move-to-folder. Here [1] is a test build of evolution-data-server, which does message copy immediately, not in a batch with message move. That should address all the above issues. Could you give it a try, please? You can download evolution-data-server and evolution-data-server-langpacks packages from [1] and then run as root: $ dnf update ./evolution-data-server*.rpm from a directory where you saved the packages. Then it's enough to run evolution as a regular user. [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=30993508 Hello I installed your package and after a quick test it seems to be working as intended. That said, I'm almost not going to use this machine this week, so I'll only have a more certain confirmation that everything is indeed working next week, once I go back to heavy emailing. Feel free to push the update as-is and close the bug if you want. I can open another ticket (or reopen this one) if the problem remains. Thanks, Paulo Thanks for a quick response. If you do not mind, then I'll wait for the next week and the heavier filtering. The next upstream release is planned on December 10th, thus there is plenty of time to confirm the fix. After another day of usage, the filters seem to be working fine. A problem I'm observing is that maybe there's some memory leak going on. After just a few hours of usage Evolution is already eating 17% of my 8gb of memory. I can't confirm that this is caused by the version that fixed the filters or if this is already in the F29 version of the package (I'm not very willing to go back to the plain F29 version because having broken filters is a major issue I want to avoid). If you have more packages available to test, feel free to submit them. I'll keep monitoring Evolution memory usage for now. Thanks a lot for the fix, Paulo Thanks for the confirmation. I committed the change upstream for 3.31.3+ [2] and for 3.30.3+ [3]. With respect of the possible memory leak, better to start a new bug report for it, to not mix different things in one report (I doubt the memory leak is caused/introduced by this change). Valgrind can be used to debug memory leaks. The set of commands look like this: $ export G_SLICE=always-malloc $ export GIGACAGE_ENABLED=0 $ valgrind --leak-check=full --num-callers=30 --show-leak-kinds=definite \ evolution &>log.txt but make sure you've installed debuginfo and debugsource packages for evolution-data-server (from the [1] at comment #3) and at least for other evolution packages you've installed (rpm -qa | grep evolution) of exactly the same version as those binary packages, thus the valgrind log is usable. It's rather useless without those debug symbols. Please note that valgrind slows things down significantly and causes higher CPU usage, due to all the memory checking, thus it's not meant for any longer use, at least in case of Evolution. The longer you make it run the better, but I fully understand that the slowness will be so huge that you might consider Evolution under valgrind useless. [2] https://gitlab.gnome.org/GNOME/evolution-data-server/commit/63741937d [3] https://gitlab.gnome.org/GNOME/evolution-data-server/commit/c0dc8c5d1 |