Yes, I think the limit is high enough : zimbra@phlag:~$ zmlocalconfig | grep zimbra_session_limit_soap zimbra_session_limit_soap = 100 zimbra@phlag:~$ Additionally, mailbox.log doesn't state there are too many SOAP sessions : 2024-06-10 22:30:58,290 INFO [qtp1477657879-17070:https://example.com:8443/service/soap/] [name=seb@example.com;mid=11;ip=<REDACTED>;port=45164;ua=Outlook/16.0 (16.0.17531.20004;; x64)(...1f4a45) devip=<REDACTED> ZPZB/72;soapId=46f9e2a9;] soap - GetInfoRequest elapsed=2 2024-06-10...
Apologies for this late reply, I tried to figure out what is happening by myself. Here is what I found in the JSON replies : - This is a loop of 4 responses: one with the context ‘refresh’, then 3 with the context ‘change’ - Every 4 JSON responses (so at every 'refresh' response), the session ID increases by 3 - The 'token' (change token) value is everytime the same According to information I found here : https://gist.github.com/be1/562195/0c7f6b3e065b5a7db432c46f9ae9d73f231185df, this means there...
Sure, I understand. I attached a sample of the logs with the highest verbosity level. This is what I get in loop. Thanks for this information. No, I don't have anything like that. I've been using z-push with the Zimbra backend for years without this kind of problem. I tried to extract the HTTPS traffic between Outlook and the server and try to analyse it with Wireshark, thinking that all I had to do was integrate the server's private key into the software to decrypt the traffic, but it's actually...
This is getting really strange... The problem now occurs randomly for all accounts, all devices and all folders (but only calendar folders). The only way to stop it is to run a resync from the Z-Push server, but the calm only lasts for an hour or so before it starts to storm again. I even tried a ‘z-push-admin -a resync -t calendar’ (to resynchronise ALL the calendars for all the accounts, and on all the devices), to no avail. I have enabled WBXMLSTACK level logs for one of the accounts (mine) when...
Yes - I used DEBUG in the first place, then DEVICEID in order to see WBXML requests and responses and identify the events. I tried to re-sync calendar folders and even delete the account from the device and add it again, without success. For now, I disabled the faulty calendar by adding a "-" after its name from Zimbra webmail. I will dig again into DEVICEID log level in order to debug, but I think the best way to solve the issue is to delete the calendar and create it again (or delete all events...
I was able to identify the 8 events concerned using the LOGLEVEL_DEVICEID parameter. I can find them in the webmail (they date back to 2023). However, even if I delete them from the webmail, Z-Push still indicates that 8 changes are pending. This operation does have the effect of deleting them from the device. After some research, I realise that the event deleted in this way does disappear from the 8 pending changes, but is replaced by a different one. In fact, the 8 pending events are constantly...
Thanks, I've solved my time zone problem! One last thing (I hope...), it seems that some changes don't filter down to the devices. Here's what I can see in a loop in the logs for some accounts (several times a second) : 22/05/2024 23:42:40 [2448062] [ INFO] [compta@example.com] cmd='Ping' memory='4.52 MiB/2.00 MiB' time='0.09s' devType='WindowsOutlook' devId='b1fec19d0a3c47df9ac5bcace140cf4b' getUser='compta@example.com' from='<REDACTED>' idle='0s' version='2.7.3 22/05/2024 23:42:40 [2467188] [ INFO]...
Understood. I switched every read-only account to direct CalDAV with Zimbra to manage the issue. However, I am unable to get rid of errors below. I tried a resync (with z-push-admin) and deleting/re-adding the account to the device. 22/05/2024 11:12:16 [1045571] [WARN] [pierre@example.com] SyncAppointment->Check(): Parameter 'organizername' and 'organizeremail' should be set for a meeting request 22/05/2024 11:12:16 [1045571] [WARN] [pierre@example.com] SyncAppointment->Check(): Parameter 'organizername'...