RE: start http request and move on

[Moon, John]

-Original Message-
From: JupiterHost.Net [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, November 03, 2004 4:23 PM
To: [EMAIL PROTECTED]
Subject: start http request and move on

Hey group,

Not sure how I'd go about doing a url (via LWP probably) but not wait
for it to return.


  print "Starting...\n";
  nowaiturl("$url?foo=bar");
  print "$url has been submitted. When it finishes running you'll get an
email. Have a super day\n"; # or whatever :)


The idea is to be able to submit data to $url for it to be processed 
(which may take a while)
without waiting for it to finish.

LWP::Parallel does mutiple $urls in parallel but I want to submit a 
single url like you would with LWP but not wait, does that make sense?

Would a fork() of some sort be the best way?

Or what is that even called so I can look around for it?

[jwm] 
Don't use LWP but in my CGI scripts I set $| to nonzero ... to do what you
want... 

jwm


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

Re: start http request and move on

[JupiterHost.Net]

The idea is to be able to submit data to $url for it to be processed 
(which may take a while)
without waiting for it to finish.

LWP::Parallel does mutiple $urls in parallel but I want to submit a 
single url like you would with LWP but not wait, does that make sense?

Would a fork() of some sort be the best way?
Or what is that even called so I can look around for it?
[jwm] 
Don't use LWP but in my CGI scripts I set $| to nonzero ... to do what you
want... 
Thanks, I'm not worried about flushing output, I want to submit the url 
and move on like so:

say, it takes the entire http session 60 seconds from start to finish to 
submit the url, the script to run and return the results

I want:
 print "Starting...\n";
 nowaiturl("$url?foo=bar");
 print "$url has been submitted, in appx 60 seconds it will finish";
to run in like it had been (obviously it'll take a bit more than print() 
but it illustrates the idea):
 print "Starting...\n";
 print "$url?foo=bar";
 print "$url has been submitted, in appx 60 seconds it will finish";

make sense?
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

Re: start http request and move on

[JupiterHost.Net]

say, it takes the entire http session 60 seconds from start to finish to 
submit the url, the script to run and return the results

I want:
 print "Starting...\n";
 nowaiturl("$url?foo=bar");
 print "$url has been submitted, in appx 60 seconds it will finish";
to run in like it had been (obviously it'll take a bit more than print() 
but it illustrates the idea):
 print "Starting...\n";
 print "$url?foo=bar";
 print "$url has been submitted, in appx 60 seconds it will finish";

make sense?
I attempted this with fork() (code modified from 
http://www.perl.com/pub/a/2003/01/07/mod_perl.html?page=2)but it still 
seems the parent (or at least the time it takes the script to finish) 
waits for the child to finish:

#!/usr/bin/perl
use strict;
use warnings;
$SIG{CHLD} = 'IGNORE';
defined (my $kid = fork) or die "Cannot fork: $!\n";
if ($kid) {
  sleep(2); # fake command taking time
  # print "Doing url now - Parent $$ has finished, kid's PID: $kid\n";
} else {
  print "Hello\n";
}
Any ideas how I can get the child process code to go on once the child 
is started and once the parent finishes the entire script is done?

As in if you execute that script I want it to do:
# ./scriptabove.pl
Hello
#
super fast while the kid's sleep(2) (in real life code that might take a 
few seconds) doesn't make it wait for 2 seconds for the next prompt to 
show up.

Looking over
perlddoc perlipc
now...
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

RE: start http request and move on

[NYIMI Jose \(BMB\)]

> -Original Message-
> From: JupiterHost.Net [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, November 03, 2004 10:23 PM
> To: [EMAIL PROTECTED]
> Subject: start http request and move on
> 
> 
> Hey group,
> 
> Not sure how I'd go about doing a url (via LWP probably) but 
> not wait for it to return.
> 
> 
>   print "Starting...\n";
>   nowaiturl("$url?foo=bar");
>   print "$url has been submitted. When it finishes running 
> you'll get an email. Have a super day\n"; # or whatever :)
> 
> 
> The idea is to be able to submit data to $url for it to be processed 
> (which may take a while)
> without waiting for it to finish.
> 
> LWP::Parallel does mutiple $urls in parallel but I want to submit a 
> single url like you would with LWP but not wait, does that make sense?
> 
> Would a fork() of some sort be the best way?
> 
> Or what is that even called so I can look around for it?


Randal has written an excellent column and shown how to deal with such needs.
Have a look to
http://www.stonehenge.com/merlyn/LinuxMag/col39.html

HTH,

José.


 DISCLAIMER 

"This e-mail and any attachment thereto may contain information which is confidential 
and/or protected by intellectual property rights and are intended for the sole use of 
the recipient(s) named above. This email is not intended to create or affect any 
contractual arrangements between the parties.
Any use of the information contained herein (including, but not limited to, total or 
partial reproduction, communication or distribution in any form) by other persons than 
the designated recipient(s) is prohibited. 
If you have received this e-mail in error, please notify the sender either by 
telephone or by e-mail and delete the material from any computer".

Thank you for your cooperation.

For further information about Proximus mobile phone services please see our website at 
http://www.proximus.be or refer to any Proximus agent.


--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

Re: start http request and move on

[JupiterHost.Net]

Randal has written an excellent column and shown how to deal with such needs.
Have a look to
http://www.stonehenge.com/merlyn/LinuxMag/col39.html
Thanks Jose, and Randal too :),
very close indeed the only difference is I don't want the user to wait 
at all, just submit the form, they see the confirmation and close their 
browser and the fork() finished in its own sweet time on the server.

I think the best thing might be to put the goods in a file and have 
another script process the file via cron evry so often, I just didn't 
want to have to involve 2 scripts to keep track of :)

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

