Getting a response from a Perl script 2

[audiopro]

I have a VFP6 app which uploads a file onto a remote server, processes the contents of the file and populates a MySQL database with the contents. That is all working fine but I want to pass some information back from the server to the calling VFP6 application. Is there an API for this or is there a much simpler approach? I am just looking for a bit of guidance on this.

Keith

http://www.studiosoft.co.uk

 

[Mike Lewis]

Keith, I wonder if just pausing for a few hundred millisecs after the OpenURL call will solve it. It might be worth a try.

Just for testing purposes, try putting [tt]WAIT TIMEOUT 1[/tt] immediately after the call, just to see if that makes any difference.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Perhaps you should use something like this:

http://perl.about.com/od/perltutorials/a/hellocgi.htm

This perl script ends with

exit;

Perhaps the most important part missing from your perl script.

So try this:

#!/usr/bin/perl
print "Content-type: text/html\n\n";
print "Yippee"; 
exit;

Bye, Olaf.

 

[audiopro]

I like to think I am a bit beyond writing basic hello world scripts in perl. I have done this, passing strings from Perl scripts, many times in Flash and never seen this error before even when the script has been returning large amounts of data after doing all kinds of processes.
Usually, I get the 'yippee' string almost immediately although occasionally I get the error and in that case, ' yippee' is never returned so it looks like the process is synchronous.

The 'exit' at the end of a Perl script is optional and I have run hundreds of scripts without it, no problem.
New CGI is necessary to process incoming form information and while not being used in the test script, it is needed in the main script I am using. Once again, this is an issue I have never seen before.

I am using it for it's intended purpose now and all seems to be well, it only seemed to error with the test script - very odd.

Keith

http://www.studiosoft.co.uk

 

[Mike Lewis]

Just out of interest, did you try my timeout idea? I'm not insisting that it will work - just the opposite - but I thought it would be interesting to try it.

On the other hand, given that you've got it working in the production environment, it might not be worth worrying about.

I would just add that I am reasonably sure the problem has got nothing to do with Perl. My bet is that whatever is causing the error would still do so even if the URL pointed to a simple HTML page.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[audiopro]

The error occurs after a program error, the function (hope that is the correct phrase) is still hanging.
This wouldn't happen if I wrote perfect code, every time.

Question then is, how do I clean it up after an error?

Keith

http://www.studiosoft.co.uk

 

[Olaf Doschke]

>how do I clean it up after an error

Well, your perl script needs to exit gracefully. As far as I read you use die when an error occurs and elevate up the call chain so finally a global error handler can handle the error.

On the VFP side you should nevertheless get a response, maybe an errorcode instead of the normal body. But it should end, if it doesn't end the problem rather is to search within web server or perl. The InetCtls.Inet class can just wait, it has no way to get into what is running server side and why it doesn't respond, it just can wait untile a timeout, if there is one.

So the only thing to do VFP side is to RELEASE oINet in case of an error and start a fresh instance with CREATEOBJECT() again. There is nothing you can do to force the server or perl to respond. HTTP is a stateless protocol, you're not connected like you are to a file via file handle.

Bye, Olaf.

 

[audiopro]

OLE |Dispatch exception code 0 from Inet. Still executing last request

This is not a Perl error.

Keith

http://www.studiosoft.co.uk

 

[Olaf Doschke]

Well, Yes, I know, Keith

But it's coming from Inet, more precise from InetCtls.Inet

