Thanks for the information
‘the socket stream watchdog timer fired’.
Now i believe timeouts sets correctly and some watchdog timer blocks the background upload task after 65 seconds. Now it is looking more like an undocumented behavior. Any idea how to circumvent this ?
now i found same error in an old stackoverflow post
https://stackoverflow.com/questions/30597905/afnetworking-background-downloads-and-watchdog-timer
nsurlsessiond[6810] <Notice>: SocketStream watchdog timer fired after 65.000000 seconds of inactivity. Timing out the connection.
Post
Replies
Boosts
Views
Activity
Hi Quinn,
I enabled CFNETWORK_DIAGNOSTICS and inspected the logs.
At the beggining of the request i can clearly see the timeouts set correctly in the paranthesis.
default 23:00:36.916759+0300 nsurlsessiond Task <5C4414F6-6D5B-46D0-ACBA-E220B2607F14>.<3> resuming, timeouts(300.0, 300.0) QOS(0x19) Voucher <OS_voucher: 0x7f94a61086e0>
and the request sent without any error logging
default 23:00:37.264507+0300 nsurlsessiond Task <5C4414F6-6D5B-46D0-ACBA-E220B2607F14>.<3> sent request, body S 104857891
and after 65 second
error 23:01:42.265141+0300 nsurlsessiond Connection 27: timed out with error(4:-2104)
error 23:01:42.265310+0300 nsurlsessiond Connection 27: encountered error(4:-2104)
default 23:01:42.265377+0300 nsurlsessiond Connection 27: cleaning up
so this error(4:-2104) could be usefull but i dont know what it is
and more errors and logs about retry
default 23:01:42.265482+0300 nsurlsessiond [C27 A6343939-91A0-4B91-9802-215D32D4A003 [REDACTED]:443 tcp, url hash: c6b386c1, traffic class: 200, expected workload: 1000, tls, indefinite] cancel
default 23:01:42.265688+0300 nsurlsessiond [C27 A6343939-91A0-4B91-9802-215D32D4A003 [REDACTED]:443 tcp, url hash: c6b386c1, traffic class: 200, expected workload: 1000, tls, indefinite] cancelled
[C27.1 B47D4C9A-ACE2-4C49-96C8-34C455DA4F13 127.0.0.1:54234<->127.0.0.1:9090]
Connected Path: satisfied (Path is satisfied), viable, interface: lo0
Duration: 65.346s, TCP @0.007s took 0.000s, TLS 1.3 took 0.013s
bytes in/out: 1870/105001218, packets in/out: 2/8268, rtt: 0.000s, retransmitted bytes: 0, out-of-order bytes: 0
default 23:01:42.266462+0300 nsurlsessiond nw_flow_disconnected [C27.1 127.0.0.1:9090 cancelled socket-flow ((null))] Output protocol disconnected
default 23:01:42.266762+0300 nsurlsessiond nw_connection_report_state_with_handler_on_nw_queue [C27] reporting state cancelled
default 23:01:42.267240+0300 nsurlsessiond Connection 27: done
default 23:01:42.267585+0300 nsurlsessiond Task <5C4414F6-6D5B-46D0-ACBA-E220B2607F14>.<3> can retry(N) with reason(2) for error [4:-2104]
default 23:01:42.267621+0300 nsurlsessiond Task <5C4414F6-6D5B-46D0-ACBA-E220B2607F14>.<3> RELEASING power assertion.
error 23:01:42.267673+0300 nsurlsessiond Task <5C4414F6-6D5B-46D0-ACBA-E220B2607F14>.<3> HTTP load failed, 104859603/0 bytes (error code: -1001 [4:-2104])
default 23:01:42.268085+0300 nsurlsessiond Task <5C4414F6-6D5B-46D0-ACBA-E220B2607F14>.<3> summary for task failure {transaction_duration_ms=65350, response_status=0, connection=27, protocol="http/1.1", domain_lookup_duration_ms=0, connect_duration_ms=0, secure_connection_duration_ms=0, request_start_ms=22, request_duration_ms=324, response_start_ms=0, response_duration_ms=0, request_bytes=104859603, response_bytes=0, cache_hit=0}
error 23:01:42.268480+0300 nsurlsessiond Task <5C4414F6-6D5B-46D0-ACBA-E220B2607F14>.<3> finished with error [-1001] Error Domain=NSURLErrorDomain Code=-1001 "The request timed out." UserInfo={_kCFStreamErrorCodeKey=-2104, NSUnderlyingError=0x7f94a610bda0 {Error Domain=kCFErrorDomainCFNetwork Code=-1001 "(null)" UserInfo={NSErrorPeerAddressKey=<CFData 0x7f94a60267c0 [0x7fff8004b340]>{length = 16, capacity = 16, bytes = 0x100223827f0000010000000000000000}, _kCFStreamErrorCodeKey=-2104, _kCFStreamErrorDomainKey=4}}, _NSURLErrorFailingURLSessionTaskErrorKey=LocalUploadTask <5C4414F6-6D5B-46D0-ACBA-E220B2607F14>.<3>, _NSURLErrorRelatedURLSessionTaskErrorKey=(
"LocalUploadTask <5C4414F6-6D5B-46D0-ACBA-E220B2607F14>.<3>"
), NSLocalizedDescription=The request timed out., NSErrorFailingURLStringKey=https://[REDACTED]/s3/upload-file, NSErrorFailingURLKey=https://[REDACTED]/s3/upload-file, _kCFStreamErrorDomainKey=4}
default 23:01:42.268615+0300 nsurlsessiond NDSession <FD814BB3-5B2C-4D3A-9526-F250F73C2029> Task <5C4414F6-6D5B-46D0-ACBA-E220B2607F14>.<3> for client [REDACTED]will be retried after error Error Domain=NSURLErrorDomain Code=-1001 "The request timed out." UserInfo={_kCFStreamErrorCodeKey=-2104, NSUnderlyingError=0x7f94a610bda0 {Error Domain=kCFErrorDomainCFNetwork Code=-1001 "(null)" UserInfo={NSErrorPeerAddressKey=<CFData 0x7f94a60267c0 [0x7fff8004b340]>{length = 16, capacity = 16, bytes = 0x100223827f0000010000000000000000}, _kCFStreamErrorCodeKey=-2104, _kCFStreamErrorDomainKey=4}}, _NSURLErrorFailingURLSessionTaskErrorKey=LocalUploadTask <5C4414F6-6D5B-46D0-ACBA-E220B2607F14>.<3>, _NSURLErrorRelatedURLSessionTaskErrorKey=(
"LocalUploadTask <5C4414F6-6D5B-46D0-ACBA-E220B2607F14>.<3>"
after that request sent again and timed out again sent again... basically stucks in a loop.
so client thinks the request timed out at 65 seconds altough it has set the timeouts as 300 seconds correctly. And when i inspected http traffic at T+65 seconds server did not send any response or timeout.
PS: some addresses in logs are redacted by me
Yes i serialized it to a file
In a background session (default session works as expected).
My background requests just resending every 65-70 ish seconds.
I'm trying to upload some files to a server as post request using multipart body.
I've set my
timeoutIntervalForRequest = 100 (timeoutIntervalForRequest has no effect, that's correct behavior i believe)
in session configuration and 100 in my URLRequest's timeoutInterval property for good measure
But it seems like system is ignoring these values. (setting timeoutIntervalForResource is works as expected, when timeoutIntervalForResource value reached completion handler is called correctly).
I can see upload requests resent after 65 second in proxyman. And system will only listen responses for the last one sent, thus im stuck in a retry loop until timeoutIntervalForResource reached.
note: All requests will eventually returns successfully from server, and other clients can upload large amounts of data for 5 minutes so server-side issue is unlikely.
I'm having exact same issue, any update on your situation ?
I can confirm exact same behaviour in our internal call directory app. Couldn't figure out any workaround.