Pendingmessages

[Brian Yennie]

Richard,

If you're uneasy about your current workaround, here are a couple of  
ideas that might help:

1) You could use a blocking shell() command to do the uploads and  
avoid libURL for this particular task.

Example: get shell("curl -T uploadfile -u user:passwd ftp:// 
ftp.upload.com/myfile")

2) Assuming you wrap the upload in a handler, you could possibly  
track the number of uploads running and avoid running more than one  
at a time. If one is already running, another could retry in 10  
second (or whatever interval):

global numUploads
on uploadFile tFile
         if (numUploads > 0) then
            send "uploadFile tFile" to me in 10 seconds
         else
             add 1 to numUploads
             put ... into url ...
             if (success) then subtract 1 from numLoads
         end if
end if

HTH,
Brian

> Here is from our experience. I can't explain why this is happening,  
> but repeated tests show that it does.
>
> 1) Using the blocking form (put url xx into url yy), we experienced  
> that a foreground file transfer that might take 30 seconds would be  
> effected by a pendingmessage file transfer scheduled to occur  
> sometime during the time frame of that foreground transfer
>
> 2) Using the non-blocking form (libURLFTPupload or download), in  
> concert with a "wait until messages" line thereafter, would also be  
> effected by pending messages.
>
> Canceling all pending messages, then resending them after the  
> transfers, helped a great deal. Keep in mind all of these transfers  
> are occurring under strained wireless conditions outdoors over a  
> distance of up to 500 feet, with a signal that can drop briefly at  
> any time. We have to structure all of our transfers with  
> considerable robustness to repeat the transfer over and over again  
> until it is successful.
>
> We've also discovered that the built-in Rev file transferring  
> methods (both blocking and non-blocking) cannot simply be  
> immediately repeated if one fails during a transfer attempt... at  
> least not with Rumpus ftp server software and OSX. The server  
> (under its default settings) rejects subsequent attempts unless we  
> unload the url, send a QUIT command, and wait some period of time  
> before starting the next attempt. We're still trying to come up  
> with a reliable approach to guarantee any downloads or uploads work  
> every time, even if it takes five attempts.
>
> Richard
>
>
> On Mar 5, 2007, at 10:46 AM, Dave Cragg wrote:
>
>>
>> On 5 Mar 2007, at 16:25, Richard Gaskin wrote:
>>
>>>
>>> There's a blocking form for uploading and downloading available  
>>> in libURL, and in the last several versions includes callbacks so  
>>> one can update a progress indicator or do other minor  
>>> housekeeping.  Would that help your situation?
>>
>> I haven't quite grasped Richard's problem of the pendingMessages.  
>> But I doubt it would make a difference whether using "blocking" or  
>> non-blocking url routines. The so-called blocking routines are  
>> only "script-blocking". i.e. they block the currently executing  
>> handler, but will allow other asynchronous activity. (For example,  
>> clicking on an active button during a download, or presumably  
>> executing anything put on the pendingMessages queue before the  
>> "blocking" routine was called.)
>>
>> Generally, anything on the pendingMessages queue will execute  
>> during an FTP file transfer, if it's due to be run at that time.  
>> Depending on the message, it might interfere with the transfer.  
>> For example, a long repeat that exceeds the socketTimeout interval.
>>
>> Cheers
>> Dave
>>
>> _______________________________________________
>> 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
>
>