mirror of
https://github.com/aluxnimm/outlookcaldavsynchronizer.git
synced 2026-04-25 11:05:56 +03:00
[GH-ISSUE #49] Timeouts when syncing #518
Labels
No labels
1.0
1.0
1.0
2.0
Feature
Feature request
Google
Google Calendar
async
attachement
auto-migrated
auto-migrated
auto-migrated
bug
critical
enhancement
help wanted
implemented
pull-request
solved
solved
sourceforge
sourceforge
sourceforge
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/outlookcaldavsynchronizer#518
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @aluxnimm on GitHub (Jul 29, 2015).
Original GitHub issue: https://github.com/aluxnimm/outlookcaldavsynchronizer/issues/49
Originally assigned to: @nertsch on GitHub.
Trying to sync a new calendar from Outlook with version 0.99.4 to GroupOffice 6.1.42, I get timeouts in the log and the synchronization gets stuck.
Original comment by: mawinkler
Original Ticket: outlookcaldavsynchronizer/50
@aluxnimm commented on GitHub (Jul 29, 2015):
Maybe GrouOffice sends a wrong 'Content-Length' in the http header when it replies to a GET-Request. So the value would be too low.
Could it be that you respect this value and you fetch only the characters which are defined in the header? So you are waiting for a 'END:VCALENDAR', which results in a timeout?
I did open a ticket at GroupOffice too.
Update (2015-07-30): My first guess wasn't right: GroupOffice calculates the value (content-length) correctly.
Original comment by: mawinkler
@aluxnimm commented on GitHub (Jul 29, 2015):
Hi,
I never had such problems, when I was using Sogo and I created thousands of events in series.
But when I used Google, I noticed, that the creation of events also times out sometimes. Also with Synology CalDAV (see Ticket #49), there are timeouts.
CalDavSynchronizer is utilizing the class 'System.Net.HttpWebRequest' for HTTP(s) communication. CalDavSynchronizer does not wait for a specific Tag in the response. It passes the response stream directly to XmlDocument.Load() and starts processing the Document, when XmlDocument.Load() has completed.
I never thought about the possibility, that the HTTP protocol could hang in the stage, when the server already started to respond.
Maybe 'System.Net.HttpWebRequest' is doing something wrong in the HTTP communication. I will try to investigate this issue in the next few days.
Could it be, that the server has some kind of "request throttling", to prevent an DOS attack ?
CalDav requires every "logical" Event to have a separate resource (see https://tools.ietf.org/html/rfc4791#section-4.1 ), so there will be a separate PUT-Request for every Event. In your case this means there will be 498 consecutive PUT-Requests.
It seems that there are approaches to to bulk-uploads ( see https://svn.calendarserver.org/repository/calendarserver/CalendarServer/trunk/doc/Extensions/calendarserver-bulk-change.txt), but currently I don't have the time to investigate if there is an RFC for that, or if any CalDav servers implement this protocol.
br
Gerhard
Original comment by: nertsch
@aluxnimm commented on GitHub (Jul 29, 2015):
The freezing occurs, because of the following reason:
Loading CalDav entites happens in a Background thread, but creating,updating and deleting CalDav-Events happens in the UI-Thread. If the CalDav-Server doesn't respond, this will block Outlook. But usually (If the CalDav-Server is available) this should not affect responsiveness of the UI. (Maybe I will move the whole CalDav-Communication to a Background thread in the future)
br
Gerhard
Original comment by: nertsch
@aluxnimm commented on GitHub (Jul 29, 2015):
Thanks for your detailed answer!
No, the server does not use any methods to throttle requests.
The problem (timeout) happens when CalDavSynchronizer sends a simple GET request:
GET /caldav/calendars/myname%40mydomain.tld/privat-569/b46adc4f-73fb-4b71-8eac-3a0726278023.ics HTTP/1.1
Authorization: Digest username="XXXXXXXXXX"
Host: host.mydomain.tld
Reply from server:
HTTP/1.1 200 OK
Date: Wed, 29 Jul 2015 13:32:35 GMT
Server: Apache/2.2.22 (Debian)
X-Powered-By: PHP/5.4.41-0+deb7u1
Last-Modified: Wed, 29 Jul 2015 13:32:35 GMT
ETag: "20150729 15:32:35-82859"
Content-Length: 2856
Content-Type: text/calendar; charset=utf-8
BEGIN:VCALENDAR
...
END:VCALENDAR
I just did a little test with Cadaver to fetch the URL '.../caldav/calendars/myname%40mydomain.tld/privat-569/b46adc4f-73fb-4b71-8eac-3a0726278023.ics' from the server. It did work. Strange ...
Original comment by: mawinkler
@aluxnimm commented on GitHub (Jul 29, 2015):
A colleague reported that the whole thing works, if he is using a proxy (Fiddler). I will make further tests tomorrow ...
Original comment by: mawinkler
@aluxnimm commented on GitHub (Jul 30, 2015):
We fixed some timeout issues by properly disposing WebRequests. Please try 0.99.8
https://github.com/aluxnimm/outlookcaldavsynchronizer/releases/download/v0.99.8/OutlookCalDavSynchronizer-0.99.8.zip
Original comment by: aluxnimm
@aluxnimm commented on GitHub (Jul 30, 2015):
Thanks a lot! I tried out 0.99.8 and it works again with GroupOffice.
Original comment by: mawinkler
@aluxnimm commented on GitHub (Jul 30, 2015):
Original comment by: aluxnimm