sending a request 1

[JeffChilders]

is there a way to send a url request without recieving the response?

 

[siberian]

From within a CGI you can use LWP and just not check the response. Send and continue on..

 

[arcnon]

how do I do that

just do a

get($URL);

or do you mean something else?

 

[siberian]

Check the docs:

        # Create a user agent object
         use LWP::UserAgent;
         $ua = LWP::UserAgent->new;
         $ua->agent("MyApp/0.1 ");

         # Create a request
         my $req = HTTP::Request->new(GET=> '[URL unfurl="true"]http://search.cpan.org/search?bla=bla');[/URL]

         # Pass request to the user agent and get a response back
         my $res = $ua->request($req);

Don't check the response if you don't care but do know that your script goes into a wait state until LWP returns. To fire it off and see no lag you'll have to fork it (bad idea in CGI!)

 

[arcnon]

the lag/responce is what I am tring to dodge hence the send "a url request without recieving the response". I have adopted a web site that was dynamic and has been restyled into static pages generated from several databases. The content which is updated by 153 scripts.

when the internal users update the datebase I have to send a request so that the new page can be generated and placed on the server. Now normally I would just use the perl script itself but I am working with 7 servers that handle the web content and passwords have to be sent to access the various servers. I tried expect but for some reason I cant get it to work and after talking with the sys admin. He ruled out the use of expect.

So doing it as a cgi just seemed the easiest solution at the moment. End the end I will have all the processes sync'd but I need a work around until the backend is rewrote.

 

[siberian]

Yea, forking is your only method for this one, something I do not advocate on systems that see any sort of load, you end up with rogue processes in the system.

One thing I have done in the past in similiar situations is to write a deamon that sits and listens on a port.

Your app pings the daemon and then disconnects. This is very rapid.

The deamon then goes off and runs your commands outside of user space, taking all the time it needs and not impacting your users experience.

This has worked very well for us.

 

[JeffChilders]

siberian,

thanks. I guess you use net:ing? or Net::Telnet with the deamon?. I am interested in your solution. If you have so code lying around for me to look at I would greatly appreciate it. Til then I'll see what I acn come up with.

jeff

 

[JeffChilders]

looking in the perl cookbook I followed the example in making a server now I put in the daemon stuff so it will run on its own.

how do I kill it? from the wrapping code
heres what I have so far.....

sub signal_handler {
$time_to_die = 1;
}

$SIG{INT} = $SIG{TERM} = $SIG{HUP} = \&signal_handler;
# trap or ignore $SIG{PIPE}

 

[siberian]

Sorry, when I say 'ping' I mean 'tickle' or 'somehow send it a message'.

Generally for me its a quick GET request with the details of the request on the URI. The daemon logs this info and then uses it to make the subrequests on my behalf.

As for kill it, you mean kill the entire daemon or the process it creates to do LWP?

 

[arcnon]

after I tought about it for a while I figured out what you meant.

yes kill the server process

the main server code is wrapped in a
until ($time_to_die = 1)

as it reads the input
if ($data =~/quit|q/){
signal_handler();
print "goodbye\n";
}
but the process doesn't die