RE: start http request and move on

[Bob Showalter]

JupiterHost.Net wrote:
> I don't want the user to wait
> at all, just submit the form, they see the confirmation and close
> their browser and the fork() finished in its own sweet time on the
> server. 

Use something like the following:

  #!/usr/bin/perl

  use strict;
  use CGI ':standard';
  use POSIX 'setsid';

  defined(my $pid = fork) or die "Couldn't fork: $!";
  if ($pid) {
  print header,
  start_html,
  p("Process $pid has been started"),
  end_html;
  exit;
  }

  close STDIN;
  close STDOUT;
  setsid();

  # at this point your process is detached from the web server,
  # so start your long-running process now

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

RE: start http request and move on

[Murphy, Ged (Bolton)]

-Original Message-
From: JupiterHost.Net [mailto:[EMAIL PROTECTED]
Sent: 05 November 2004 15:14
To: [EMAIL PROTECTED]
Subject: Re: start http request and move on



Thanks Jose, and Randal too :),
very close indeed the only difference is I don't want the user to wait 
at all, just submit the form, they see the confirmation and close their 
browser and the fork() finished in its own sweet time on the server.

I think the best thing might be to put the goods in a file and have 
another script process the file via cron evry so often, I just didn't 
want to have to involve 2 scripts to keep track of :)


--

A very shoddy way of doing it, but you could put what you want to do in
another script, call system() and place it in the background so you original
script doesn't wait for it to return.

.
system "perl script.pl any arguments &";
.

I assume this would work, but am not 100% sure without trying it.





The information contained in this message or any of its
attachments is confidential and is intended for the exclusive
use of the addressee. The information may also be legally
privileged. The views expressed may not be company policy,
but the personal views of the originator. If you are not the
addressee, any disclosure, reproduction, distribution or other
dissemination or use of this communication is strictly prohibited.
If you have received this message in error, please contact
[EMAIL PROTECTED] 
<mailto:[EMAIL PROTECTED]> and then delete this message. 

Exide Technologies is an industrial and transportation battery
producer and recycler with operations in 89 countries.
Further information can be found at www.exide.com



-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>

Re: start http request and move on

[JupiterHost.Net]

A very shoddy way of doing it, but you could put what you want to do in
another script, call system() and place it in the background so you original
script doesn't wait for it to return.
.
system "perl script.pl any arguments &";
.
I assume this would work, but am not 100% sure without trying it.
Yes, it works great:
#!/usr/bin/perl
use strict;
use warnings;
print "start\n";
system "perl -e 'sleep(3);`echo system >> long.txt`;' &";
print "end\n";
print "exec\n"; # do it at the end instead with exec() not sure if there 
is an advantage of either one in this case besides maybe return from 
system()
exec "perl -e 'sleep(3);`echo exec  >> long.txt`;' &";

I agree an external script isn't real great but it does have the effect 
I wanted thank you so much for the great idea!

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

