Archived Forum Post
Index of archived forum posts
Question:
Archived Forum PostQuestion:
I'm 99% sure this is a misconfiguration or a problem on the server side, but I'm not sure how to deal with it. Some uploads are hanging indefinitely. They will continue running for days with no data being transferred. Even when I lower the timeout to 120 seconds.
In looking at the Chilkat sftp debug file I see a keepalive message is being sent. I can't tell if it's coming from the client or the server. Below is what I assume is the relevant section of the log. I don't know why the transfer stops and this keepalive thing starts happening. I doubt the server administrators are going to cooperative in helping me debug it. I just want a way to detect when the situation is happening and have the transfer fail. I can log an error and recover if I can detect the situation occurring. My current line of thinking is that I set EnableEvents and KeepSessionLog equal to true and then check the SessionLog string for "keepalive@openssh.com" in the OnAbortCheck. Existence of that substring would start a timer and I would abort the process after n seconds of continued inactivity.
I guess my question is, is there an easier way to detect this scenario? Are there some settings I could change to avoid it in the first place? Again, setting the timeout properties doesn't seem to help.
One other note is that when this happens the OnPercentDone event seems to stop firing.
Following is the log:
SFTP< Received SSH_FXP_HANDLE
timeToOpenMs: Elapsed time: 31 millisec
uploadFile:
handle: 00000000
fromLocalPath: [....]
sendAheadMaxCount: 12
openForReadWin32:
(leaveContext)
localFileSize2: 214619512
serverWindowSize: 2147614652
readChannelData_2:
genRead_1:
(leaveContext)
(leaveContext)
readChannelData_2:
genRead_1:
(leaveContext)
(leaveContext)
readChannelData_2:
genRead_1:
(leaveContext)
(leaveContext)
[....]
readChannelData_2:
genRead_1:
(leaveContext)
(leaveContext)
readChannelData_2:
genRead_1:
Received CHANNEL REQUEST message
requestType: keepalive@openssh.com
wantReply: 1
Received CHANNEL REQUEST message
requestType: keepalive@openssh.com
wantReply: 1
No Chilkat method call should ever hang indefinitely, unless one of the timeout related properties is set to 0 to indicate that waiting forever is the intended behavior.
The first thing to do is to verify that the timeout related properties are not set to 0. These are the ConnectTimeoutMs and IdleTimeoutMs properties. If your app explicitly sets these properties to 0, then it is asking for an infinite wait time and the app can hang.
The 2nd thing to check is that maybe the timeouts are set to a long amount of time, or even the default of 30 seconds (30,000 ms) and maybe what seems to be an indefinite hang is something that would eventually return.
The 3rd thing to verify is that the hang is not occurring within your app code inside an event callback.
Finally, if Chilkat is truly hanging, then the way to get more information is via the DebugLogFilePath property, which is common to all Chilkat classes.
Setting the DebugLogFilePath property causes each Chilkat method or property call to automatically append it's LastErrorText to the specified log file. The information is appended such that if a hang or crash occurs, it is possible to see the context in which the problem occurred, as well as a history of all Chilkat calls up to the point of the problem. The VerboseLogging property can be set to provide more detailed information. This property is typically used for debugging the rare cases where a Chilkat method call hangs or generates an exception that halts program execution (i.e. crashes). A hang or crash should generally never happen. The typical causes of a hang are: (1) a timeout related property was set to 0 to explicitly indicate that an infinite timeout is desired, (2) the hang is actually a hang within an event callback (i.e. it is a hang within the application code), or (3) there is an internal problem (bug) in the Chilkat code that causes the hang.