z-push 2.4.5 sync issue - 0xFFFFFFFF8004010F
-
Brief update from my side as well:
Issue came back in the mobile sync. I dropped the Outlook profile once again and recreated it. Reason is, that Outlook resync had some issues yesterday, so I wanted to give it a 2nd try. Currently, mobile sync is working fine angain and Outlook resync has completed.
From my perspective, the “pattern” looks as follows:
- MariaDB as database
- EAS profiles for Outlook and also for a mobile device
- (possibly) “old” installations with many migration steps in between
-
This time it worked for 2 days. Now folders do no longer sync on the mobile and the error message is back…
So not a sustainable workaround, at least not for me! -
The environment variable can be set to KOPANO_CLIENT_LOGLEVEL=0x800006 to get sync messages. That is something introduced in 3ac65333, so for those who feel lucky and in a dev mood…
-
Not sure if it helps, but I do only see this issue as long as my mobile device is set to sync “less than no Limit” days. Specifically on the iPhone in accounts if I set “Mail Days to Sync” to “No Limit” the error does not show up anymore…
Not really what I want, though, as my mailbox is huge…
-
@hrobbie1981
I can not confirm. I see the issues on users where Android Phones (Samsung) and Outlook are connected. The sync limit is set to “All / No Limit”.
Users who using an iPhone doesn’t have any problems as much as I know.Bye
Robert. -
Hi. I got the same issue with an android mobile today after upgrading the SQL server VM from Debian 8 to Debian 10. My setup is:
Zarafa 7.2.6-10 (still on Debian 7)
Z-Push 2.2.8
DB: mariadb 10.3.18For me setting “max_allowed_packet” in my.conf in the [mysqld] Section, resolved the issue immediately.
-
@glotzkowsky said in z-push 2.4.5 sync issue - 0xFFFFFFFF8004010F:
For me setting “max_allowed_packet” in my.conf in the [mysqld] Section, resolved the issue immediately.
I´d be more than happy, if this would be a sustainable solution…
Unfortunately, others already reported back in this thread, that increasing max_allowed_packet did not cure the issue for them.To which value did you set “max_allowed_packet”?
Could you please keep us updated, if the issue is gone for you on a permanent base? -
I set it to 64M, but unfortunately it does not solve the problems for all users. There is one user with > 30000 mails in his inbox. For this user the problem still exists.
Before the update, it was a Mysql 5.5 server with max_allowed_packet set to default (16M). -
@glotzkowsky 30k emails in the inbox. thats crazy.
It slows down everything…MS advices max 5k per folder, so make that guy clean up its mail really, its that simple.
-
@thctlo said in z-push 2.4.5 sync issue - 0xFFFFFFFF8004010F:
MS advices max 5k per folder, so make that guy clean up its mail really, its that simple.
Sry, but this is not correct.
The Microsoft recommendation from your URL mentions “5,000 items per Calendar folder” but in general “100,000 items per folder” and “500 folders total”.
30k mails in the inbox should at least for outlook generally not be too big a problem, if one also thinks about archive solutions as for example Kopano Archiver.
PS: Is there actually already progress with the new Kopano Archiver (2.0) announced about 2 years ago? Auditing acceptability, especially in the areas of completeness and protection from change and tamper (denial of deletion and modification).
-
Ah, sorry, yes, but on older clients it really helps, i suggest you try it.
My boss had also over 30k items, i/we cleaned it up, added most in subfolders and gone problems.
Costs nothing, worth a try. -
z-push version 2.5.1+0-118.1
kopano-server 8.7.85-2.4I ran into the same problem after restoring emails into Inbox. Only after reducing the amount of emails to around 2600 in Inbox, did my iphone sync again. I just moved the excessive emails into sub-folders. Standard sync is set to 1 day. The other option to sync all emails was not viable.
-
After I setup my kopano server completely new from the scratch, I looks like the issue is gone from me. I backuped my users as PSTs, dropped the database an attachment store and create a new one (via kopano-dbadm, as the automatic creation from the server failed). After importing the PSTs (and recreating all rules manually, as they didn´t come back with the import), the system is running smoothly.
I have to admit that my installation was very old, I always updated since version 7.0.x. When I realized, that I´ve some metadata corruption that prevented me from dropping ophaned stores (https://forum.kopano.io/topic/2888/can-t-delete-orphaned-store/6), I decided to do a new installation.That was 2 weeks ago and so far, the system is running properly.
-
So, I’m back again. Sorry for the late response. To respond to the question about the attachment: I did not remove it myself. The backup and restore put it back in order enough for me.
Anyway, the issue resurfaced for me too. It started happening on a tablet that I only sync manually, and hadn’t done so in a few months. Tried to install mysql from the official repo, but ran into incompatibilities with the new mysql 8 password encoding. Long story short, don’t try this at home!
What did help for me was a …drumroll please: OPTIMIZE TABLE of the properties and tproperties tables (takes hours even for a relatively small db, don’t do this on a weekday).
So, I think I narrowed the problem down to performance. It is some sort of timeout between the components. The response from X simply takes too long.
- That would explain the backup/restore fix (fresh import would be clean and all data would be together) and the resurfacing after a while.
- It would explain the fact that some existing devices still sync. They don’t have too much to sync, while new devices won’t.
- It would explain syncing failing on big mailboxes/folders only.
The problem is that I still don’t know where to look exactly. It is a long chain of client app -> network -> webserver(for some of your with loadbalancer) -> php engine -> z-push-server -> network -> kopano server -> network -> database. The timeout could be in any one of these parts, I would not know.
But for me, for now, stuff works as expected as long as I do a weekly OPTIMIZE TABLE during a weekend night. Be careful, I did not pay attention to table locking or storage size. Please check before you attempt this.
Oh, also tried playing with the fsync option of innodb but did not find a significant improvement there, but it can be a big risk for your data. AFAICS don’t waste your time there. -
Btw. problem not exist in Ubuntu 20.04 with mariadb. By me problem fixed by dist-upgrade to 20.04.
P.S. i don’t use community or subscribe packages. distr packages only, due to problem with php-mapi. -
Hello,
I’ve been struggling with this problem for ages (years!) and eventually found this post.
Several key pointers: max_packet_size and not restricting client sync duration (download all). As has been suggested, a possible performance problem.
Can I suggest turning on “slow query logging” in MariaDB (https://www.liquidweb.com/kb/mysql-performance-identifying-long-queries/). Also ref: https://forum.kopano.io/topic/713/properties-ibd-table-more-than-25gb/11
I would hesitate a guess that properties/tproperties tables are organised by folder, but not indexed by date (at least on my DB, and I cannot find the DB schema definitions online), so a common client query of “get emails for last month” will scan all emails in the folder, presumably triggering a timeout?
-
Hi all,
Back with another bit of evidence towards a database issue. Up until 10 minutes ago, I was running MariaDB10 as a backend for kopano/z-push/fetchmail on UCS, attachments on a network share, not in the db.
Previously I had encountered issues with syncing a calendar with a new device. Some entries got lost, others wouldn’t disapear, in short: a sync problem.
I had absolutely inexplicable issues when I recently did a full reset on the device and then tried to add a new z-push client (android outlook) on that device for this account. It proved impossible to sync calendar entries for this account, but mail was syncing ok. Another account (older and actually more entries) synced seemingly ok at first, but had issues with new entries.I finally found time to stop the server for an hour, migrate the kopano database to a “docker-based” mysqld 5.7.31 and restart.
Instantly, the calendar entries started to appear on the new device. No account refreshing, no z-push.admin magic, just look at the mobile, open outlook and calendar was properly synced.To me, it seems to be a very well hidden performance issue with MariaDB 10 when devices try to z-push sync many entries. Could well be --as someone mentioned earlier-- a timeout in one of the involved subsystems on the chain between device and database, which is about all of them. And Mysql doesn’t have this issue, so I guess it is close to the DB server, if not the server itself.
Hope, finally someone finds the resources to fix this… once and for all.
Nib.
-
Hello everybody!
Has anyone had a chance to reproduce subject issue using nightly 10.0.x Kopano builds and MariaDB 10.3 ?
-
Hi @Finji,
@Finji said in z-push 2.4.5 sync issue - 0xFFFFFFFF8004010F:
Has anyone had a chance to reproduce subject issue
so far the steps given here did not lead to a successful reproduction of the issue on our end.
Edit: I think I made that statement here before. But if you have a Kopano subscription and are experiencing this with our supported packages please reach out to our support so that we could have a direct look on your system. As far as I know there is not a single customer who has reported these kind of issues to our support.