Re: start http request and move on

[JupiterHost.Net]

Bob Showalter wrote:
JupiterHost.Net wrote:
I don't want the user to wait
at all, just submit the form, they see the confirmation and close
their browser and the fork() finished in its own sweet time on the
server. 

Use something like the following:
  #!/usr/bin/perl
  use strict;
  use CGI ':standard';
  use POSIX 'setsid';
  defined(my $pid = fork) or die "Couldn't fork: $!";
  if ($pid) {
  print header,
  start_html,
  p("Process $pid has been started"),
  end_html;
  exit;
  }
  close STDIN;
  close STDOUT;
  setsid();
  # at this point your process is detached from the web server,
  # so start your long-running process now

Thanks Bob, That works great! Now the next step is to play with that in 
a peristent  environment without killing the persistent process with the 
exit() Perhapst the system + & will do better in a persistent 
environement...
I'll have to play around with those now and see :)

Thanks to every one who helped me out!

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

RE: start http request and move on

[Bob Showalter]

JupiterHost.Net wrote:
> Bob Showalter wrote:
...
> > Use something like the following:
...
> Thanks Bob, That works great! Now the next step is to play with that
> in a peristent  environment without killing the persistent process
> with the exit() Perhapst the system + & will do better in a persistent
> environement...

You don't need to call exit if you just put the other stuff in an else {}
block so the parent doesn't execute it. If you're running under
Apache::Registry though, calling exit is OK.

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

Re: start http request and move on

[Gunnar Hjalmarsson]

Bob Showalter wrote:
If you're running under Apache::Registry though, calling exit is OK.
If I have understood it correctly, it's not OK if Perl is older than 
5.6. Therefore I'm using this sub:

sub myexit {
if ($ENV{MOD_PERL}) {
if ($] < 5.006)  {
require Apache;
Apache::exit();
}
}
exit;
}
P.S. Thanks for showing a simple way to fork off a process. It will be 
useful to me as well.

--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

Re: start http request and move on

[JupiterHost.Net]

You don't need to call exit if you just put the other stuff in an else {}
block so the parent doesn't execute it. If you're running under
Apache::Registry though, calling exit is OK.
Perfect, the else {} works great! I'll need to read up on fork and all 
that so I can really get it :)

Thanks so much for the assist!
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

RE : start http request and move on

[Jose Nyimi]

> -Message d'origine-
> De : Bob Showalter [mailto:[EMAIL PROTECTED]
> Envoyé : vendredi 5 novembre 2004 19:40
> À : 'JupiterHost.Net'; [EMAIL PROTECTED]
> Objet : RE: start http request and move on
> 
> JupiterHost.Net wrote:
> > Bob Showalter wrote:
> ...
> > > Use something like the following:
> ...
> > Thanks Bob, That works great! Now the next step is to play with that
> > in a peristent  environment without killing the persistent process
> > with the exit() Perhapst the system + & will do better in a
persistent
> > environement...
> 
> You don't need to call exit if you just put the other stuff in an else
{}
> block so the parent doesn't execute it. If you're running under
> Apache::Registry though, calling exit is OK.
> 

Nice approach, I have learned today an easy to do it :)
Though care should be taken to not fork many *uncontrolled* childs.

Rgds,
José. 



--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>

Re: RE : start http request and move on

[JupiterHost.Net]

Nice approach, I have learned today an easy to do it :)
Though care should be taken to not fork many *uncontrolled* childs.
Could you elaborate what uncontrolled children are specifically and what 
should be avoided?
(In context of this thread of course not the little humans running 
around like crazy ;p)

Rgds,
José. 
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

RE: RE : start http request and move on

[Larsen, Errin M HMMA/IT]

> -Original Message-
> From: JupiterHost.Net [mailto:[EMAIL PROTECTED] 
> Sent: Friday, November 05, 2004 3:08 PM
> To: [EMAIL PROTECTED]
> Cc: Jose Nyimi
> Subject: Re: RE : start http request and move on
> 
> 
> 
> > Nice approach, I have learned today an easy to do it :) Though care 
> > should be taken to not fork many *uncontrolled* childs.
> 
> Could you elaborate what uncontrolled children are 
> specifically and what 
> should be avoided?
> (In context of this thread of course not the little humans running 
> around like crazy ;p)
> 
> > Rgds,
> > José.
> 
> -- 