And when does it happen? When you do oInet.OpenURL("

http://www.mysite.co.uk/cgi-bin/httpreq.pl"),

right?
And why does it error then? Bingo.

Bye, Olaf.

 

[Mike Lewis]

There's an easy way of settling this:

Try calling OpenURL with a URL pointing to a plain HTML file. If the same error occurs (and my bet is that it will), then the problem has got nothing to do with Perl.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

If you don't get "Bingo".

Here's what you wrote the error message is:

Still executing last request

So InetCtls.Inet is just saying it can't do your new OpenURL, becuase the previous request still isn't responded to and no timeout has yet occurred. You can then either use a new InetCtls.Inet instance or wait.

The reason the previous call didn't return a respond yet can be, it still takes time to work, or it errored and ended in a way not giving any response to the caller, to the oInet. You may set oInte.ResponseTimeout lower, but if it is too low, the normal time your perl scripts needs to process the file would perhaps cause the OpenURL call to return with timeout error. Then you also don't know, if your perl call was successfull in the end.

One way to cope with this is not reusing oINET and always using a fresh new instance of InetCtls.Inet to not have to wait for a previous call. I don't see how the error "Still executing last request" is a problem on the FoxPro side.

Is that helping a bit?

You may try the asynchronous approach und use MSXML2.XMLHTTP.6.0 or MSXML2.XMLHTTP.3.0 instead of InetCtls.Inet

loRequest = Createobject('MSXML2.XMLHTTP.6.0') && use 3.0 istead of 6.0 if your Windows version doesn't have MSXML6
lcReply = oInet.OpenURL("[URL unfurl="true"]http://www.mysite.co.uk/cgi-bin/httpreq.pl")[/URL] 
loRequest.Open("GET", "[URL unfurl="true"]http://www.mysite.co.uk/cgi-bin/httpreq.pl",[/URL] .T.)
loRequest.Send(.NULL.)
DO WHILE loRequest.ReadyState # 4
   DOEVENTS FORCE
ENDDO

If the problem is the webserver doesn't respond, this code will get stuck in the while loop. And then you can be sure the problem is on the server side, and if it's not your script it's MySQL or the webserver itself.

Also the MSXML2.XMLHTTP.6.0 has it's timeouts, it has a method setTimeouts, which sets 4 timeouts, for url adress resolving, connecting, sending and receiving, so the 4th timeout is interesting to set it higher (or lower) and test what's going on server side.

There also are webserver side timouts, that may apply. If your file is larger and perl or MySQL are not that fast, you might get into a state the timeout applies and you get no graceful end of your request with a good response.

Even if there is no error in your perl and your file and mysql and the web server, that timout may bite you.

Bye, Olaf.

 

[Olaf Doschke]

>Try calling OpenURL with a URL pointing to a plain HTML file. If the same error occurs (and my bet is that it will), then the problem has got nothing to do with Perl.

I doubt that logic mike, because the problem then still is the last request and not the current request. And the last request was the perl script request. I rather assume it's the timeout problem. Apache or IIS stop waiting for asp.net, php or perl or any other scripting language, if they don't return back after a configurated timout.

For example if the data Keith sends in gets more and more and the time processing it raises, it's only a question of time when this will lead to a timeout problem.

Bye, Olaf.

 

[audiopro]

The simple script is over in a heartbeat so I don't think it is a timeout on the server.
I have been using it for quite a while and it is doing a lot more than it was in the initial test script, without error.

I think the best way will be to continue using it and see how it goes.

Keith

http://www.studiosoft.co.uk

 

[Olaf Doschke]

Well, You never know, anything can happen. Even a script just taking a heartbeat everytime can take long at one time there is any problem, the error is quite clear about the previous request being the problem, not the current one.

As far as I understand it you have this problem reproducable, or was it just a hickup?`Anything else on the same Windows Server can cause a long running web server request processing, it's typically not the only service running there, is it? Even if you rented a dedicated server.

Bye, Olaf.

 

[audiopro]

This just gets more and more bizarre but bear with me.
For simplicity I have put this code on the click action of a button - call it 'callscript'.
I have changed the URL to that of a .shtml page on the remote server to take Perl out of the equation
I run the program, click the 'callscript' button and get an error every time.
If I run the program, click another button which opens a page for editing using the RUN command, close the edited file and then click the 'callscript' button and the script returns a value.
I have run both routes numerous times and get the same results each time.


Keith

http://www.studiosoft.co.uk

 

[Olaf Doschke]

From what I understand about your test approach, something may be whacky about your windows. Do you go through a Proxy server? Internet configuration is system wide, so that may cause trouble.

I don't know what you mean about the button opening "a page for editing using the RUN command" HTML page?

You said your script processes a file, is the page editing form editing that file and uploading it?

Is it perhaps missing, if you don't do this previous to clikcing the callscript button?

Prerequisites always must be fulfilled before something can work, and things don't always work synchronous, you can save afile upload and already call your script and the file still uploads. That causes file open problems for perl, perhaps.

Whatever, I don't see how this could be related to VFP, as you say you RUN something, which means another process.

Bye, Olaf.

 

[audiopro]

Made a mistake in the description.
The script is not running, the contents of the .shtml page are returned

The run command is opening a text file in notepad for editing, this has nothing to do with the process it just an action which stops the error occuring. The file is not uploaded, it is just opened and closed.
RUN /N3 NOTEPAD &EDFILE

If I issue the 'RUN' line above the error does not occur.
I know it sounds crazy but that is what happens.

Keith

http://www.studiosoft.co.uk

 

[Olaf Doschke]

That sounds like it's merely a timing issue or changing processes "heals" oInet. Then I'd try using MSXML2.XMLHTTP.6.0 instead, it'smore modern anyway, even though it needs open+send instead of OpenURL, you have lots of possibilities more, definint User-Agent, Headers etc.

Bye, Olaf.

 

[audiopro]

Not sure if I am using MSXML2.XMLHTTP correctly but I am getting 'Object OINET is not found'.
What is DOEVENTS FORCE?

Keith

http://www.studiosoft.co.uk

 

[Olaf Doschke]

I don't know why still you have any oInet in code, my code replaces it with loRequest.
DOEVENTS FORCE, look it up. In VFP6 you may only have DOEVENTS without the FORCE clause. It was enhanced in VFP9.

Bye, Olaf.

 

[audiopro]

IO assumed it was that.
I will have another look in the morning.

loRequest = Createobject('MSXML2.XMLHTTP.6.0') && use 3.0 istead of 6.0 if your Windows version doesn't have MSXML6
lcReply = oInet.OpenURL("

http://www.mysite.co.uk/cgi-bin/httpreq.pl")

loRequest.Open("GET", "

http://www.mysite.co.uk/cgi-bin/httpreq.pl",

.T.)
loRequest.Send(.NULL.)
DO WHILE loRequest.ReadyState # 4
DOEVENTS FORCE
ENDDO

Keith

http://www.studiosoft.co.uk