Closed yuq closed 11 years ago
That's strange. Do you have the same delay with a simple browser or wget when you try to access to http://192.168.1.123:5232/ ?
No, seem not. here is the log for a browser to access it, the 3 sec delay is for me to enter username and password.
2013-11-18 15:34:26,363 - INFO: GET request at / received
2013-11-18 15:34:26,365 - DEBUG: Request headers:
{'CONTENT_LENGTH': '',
'CONTENT_TYPE': 'text/plain',
'GATEWAY_INTERFACE': 'CGI/1.1',
'HTTP_ACCEPT': 'text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8',
'HTTP_ACCEPT_ENCODING': 'gzip, deflate',
'HTTP_ACCEPT_LANGUAGE': 'zh-cn,zh;q=0.8,en-us;q=0.5,en;q=0.3',
'HTTP_CONNECTION': 'keep-alive',
'HTTP_HOST': 'localhost:5232',
'HTTP_USER_AGENT': 'Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:24.0) Gecko/20100101 Firefox/24.0',
'PATH_INFO': '/',
'QUERY_STRING': '',
'REMOTE_ADDR': '127.0.0.1',
'REMOTE_HOST': 'localhost',
'REQUEST_METHOD': 'GET',
'SCRIPT_NAME': '',
'SERVER_NAME': 'yuq-Vostro-270',
'SERVER_PORT': '5232',
'SERVER_PROTOCOL': 'HTTP/1.1',
'SERVER_SOFTWARE': 'WSGIServer/0.1 Python/2.7.3',
'wsgi.errors': <open file '/dev/null', mode 'w' at 0x9820bd0>,
'wsgi.file_wrapper': <class wsgiref.util.FileWrapper at 0x9768ddc>,
'wsgi.input': <socket._fileobject object at 0x988102c>,
'wsgi.multiprocess': False,
'wsgi.multithread': True,
'wsgi.run_once': False,
'wsgi.url_scheme': 'http',
'wsgi.version': (1, 0)}
2013-11-18 15:34:26,365 - DEBUG: Sanitized path: /
2013-11-18 15:34:26,365 - INFO: Anonymous user refused
2013-11-18 15:34:26,365 - DEBUG: Answer status: 401 Unauthorized
2013-11-18 15:34:29,527 - INFO: GET request at / received
2013-11-18 15:34:29,528 - DEBUG: Request headers:
{'CONTENT_LENGTH': '',
'CONTENT_TYPE': 'text/plain',
'GATEWAY_INTERFACE': 'CGI/1.1',
'HTTP_ACCEPT': 'text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8',
'HTTP_ACCEPT_ENCODING': 'gzip, deflate',
'HTTP_ACCEPT_LANGUAGE': 'zh-cn,zh;q=0.8,en-us;q=0.5,en;q=0.3',
'HTTP_AUTHORIZATION': 'Basic YWRtaW46YWRtaW4=',
'HTTP_CONNECTION': 'keep-alive',
'HTTP_HOST': 'localhost:5232',
'HTTP_USER_AGENT': 'Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:24.0) Gecko/20100101 Firefox/24.0',
'PATH_INFO': '/',
'QUERY_STRING': '',
'REMOTE_ADDR': '127.0.0.1',
'REMOTE_HOST': 'localhost',
'REQUEST_METHOD': 'GET',
'SCRIPT_NAME': '',
'SERVER_NAME': 'yuq-Vostro-270',
'SERVER_PORT': '5232',
'SERVER_PROTOCOL': 'HTTP/1.1',
'SERVER_SOFTWARE': 'WSGIServer/0.1 Python/2.7.3',
'wsgi.errors': <open file '/dev/null', mode 'w' at 0x9820bd0>,
'wsgi.file_wrapper': <class wsgiref.util.FileWrapper at 0x9768ddc>,
'wsgi.input': <socket._fileobject object at 0x988102c>,
'wsgi.multiprocess': False,
'wsgi.multithread': True,
'wsgi.run_once': False,
'wsgi.url_scheme': 'http',
'wsgi.version': (1, 0)}
2013-11-18 15:34:29,528 - DEBUG: Sanitized path: /
2013-11-18 15:34:29,528 - DEBUG: admin has NO read access to collection /
2013-11-18 15:34:29,528 - DEBUG: admin has NO write access to collection /
2013-11-18 15:34:29,528 - DEBUG: Answer status: 403 Forbidden
2013-11-18 15:34:29,757 - INFO: GET request at /favicon.ico received
2013-11-18 15:34:29,758 - DEBUG: Request headers:
{'CONTENT_LENGTH': '',
'CONTENT_TYPE': 'text/plain',
'GATEWAY_INTERFACE': 'CGI/1.1',
'HTTP_ACCEPT': 'image/png,image/*;q=0.8,*/*;q=0.5',
'HTTP_ACCEPT_ENCODING': 'gzip, deflate',
'HTTP_ACCEPT_LANGUAGE': 'zh-cn,zh;q=0.8,en-us;q=0.5,en;q=0.3',
'HTTP_AUTHORIZATION': 'Basic YWRtaW46YWRtaW4=',
'HTTP_CONNECTION': 'keep-alive',
'HTTP_HOST': 'localhost:5232',
'HTTP_USER_AGENT': 'Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:24.0) Gecko/20100101 Firefox/24.0',
'PATH_INFO': '/favicon.ico',
'QUERY_STRING': '',
'REMOTE_ADDR': '127.0.0.1',
'REMOTE_HOST': 'localhost',
'REQUEST_METHOD': 'GET',
'SCRIPT_NAME': '',
'SERVER_NAME': 'yuq-Vostro-270',
'SERVER_PORT': '5232',
'SERVER_PROTOCOL': 'HTTP/1.1',
'SERVER_SOFTWARE': 'WSGIServer/0.1 Python/2.7.3',
'wsgi.errors': <open file '/dev/null', mode 'w' at 0x9820bd0>,
'wsgi.file_wrapper': <class wsgiref.util.FileWrapper at 0x9768ddc>,
'wsgi.input': <socket._fileobject object at 0x988102c>,
'wsgi.multiprocess': False,
'wsgi.multithread': True,
'wsgi.run_once': False,
'wsgi.url_scheme': 'http',
'wsgi.version': (1, 0)}
2013-11-18 15:34:29,759 - DEBUG: Sanitized path: /favicon.ico
2013-11-18 15:34:29,759 - DEBUG: admin has NO read access to collection /
2013-11-18 15:34:29,759 - DEBUG: admin has NO write access to collection /
2013-11-18 15:34:29,759 - DEBUG: Answer status: 403 Forbidden
2013-11-18 15:34:29,787 - INFO: GET request at /favicon.ico received
2013-11-18 15:34:29,788 - DEBUG: Request headers:
{'CONTENT_LENGTH': '',
'CONTENT_TYPE': 'text/plain',
'GATEWAY_INTERFACE': 'CGI/1.1',
'HTTP_ACCEPT': 'text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8',
'HTTP_ACCEPT_ENCODING': 'gzip, deflate',
'HTTP_ACCEPT_LANGUAGE': 'zh-cn,zh;q=0.8,en-us;q=0.5,en;q=0.3',
'HTTP_AUTHORIZATION': 'Basic YWRtaW46YWRtaW4=',
'HTTP_CONNECTION': 'keep-alive',
'HTTP_HOST': 'localhost:5232',
'HTTP_USER_AGENT': 'Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:24.0) Gecko/20100101 Firefox/24.0',
'PATH_INFO': '/favicon.ico',
'QUERY_STRING': '',
'REMOTE_ADDR': '127.0.0.1',
'REMOTE_HOST': 'localhost',
'REQUEST_METHOD': 'GET',
'SCRIPT_NAME': '',
'SERVER_NAME': 'yuq-Vostro-270',
'SERVER_PORT': '5232',
'SERVER_PROTOCOL': 'HTTP/1.1',
'SERVER_SOFTWARE': 'WSGIServer/0.1 Python/2.7.3',
'wsgi.errors': <open file '/dev/null', mode 'w' at 0x9820bd0>,
'wsgi.file_wrapper': <class wsgiref.util.FileWrapper at 0x9768ddc>,
'wsgi.input': <socket._fileobject object at 0x988102c>,
'wsgi.multiprocess': False,
'wsgi.multithread': True,
'wsgi.run_once': False,
'wsgi.url_scheme': 'http',
'wsgi.version': (1, 0)}
2013-11-18 15:34:29,788 - DEBUG: Sanitized path: /favicon.ico
2013-11-18 15:34:29,788 - DEBUG: admin has NO read access to collection /
2013-11-18 15:34:29,788 - DEBUG: admin has NO write access to collection /
2013-11-18 15:34:29,788 - DEBUG: Answer status: 403 Forbidden
It only happens for CardDAV-Sync. I have tested libcarddav, it's OK.
But, from wireshark, it's Radicale who hold the communication process for a while (response for 5 sec delay). Here is the Wireshark result.
Can you check the CPU to find if Radicale is actually doing something during these 5 seconds?
I have checked the Radicale process CPU usage, almost 0% when the CardDAV-Sync is communicating with Radicale. The total CPU usage is also very low.
OK, so that's probably a problem related to the network. As Radicale is using the default Python HTTP server, and as the problem only happens with CalDAV-Sync, I'm pretty sure that the problem comes from CalDAV-Sync.
If the 5s delay is always the same, there's probably a timeout in the server or in the client. It may be caused by a request with a bad content-length header, or something similar. I've met other network-related problems causing strange delays (IPv6 or DNS resolution for example), but they're related to the computer configuration and are not directly caused by the software.
I close the bug for now, feel free to re-open it if you have any clues about something wrong in Radicale.
Do you think if the HTTP headers (like keep alive) will cause this problem?
Hi, I had the same issue and tried everything: Firewall, other port, other radicale version... In the end I only had to change in the /etc/radicale/config the value "DNS_LOOKUP=False". Please try that. Best regards Christoph
I tried to use CardDAV-Sync with Radicale, it works but very slow. I see the DEBUG log that Radicale print out and find two request from client are always delayed by 5 seconds.
And I also use Wireshark to monitor the same communication, it seems the Radicale side will delay 15 seconds to respond client for a request.
So I'm wondering what happened in Radicale and how can I drop the delay to make the sync not so painful.