Hi,

I've been lurking on this thread for a bit, and now that you've jumped to children and 
fork and related topics I'll chime in!

I found a lot of useful information about this sort of thing in "perldoc perlipc".  
Check out the stuff about Daemons and the REAPER subroutine in that doc.  Also, in the 
cookbook (I think! I don't have it with me to check) there is some good stuff about 
daemons and children.

More specifically to the questions above, two things to be careful of:

First, always, ALWAYS check (then, check again!) that you are not going to fork-bomb 
your system.  If your script, forks (now you have 2), then both of those fork again, 
'cause you have a bug in a loop somewhere (now you have 4) and so on (now there are 8) 
and so on (16 ... Can you see where this is goin?!), you will quickly bring your box 
to a screaching halt!

Second, (I'm assuming this is a UNIX-ey OS) make sure you read up on setsid and 
sys_wait_h in the POSIX (perldoc POSIX) module, as well as the builtin 'waitpid' 
(perldoc -f waitpid).  You might have to 'man' the equivelant to get meaningful 
documentation (like, 'man setsid').

When I fork a process, I like to make sure the child at least does the following: 
- chdir /
   (it's rude for a random process to sit on a filesystem that might need to be 
unmounted)
- change the stdin, stdout and stderr
   (also rude to spurt random nonsense from a random process onto the terminal or 
somesuch)
- setsid
   (So the child can own it's own session)

Like this:

sub daemonize {
chdir '/'   or die "Can't chdir to /: $!";
open STDIN, '/dev/null' or die "Can't read /dev/null: $!";
open STDOUT, '/dev/null'or die "Can't write to /dev/null: $!";

defined( my $pid = fork )   or die "Can't fork the child: $!";

   #The exit below can be replaced with an if-else construct if you want the 
original to keep going.
   #I believe this has been handled in this thread already!
exit if $pid;   # original process dies here
setsid  or die "Can't start a new session: $!";
open STDERR, '>&STDOUT' or die "Can't duplicate STDOUT: $!";
}

I hope this helps a bit.  Let me know if ya got more questions,

--Errin

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>

Re: RE : start http request and move on

[JupiterHost.Net]

Hi,
Hello :)
I've been lurking on this thread for a bit, and now that you've jumped to children and 
fork and related topics I'll chime in!
I found a lot of useful information about this sort of thing in "perldoc perlipc".  
Check out the stuff about Daemons and the REAPER subroutine in that doc.  Also, in the cookbook 
(I think! I don't have it with me to check) there is some good stuff about daemons and children.
More specifically to the questions above, two things to be careful of:
First, always, ALWAYS check (then, check again!) that you are not going to fork-bomb 
your system.  If your script, forks (now you have 2), then both of those fork again, 
'cause you have a bug in a loop somewhere (now you have 4) and so on (now there are 8) 
and so on (16 ... Can you see where this is goin?!), you will quickly bring your box 
to a screaching halt!
Second, (I'm assuming this is a UNIX-ey OS) make sure you read up on setsid and 
sys_wait_h in the POSIX (perldoc POSIX) module, as well as the builtin 'waitpid' 
(perldoc -f waitpid).  You might have to 'man' the equivelant to get meaningful 
documentation (like, 'man setsid').
When I fork a process, I like to make sure the child at least does the following: 
- chdir /
   (it's rude for a random process to sit on a filesystem that might need to be unmounted)
- change the stdin, stdout and stderr
   (also rude to spurt random nonsense from a random process onto the terminal or somesuch)
- setsid
   (So the child can own it's own session)

Like this:
sub daemonize {
chdir '/'   or die "Can't chdir to /: $!";
open STDIN, '/dev/null' or die "Can't read /dev/null: $!";
open STDOUT, '/dev/null'or die "Can't write to /dev/null: $!";
defined( my $pid = fork )   or die "Can't fork the child: $!";
   #The exit below can be replaced with an if-else construct if you want the 
original to keep going.
   #I believe this has been handled in this thread already!
exit if $pid;   # original process dies here
setsid  or die "Can't start a new session: $!";
open STDERR, '>&STDOUT' or die "Can't duplicate STDOUT: $!";
}
I hope this helps a bit.  Let me know if ya got more questions,
Very good info thanks, I'm learning a lot!
Since this isn't going to be a daemon (its a webpage that gives the 
visitor what they came for and then does some stuff on the server 
without them having to wait) and in conjunction with Bob's earlier 
suggetion (slightly modified):

#!/usr/bin/perl
use strict;
use warnings;
use CGI 'header';
use POSIX 'setsid';
defined(my $pid = fork) or die "Couldn't fork: $!";
if ($pid) {
print header();
print "Hello World\n";
} else {
  close STDIN;
  close STDOUT;
  setsid();
  # at this point your process is detached from the web server,
  # so start your long-running process now
  open FILE, '>> ./long.txt' or die $!;
  print FILE $$;
  sleep 3;
  print FILE ' ' . time() . "\n";
  close FILE;
}
What and were would you modify it to be safe? (the open stuff is just to 
take time up so we can see the original "web page" being out put and 
back to a prompt)

try it, its cool:
 ./long.pl
 tail -f long.txt
You'll see long.pl finishes running (putting you back to a prompt) and 
then the stuff is added to long.txt, very cool!

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 

RE: RE : start http request and move on

[Christopher Maujean]

On Fri, 2004-11-05 at 13:39, Larsen, Errin M HMMA/IT wrote:
> > -Original Message-
> > From: JupiterHost.Net [mailto:[EMAIL PROTECTED] 
> > Sent: Friday, November 05, 2004 3:08 PM
> > To: [EMAIL PROTECTED]
> > Cc: Jose Nyimi
> > Subject: Re: RE : start http request and move on
> > 
> > 
> > 
> > > Nice approach, I have learned today an easy to do it :) Though care 
> > > should be taken to not fork many *uncontrolled* childs.
> > 
> > Could you elaborate what uncontrolled children are 
> > specifically and what 
> > should be avoided?
> > (In context of this thread of course not the little humans running 
> > around like crazy ;p)
> > 
> > > Rgds,
> > > JosÃ.
> > 
> > -- 
> 
> Hi,
> 
> I've been lurking on this thread for a bit, and now that you've jumped to children 
> and fork and related topics I'll chime in!
> 
> I found a lot of useful information about this sort of thing in "perldoc perlipc".  
> Check out the stuff about Daemons and the REAPER subroutine in that doc.  Also, in 
> the cookbook (I think! I don't have it with me to check) there is some good stuff 
> about daemons and children.
> 
> More specifically to the questions above, two things to be careful of:
> 
> First, always, ALWAYS check (then, check again!) that you are not going to fork-bomb 
> your system.  If your script, forks (now you have 2), then both of those fork again, 
> 'cause you have a bug in a loop somewhere (now you have 4) and so on (now there are 
> 8) and so on (16 ... Can you see where this is goin?!), you will quickly bring your 
> box to a screaching halt!
> 
> Second, (I'm assuming this is a UNIX-ey OS) make sure you read up on setsid and 
> sys_wait_h in the POSIX (perldoc POSIX) module, as well as the builtin 'waitpid' 
> (perldoc -f waitpid).  You might have to 'man' the equivelant to get meaningful 
> documentation (like, 'man setsid').
> 
> When I fork a process, I like to make sure the child at least does the following: 
> - chdir /
>(it's rude for a random process to sit on a filesystem that might need to be 
> unmounted)
> - change the stdin, stdout and stderr
>(also rude to spurt random nonsense from a random process onto the terminal or 
> somesuch)
> - setsid
>(So the child can own it's own session)
> 
> Like this:
> 
> sub daemonize {
> chdir '/'   or die "Can't chdir to /: $!";
> open STDIN, '/dev/null' or die "Can't read /dev/null: $!";
> open STDOUT, '/dev/null'or die "Can't write to /dev/null: $!";
> 
> defined( my $pid = fork )   or die "Can't fork the child: $!";
> 
>#The exit below can be replaced with an if-else construct if you want the 
> original to keep going.
>#I believe this has been handled in this thread already!
> exit if $pid;   # original process dies here
> setsid  or die "Can't start a new session: $!";
> open STDERR, '>&STDOUT' or die "Can't duplicate STDOUT: $!";
> }
> 
> I hope this helps a bit.  Let me know if ya got more questions,
> 
> --Errin


when you do want to code a daemon, you also might take a look at
Proc::Daemon which does most, if not all, of what the code above does.

--Christopher


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>