libURL gone mad

[Phil Davis]

Richard,
You could always write yourself a curl wrapper... just sayin'.

Phil Davis


On 9/2/16 9:28 AM, Richard Gaskin wrote:
> 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.
>

-- 
Phil Davis