is this a bug that has been reported or should be?

Josh Mellicker josh at dvcreators.net
Fri Nov 30 14:24:26 EST 2007


Rev seems to want to initiate an additional FTP connection for each  
file uploaded...

The problem with this is that when uploading small files, with the  
default libURLSetFTPStopTime, if a new file uploads before that  
interval, Rev will quickly use up all the available ftp connections  
for a server, preventing anyone (or Rev) from ftp access to that  
server (until the connection is manually closed (or times out?).



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
>>> use-revolution at lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your  
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-revolution
>>>
>>>
>>
>> _______________________________________________
>> use-revolution mailing list
>> use-revolution at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your  
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-revolution
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution




More information about the use-livecode mailing list