I just tried Sarah's trick:
libURLSetFTPStopTime 1
and the stalled uploading is fixed!
Thanks (again!) Sarah!
On Nov 15, 2007, at 12:53 PM, Sarah Reichelt wrote:
However I find that if I am transferring lots of files, that Rev
opens
a new connection for each file regardless and I rapidly get to a
stage
where the server is rejecting my commands because I have too many
connections open.
Quick response:
Are you doing anything that might close the socket used after each
transfer? This would cause a new session to be opened with the
server, while the server might see the previous session as still
being open.
Not that I know of. I use a libURLftpUploadFile or
libURLDownloadToFile command with a callback. During the transfer I
monitor the URLstatus. In the callback, I check the status again and
it the status is "uploaded" or "downloaded", I just go on to issue the
next libURLftpUploadFile or libURLDownloadToFile command.
Are you checking for errors after each download? An error would cause
libUrl to close the socket, which might result in what you are
seeing.
Yes, I check for errors after every transfer. If I encounter an error
then I stop the process myself.
Decreasing the stop time as you did causes the session to close
cleanly (using the QUIT command) which will keep the server happy.
However, you shouldn't have to do this.
Yes, it woould be neater if the same connection could be kept open,
however I have got a workable solution now.
On Nov 27, 2007, at 3:57 PM, Josh Mellicker wrote:
We just found out something:
Someone noticed it was always the 4th file that stalled (hung on
status "connecting...")
Well, our server only allows 3 simultaneous FTP connections.
So Rev was initiating a new FTP connection for each upload (using
libURLftpUploadFile)
Can I force Rev to use the same connection for multiple uploads?
Or, can I make it close the connection after each successful
upload, so I don't run out of connections?
(increasing the limit on our server is not a solution- it will help
us, but not others :-)
On Nov 10, 2007, at 2:01 AM, viktoras didziulis wrote:
hi Josh,
if you upload via ftp try increasing libURLSetFTPStopTime to
anything more than the default 15 seconds. Dictionary says: use
the libURLSetFTPStopTime command to increase the efficiency of
multiple FTP transfers. The timeout set by libURLSetFTPStopTime
controls when Revolution closes the connection from its end.
or try setting the socketTimeoutInterval to some astronomic value
like 30 000 (the default is 10 000, which means 10 sec). Some time
ago this solved my problems with stalled downloads :-)
Best wishes
Viktoras
Josh Mellicker wrote:
I am uploading a list of files.
After uploading a few files with no problem, uploading "stalls"
with no progress, and no timeout message is sent.
The first thing I tried was implementing a "red light/green
light" to make the upload blocking, so the second file would wait
(with messages) for the first file to successfully finish
uploading before proceeding, and so on. This seemed to help a
little, but uploading still stalls intermittently.
Big Watcher
The next thing was, once the uploading begins, to start a "Big
Watcher" callback loop, that acts as a "Supervisor" to monitor
the libURLSetStatusCallback callback, with a 2 second non-
blocking loop- send "checkForStalledUpload" to me in 5 seconds
If the status and bytes downloaded match, the Supervisor assumes
the current upload is stalled and does a "resetAll" and starts
over on the first unuploaded file.
In theory, this sounds good, but so far, we haven't been able to
get the "resetAll" to work...
Has anyone else experienced stalled libURL operations when
uploading or downloading a list of files? Did you find a solution?
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
