libURL gone mad

[Richard Gaskin]

Charles Warwick wrote:

 > I would like to resolve as many libUrl reliability issues as possible
 > in the community edition as well.
 >
 > Having worked on the tsNet libUrl wrapper, I have some ideas about
 > what is going on but what always helps is a sample script that can
 > reproduce the problem.

Thanks for your interest.  I've modded my libURL and have been 
experimenting, will deliver a sample stack soon.

Thus far I've found that your libURL function is much more reliable than 
the recommended flag option, but still problematic in some cases unless 
I slow things down with the introduction of an otherwise-unnecessary wait.

Chipp Walters uses a brute-force method since picked up by Jacque and 
others in which he calls libURL in a repeat loop until it returns a 
meaningful result.  Sad to have to work that hard.

At the heart of why so many people seem to be having problems with 
libURL is that the so-called "blocking" form only blocks the current 
execution instance of the handler calling libURL.  Messages still 
happen, any handlers that are calling libURL are re-entrant, and that's 
where people are seeing blocked connections, engine hangs, and 
occasional cursor locking (WTH is up with that?).

The ideal solution would be for an option to have true blocking, without 
the semi-quasi-difficult-to-predict-exactly-what's-happening form of 
threading in place for the so-called "blocking" form offered currently.

Those who need non-blocking can use "load url".  Works fine, at least 
for GET.

Maybe the issue is that POST doesn't currently have a non-blocking form, 
so the design in place now attempts to hit some mystifying middle path 
between true blocking and truly async behavior, hitting neither quit 
spot-on.

I'll continue my experiments with various permutions, including Chipp's 
now-famous hammer-on-it-until-it-behaves option, and see if I can come 
up with something that doesn't require slowing down the workflow with an 
otherwise-unnecessary wait statement.

It's not a long wait (right now the shortest wait that prevent hangs is 
around 250 ms), but the issue of preventing re-entrance remains a challenge.

I may wind up keeping a checksum hash of the url + POST data, monitored 
in a timer to prevent duplicate attempts from happening too close 
together.   Seems a lot of work, though, for something where the code 
would be MUCH simpler if we only have a truly blocking GET and POST option.

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com