-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Uncaught TypeError: mapi_message_setreadflag(): Argument #1 ($msg) must be of type resource, bool given #8
Comments
Happy to mail a wetransfer link of the wbxml log. Around the same time, there are lots of these errors in the logs
Using the grommunio appliance with the community repos. |
Could it be that grommunio sync can't handle graceful restarts of gromox-zcore? |
Hmm something seems to go wrong with exmdb around the time the mobile devices of the affected user go blank:
And gromox-http seems to restart:
zcore also seems to restart a few times. I've turned up logging for zcore, for exmdb, is there a way I can turn the logging up there? Would that be by turning up the logging of gromox-http with http_log_level? I guess this would be better placed in the community forums rather than grommunio-sync as it looks like a wider issue than just sync? |
After the latest updates, this error has stopped appearing, however, I notice in the WBXML the following when these resyncs occur:
Can this be related? |
Hi @amaccuish , there will be some fixes related to the states coming soon. We are currently testing them to make sure they don't break sync, but I guess we will commit them this week.
It depends on how you define It the restart happens when the device is in
Yes, you can turn the log level of gromox-http with For issues that may span several components I think that the community forum is indeed a better place to post. But we also check the issues on github and will pick them up eventually. |
hi @gromandreas, thank you for your reply, looking forward to testing those fixes :)
Got this again this morning, redis is running, so I guess this is the case of all the resyncs. I turned up logging elsewhere but nothing jumps out, just a lot of ZRPC fails. I'll keep an eye out for the commits and will let you know. |
As an idea, can I suggest, for large inboxes, the SYNC_FILTERTIME_MAX could be set to allow older flagged emails to be syncronised (i.e. only sync up to 30 days of email, but sync all flagged email). Then users can set to sync only 30 days, but have access to older important emails. With only 30 days, the chances of state going missing or the impact of a full resync would be reduced. |
So since the last update, we haven't had a resync, just lots of
I'll leave this open for one more week then will consider closed. Hopefully this is fixed =D |
closing, as fixed with zcore adaptions and improved session handling in sync |
The text was updated successfully, but these errors were encountered: