in reply to Post within CGI

Maybe the CGI script is having to look up where the ESB (whatever the heck that is) is located before it can post to it. This can cause the 10 second delay you're mentioning if the nameservers lag. I had the same problem on my DSL for a while. If you can access the ESB (again, what is that?) directly without lagging, I'd try figuring out what the CGI script is using for nameservers.

Can the script post to other things without lag? Or does it lag period?

Replies are listed 'Best First'.
Re^2: Post within CGI
by systemz64 (Initiate) on Dec 14, 2011 at 10:08 UTC

    OK learnt my lesson :-)

    Here is the module code (only the relevant bit)

    package PoxPost; use strict; use LWP::UserAgent; use HTTP::Request::Common; use CGI; use CGI::Carp qw ( fatalsToBrowser ); use XML::Simple; my $esbhost = "http://5.0.10.212:8280/services/"; my $query; ###################################################################### # PostESB ###################################################################### sub PostESB { my $servicename = $_[0]; my $payload = $_[1]; my $userAgent = LWP::UserAgent->new(agent => 'perl post'); my $message = "<tag>".$payload."</tag>"; my $link = $esbhost.$servicename; my $response = $userAgent->request(POST $link, Content_Type => 'application/xml', Content => $message); if ($response->is_success){ return 1; } else{ return 0; } }

    Now here is my test code

    print "start\n"; $svc = "PRUNE"; $msg = "<job>90099368</job><root>/gpfs/STUDIOS/HQ/</root><version>2</v +ersion>"; PoxPost::PostESB($svc, $msg); print "sent\n";

    This test works exactly as expected

    Now here is part of the CGI that is called, and which in turn tries to call the above method

    #!/usr/bin/perl -w use CGI; use CGI::Carp qw ( fatalsToBrowser ); use File::Basename; use File::Copy; use File::Find; use File::Path; use DBI; use POSIX; use lib "/home/zed/ZLIB"; require "poxpost.pl"; ##################################################### # CGI Initialisation ##################################################### # get the form details my $query = new CGI; HTMLHeader(); umask(0); # check action requested my $action = $query->param("action"); # now call required handler if ($action eq "jobversion"){ JobVersionCreate(); } # end header print qq(</body> </html>); # END ###################################################################### +######## # HTMLHeader # ###################################################################### +######## sub HTMLHeader{ print $query->header( ); print qq(<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" +"DTD/xhtml1-strict.dtd">); print qq(<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" +lang="en"> <head>); print qq(<meta http-equiv="Content-Type" content="text/html; chars +et=utf-8" />); print qq(<link href="/compare/style.css" rel="stylesheet" type="te +xt/css" media="screen" />); print qq(</head> <body>); } ###################################################################### +######## # JobVersionCreate ###################################################################### +######## sub JobVersionCreate{ print "creating job version "; # now send message to prune previous versions $payload = "<job>job</job><root>pathroot</root><version>ver</ver>" +; print "<result>OK</result>"; PoxPost::PostESB("COMPARE_PRUNE", $payload); }

    The problem is the call to PostESB. This is where the browser just hangs for several seconds. If I remove this line, it works fine. The test code for the PostESB runs very quick. It is the use within the CGI that is the issue.

    I hope that the above gives you enough info

    Thx Z

      In sub HTMLHeader, "print $query->header()" will create your header... but all the lines that follow, er, create the header... again. That may be part of the problem.

        Sorry - that is actually removed now. But still the same problem.

        Z
      It appears, if I'm reading this correctly, that your test code does not send the same information as your real code. How about you have your test code duplicate the call that's lagging for you and see if you get the same results? If so, then it's probably the ESB service that's lagging, for whatever reason.

      Of course, I could be entirely wrong.