Loading ...
Sorry, an error occurred while loading the content.

707RE: [soaplite] Forking from a dispatched class

Expand Messages
  • Meisner, Sean
    Jul 31 3:44 PM
    • 0 Attachment
      Hi Paul,
      Calling close() after shutdown() is redundant, shutdown() has closed
      the socket already.

      The difference between close() and shutdown() is:

      close() will close the open socket in ONLY this process.

      shutdown() is more powerful, it closes the socket in this process
      AND in any forked processes that have inherited copies of the open
      socket.

      I will say that I *think* that calling shutdown instead of close on all
      platforms will work, however, it may be unnecessary on platforms other
      than Solaris, and I wouldn't want to absolutely guarantee that there would
      be no unforeseen consequences. Maybe the right approach would be to
      distribute
      the patch as an example, or make something like a "useshutdown => 1"
      parameter
      in the constructor for SOAP::Transport::HTTP::Daemon, making it optional for

      the client programmer whether to use close or shutdown on that socket.

      As to the TCP transport, I haven't looked at that and I don't know whether
      shutdown() would be beneficial there or not. It would depend on the
      structure of the code.. if the dispatched method call is handled BEFORE the
      close(), that dispatched call has the possibilty of forking internally and
      you would see the same problems (at least on Solaris) from the child process

      inheriting the open socket.

      Hope it helps,

      Sean

      > -----Original Message-----
      > From: Paul Kulchenko [mailto:paulclinger@...]
      > Sent: Tuesday, July 31, 2001 6:09 PM
      > To: soaplite@yahoogroups.com
      > Subject: RE: [soaplite] Forking from a dispatched class
      >
      >
      > Hi, Michael!
      >
      > > Paul,
      > > If this is portable, can this find its way into the next release?
      > Sure, no problem, but the only difference that I can see is:
      >
      > $c->shutdown(2);
      > $c = undef;
      >
      > instead of
      >
      > $c->close;
      > undef $c;
      >
      > close should do this anyway as far as I understand. I can do:
      >
      > $c->shutdown(2);
      > $c->close;
      > undef $c;
      >
      > which should be safe on all platforms. Sean, is it what we need?
      > I use the same logic in TCP transport. Should I add shutdown(2) there
      > also? Thank you.
      >
      > Best wishes, Paul.
      >
      > --- Michael Percy <mpercy@...> wrote:
      > > Haha!
      > >
      > > Sean, you rock man! Thank you so much, this works great... I have a
      > > project-prototype "demo" for my boss' boss at 4:30 and I didn't
      > > want to
      > > screw it up :)
      > >
      > > How did you figure this out? I thought it might be an open socket
      > > but I
      > > didn't think it would simply be blocking on close()...
      > >
      > > Paul,
      > > If this is portable, can this find its way into the next release?
      > > Otherwise,
      > > we should get it into the Cookbook or POD or something... it is
      > > really
      > > annoying :)
      > >
      > > Thanks,
      > > Mike
      > >
      > > > -----Original Message-----
      > > > From: Meisner, Sean [mailto:Sean.Meisner@...]
      > > > Sent: Tuesday, July 31, 2001 1:06 PM
      > > > To: soaplite@yahoogroups.com
      > > > Subject: RE: [soaplite] Forking from a dispatched class
      > > >
      > > >
      > > > Michael,
      > > > This sounds a lot like a problem I had. To do exactly the kind
      > > > of thing you want to do with forks in my SOAP server, I had to
      > > > create my own version of SOAP::Transport::HTTP::Daemon, with
      > > > a modified
      > > > handle() method. Here's the code for that package:
      > > >
      > > > package KillSocketSOAPHTTPDaemon;
      > > >
      > > > use strict;
      > > > use vars qw(@ISA);
      > > > use SOAP::Transport::HTTP;
      > > >
      > > > @ISA = qw(SOAP::Transport::HTTP::Daemon);
      > > >
      > > > sub handle {
      > > > my $self = shift->new;
      > > > while (my $c = $self->accept) {
      > > > while (my $r = $c->get_request) {
      > > > $self->request($r);
      > > > $self->SOAP::Transport::HTTP::Server::handle;
      > > > $c->send_response($self->response)
      > > > }
      > > > $c->shutdown(2);
      > > > $c = undef;
      > > > }
      > > > }
      > > >
      > > > 1;
      > > >
      > > > Save this code in a file somewhere in your path, and in
      > > > the mainline of your SOAP server, say
      > > >
      > > > use KillSocketSOAPHTTPDaemon;
      > > >
      > > > my $daemon = KillSocketSOAPHTTPDaemon->new( .........
      > > >
      > > > INSTEAD of
      > > >
      > > > use SOAP::Transport::HTTP::Daemon;
      > > >
      > > > my $daemon = SOAP::Transport::HTTP::Daemon->new( .........
      > > >
      > > >
      > > > The problem is that when you fork under Solaris, your forked
      > > process
      > > > will contain a copy of the open socket in the HTTP::Daemon ($c in
      > > the
      > > > code above). You don't want that. I call shutdown() on that
      > > > socket here,
      > > > replacing close() in the original, so the socket is closed in
      > > > all child
      > > > processes and things should work as expected.
      > > >
      > > > Hope I explained that clearly enough!!
      > > >
      > > > Cheers,
      > > >
      > > > Sean
      > > >
      > > > > -----Original Message-----
      > > > > From: Michael Percy [mailto:mpercy@...]
      > > > > Sent: Tuesday, July 31, 2001 3:41 PM
      > > > > To: 'soaplite@yahoogroups.com'
      > > > > Subject: [soaplite] Forking from a dispatched class
      > > > >
      > > > >
      > > > > Hi,
      > > > > When inside a dispatched handler (using SOAP Daemon), I am
      > > > > unable to fork a
      > > > > new process to do work without it blocking forever. Even if
      > > > I localize
      > > > > $SIG{CHLD}, run POSIX::setsid(), close STDIN, STDOUT &
      > > > > STDERR, or fork()
      > > > > twice... the parent process will block until all children exit.
      > > > >
      > > > > What I really want to do is send a SOAP request to a handler
      > > > > that spawns off
      > > > > a child to do work, so the SOAP request can return a port
      > > > > number to the
      > > > > client to contact the spawned child. This behavior is located
      > > > > in a spawn()
      > > > > subroutine which refuses to return to the SOAP client (until
      > > > > all children
      > > > > are dead).
      > > > >
      > > > > Is this a common problem, or has no one heard of this kind of
      > > thing
      > > > > happening? I am running ActiveState Perl 5.6.0 on Solaris 8
      > > > > with SOAP::Lite
      > > > > 0.51.
      > > > >
      > > > > Thanks!
      > > > > Mike
      > > > >
      > > > > ------------------------ Yahoo! Groups Sponsor
      > > > > ---------------------~-->
      > > > > Small business owners...
      > > > > Tell us what you think!
      > > > > http://us.click.yahoo.com/vO1FAB/txzCAA/ySSFAA/W6uqlB/TM
      > > > > --------------------------------------------------------------
      > > > > -------~->
      > > > >
      > > > > To unsubscribe from this group, send an email to:
      > > > > soaplite-unsubscribe@yahoogroups.com
      > > > >
      > > > >
      > > > >
      > > > > Your use of Yahoo! Groups is subject to
      > > > http://docs.yahoo.com/info/terms/
      > > >
      > > >
      > > > ------------------------ Yahoo! Groups Sponsor
      > > > ---------------------~-->
      > > > Small business owners...
      > > > Tell us what you think!
      > > > http://us.click.yahoo.com/vO1FAB/txzCAA/ySSFAA/W6uqlB/TM
      > > > --------------------------------------------------------------
      > > > -------~->
      > > >
      > > > To unsubscribe from this group, send an email to:
      > > > soaplite-unsubscribe@yahoogroups.com
      > > >
      > > >
      > > >
      > > > Your use of Yahoo! Groups is subject to
      > > http://docs.yahoo.com/info/terms/
      > >
      > >
      > > ------------------------ Yahoo! Groups Sponsor
      > >
      > > To unsubscribe from this group, send an email to:
      > > soaplite-unsubscribe@yahoogroups.com
      > >
      > >
      > >
      > > Your use of Yahoo! Groups is subject to
      > > http://docs.yahoo.com/info/terms/
      > >
      > >
      >
      >
      > __________________________________________________
      > Do You Yahoo!?
      > Make international calls for as low as $.04/minute with
      > Yahoo! Messenger
      > http://phonecard.yahoo.com/
      >
      > ------------------------ Yahoo! Groups Sponsor
      > ---------------------~-->
      > Small business owners...
      > Tell us what you think!
      > http://us.click.yahoo.com/vO1FAB/txzCAA/ySSFAA/W6uqlB/TM
      > --------------------------------------------------------------
      > -------~->
      >
      > To unsubscribe from this group, send an email to:
      > soaplite-unsubscribe@yahoogroups.com
      >
      >
      >
      > Your use of Yahoo! Groups is subject to
      > http://docs.yahoo.com/info/terms/
      >
      >
    • Show all 12 messages in this topic