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

Forking from a dispatched class

Expand Messages
  • Michael Percy
    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
    Message 1 of 12 , Jul 31, 2001
    • 0 Attachment
      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
    • Meisner, Sean
      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
      Message 2 of 12 , Jul 31, 2001
      • 0 Attachment
        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/
      • Michael Percy
        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
        Message 3 of 12 , Jul 31, 2001
        • 0 Attachment
          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/
        • Meisner, Sean
          ... Happy to help :o) ... Ummm, can t recall the exact train of thought that led me to that solution, but I think I burned a good 2 or 3 work days of reading
          Message 4 of 12 , Jul 31, 2001
          • 0 Attachment
            > -----Original Message-----
            > From: Michael Percy [mailto:mpercy@...]
            > Sent: Tuesday, July 31, 2001 4:30 PM
            > To: 'soaplite@yahoogroups.com'
            > Subject: RE: [soaplite] Forking from a dispatched class
            >
            >
            > 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 :)
            >

            Happy to help :o)

            > 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()...
            >

            Ummm, can't recall the exact train of thought that led me to that
            solution, but I think I burned a good 2 or 3 work days of reading
            man pages on fork and socket calls and looking at the SOAP::Lite
            and HTTP::Daemon code to figure out what was going on.

            > 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 :)
            >

            I *think* that Solaris will be the only OS that would benefit from
            this patch, but I'm not sure on that. I seem to remember being told
            that other systems handle forking with open sockets in a cleaner fashion.

            Cheers,

            Sean
          • Paul Kulchenko
            Hi, Michael! ... 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
            Message 5 of 12 , Jul 31, 2001
            • 0 Attachment
              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/
            • Michael Percy
              ... That sounds about right... I was really confused and about to embark on that journey! ... I don t know if this is the case or not, but this issue
              Message 6 of 12 , Jul 31, 2001
              • 0 Attachment
                > -----Original Message-----
                > From: Meisner, Sean [mailto:Sean.Meisner@...]
                > Sent: Tuesday, July 31, 2001 2:13 PM
                ...
                > Ummm, can't recall the exact train of thought that led me to that
                > solution, but I think I burned a good 2 or 3 work days of reading
                > man pages on fork and socket calls and looking at the SOAP::Lite
                > and HTTP::Daemon code to figure out what was going on.

                That sounds about right... I was really confused and about to embark on that
                journey!

                > I *think* that Solaris will be the only OS that would benefit from
                > this patch, but I'm not sure on that. I seem to remember being told
                > that other systems handle forking with open sockets in a
                > cleaner fashion.

                I don't know if this is the case or not, but this issue definitely warrants
                at least a relnote! Checking on the linux manpage for fork(2), it states:

                -- from Linux.com: http://www.linux.com/develop/man/2/fork/
                Linux> fork creates a child process that differs from the parent
                Linux> process only in its PID and PPID, and in the fact that
                Linux> resource utilizations are set to 0. File locks and pending
                Linux> signals are not inherited.
                Linux> ...
                Linux> The fork call conforms to SVr4, SVID, POSIX, X/OPEN, BSD 4.3.

                While on the manpage for Solaris, it says:

                -- for Solaris:
                http://www.hgmp.mrc.ac.uk/cgi-bin/man.cgi?section=2&topic=fork
                Solaris> The fork() and fork1() functions create a new process. The
                Solaris> new process (child process) is an exact copy of the calling
                Solaris> process (parent process). The child process inherits the
                Solaris> following attributes from the parent process:
                Solaris> ...
                Solaris> open file descriptors
                Solaris> ...

                Obviously Solaris does this explicitly, while on Linux is not quite
                documented but seems likely. Since file locks != file descriptors, and I
                don't think resource utilizations would include FD's, I am assuming without
                trying it that Linux follows the same behavior as Solaris on this one.

                Can anyone developing on Linux verify this behavior?

                Thanks,
                Mike
              • Michael Percy
                Paul, I believe close() only closes the file descriptor in the local process, while shutdown(2) closes the socket (with (2), for read+write) across all
                Message 7 of 12 , Jul 31, 2001
                • 0 Attachment
                  Paul,
                  I believe close() only closes the file descriptor in the local process,
                  while shutdown(2) closes the socket (with (2), for read+write) across all
                  processes.

                  Not sure if you would need to use both, afaik it would be unnecessary.

                  See perlfunc/shutdown for details:
                  http://www.perldoc.com/perl5.6/pod/func/shutdown.html

                  Mike

                  > -----Original Message-----
                  > From: Paul Kulchenko [mailto:paulclinger@...]
                  > Sent: Tuesday, July 31, 2001 3: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/
                • Meisner, Sean
                  Hi Paul, Calling close() after shutdown() is redundant, shutdown() has closed the socket already. The difference between close() and shutdown() is: close()
                  Message 8 of 12 , Jul 31, 2001
                  • 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/
                    >
                    >
                  • Rik
                    Mike/Paul/Sean, Just to confirm, I just had the same problem on Linux (2.2 kernel/RH6.2). My client app hangs until the child process gets killed. When I
                    Message 9 of 12 , Oct 22, 2001
                    • 0 Attachment
                      Mike/Paul/Sean,

                      Just to confirm, I just had the same problem on Linux (2.2
                      kernel/RH6.2).

                      My client app hangs until the child process gets killed. When I
                      implemented the KillSocketSOAPHTTPDaemon module everything works
                      great.

                      If you look in the Perl Cookbook, Ch 17.9, it tells you the same as we
                      experienced.



                      I had hoped there would be a neater way to access the socket guts of
                      the HTTP::Daemon that SOAP::Lite used for the handler. Rather than
                      having to re-write a whole replacement ::Daemon myself. Perhaps you
                      could add a method ...->shutdown(1|2|3).

                      Thanks for saving me the the time to do it anyway!

                      Regards,
                      Rik.



                      --- In soaplite@y..., Michael Percy <mpercy@p...> wrote:
                      > > -----Original Message-----
                      > > From: Meisner, Sean [mailto:Sean.Meisner@V...]
                      > > Sent: Tuesday, July 31, 2001 2:13 PM
                      > ...
                      > > Ummm, can't recall the exact train of thought that led me to that
                      > > solution, but I think I burned a good 2 or 3 work days of reading
                      > > man pages on fork and socket calls and looking at the SOAP::Lite
                      > > and HTTP::Daemon code to figure out what was going on.
                      >
                      > That sounds about right... I was really confused and about to embark
                      on that
                      > journey!
                      >
                      > > I *think* that Solaris will be the only OS that would benefit
                      from
                      > > this patch, but I'm not sure on that. I seem to remember being
                      told
                      > > that other systems handle forking with open sockets in a
                      > > cleaner fashion.
                      >
                      > I don't know if this is the case or not, but this issue definitely
                      warrants
                      > at least a relnote! Checking on the linux manpage for fork(2), it
                      states:
                      >
                      > -- from Linux.com: http://www.linux.com/develop/man/2/fork/
                      > Linux> fork creates a child process that differs from the parent
                      > Linux> process only in its PID and PPID, and in the fact that
                      > Linux> resource utilizations are set to 0. File locks and pending
                      > Linux> signals are not inherited.
                      > Linux> ...
                      > Linux> The fork call conforms to SVr4, SVID, POSIX, X/OPEN, BSD 4.3.
                      >
                      > While on the manpage for Solaris, it says:
                      >
                      > -- for Solaris:
                      > http://www.hgmp.mrc.ac.uk/cgi-bin/man.cgi?section=2&topic=fork
                      > Solaris> The fork() and fork1() functions create a new process. The
                      > Solaris> new process (child process) is an exact copy of the calling
                      > Solaris> process (parent process). The child process inherits the
                      > Solaris> following attributes from the parent process:
                      > Solaris> ...
                      > Solaris> open file descriptors
                      > Solaris> ...
                      >
                      > Obviously Solaris does this explicitly, while on Linux is not quite
                      > documented but seems likely. Since file locks != file descriptors,
                      and I
                      > don't think resource utilizations would include FD's, I am assuming
                      without
                      > trying it that Linux follows the same behavior as Solaris on this
                      one.
                      >
                      > Can anyone developing on Linux verify this behavior?
                      >
                      > Thanks,
                      > Mike
                    • Paul Kulchenko
                      Hi, Rik! ... It s in the code already. I commited this change as suggested by Sean Meisner. Will be available with the next version. Best wishes, Paul. ...
                      Message 10 of 12 , Oct 22, 2001
                      • 0 Attachment
                        Hi, Rik!

                        > the HTTP::Daemon that SOAP::Lite used for the handler. Rather than
                        > having to re-write a whole replacement ::Daemon myself. Perhaps
                        > you could add a method ...->shutdown(1|2|3).
                        It's in the code already. I commited this change as suggested by Sean
                        Meisner. Will be available with the next version.

                        Best wishes, Paul.

                        --- Rik <ukdiveboy@...> wrote:
                        > Mike/Paul/Sean,
                        >
                        > Just to confirm, I just had the same problem on Linux (2.2
                        > kernel/RH6.2).
                        >
                        > My client app hangs until the child process gets killed. When I
                        > implemented the KillSocketSOAPHTTPDaemon module everything works
                        > great.
                        >
                        > If you look in the Perl Cookbook, Ch 17.9, it tells you the same as
                        > we
                        > experienced.
                        >
                        >
                        >
                        > I had hoped there would be a neater way to access the socket guts
                        > of
                        > the HTTP::Daemon that SOAP::Lite used for the handler. Rather than
                        > having to re-write a whole replacement ::Daemon myself. Perhaps
                        > you
                        > could add a method ...->shutdown(1|2|3).
                        >
                        > Thanks for saving me the the time to do it anyway!
                        >
                        > Regards,
                        > Rik.
                        >
                        >
                        >
                        > --- In soaplite@y..., Michael Percy <mpercy@p...> wrote:
                        > > > -----Original Message-----
                        > > > From: Meisner, Sean [mailto:Sean.Meisner@V...]
                        > > > Sent: Tuesday, July 31, 2001 2:13 PM
                        > > ...
                        > > > Ummm, can't recall the exact train of thought that led me to
                        > that
                        > > > solution, but I think I burned a good 2 or 3 work days of
                        > reading
                        > > > man pages on fork and socket calls and looking at the
                        > SOAP::Lite
                        > > > and HTTP::Daemon code to figure out what was going on.
                        > >
                        > > That sounds about right... I was really confused and about to
                        > embark
                        > on that
                        > > journey!
                        > >
                        > > > I *think* that Solaris will be the only OS that would benefit
                        > from
                        > > > this patch, but I'm not sure on that. I seem to remember being
                        > told
                        > > > that other systems handle forking with open sockets in a
                        > > > cleaner fashion.
                        > >
                        > > I don't know if this is the case or not, but this issue
                        > definitely
                        > warrants
                        > > at least a relnote! Checking on the linux manpage for fork(2), it
                        > states:
                        > >
                        > > -- from Linux.com: http://www.linux.com/develop/man/2/fork/
                        > > Linux> fork creates a child process that differs from the parent
                        > > Linux> process only in its PID and PPID, and in the fact that
                        > > Linux> resource utilizations are set to 0. File locks and pending
                        > > Linux> signals are not inherited.
                        > > Linux> ...
                        > > Linux> The fork call conforms to SVr4, SVID, POSIX, X/OPEN, BSD
                        > 4.3.
                        > >
                        > > While on the manpage for Solaris, it says:
                        > >
                        > > -- for Solaris:
                        > > http://www.hgmp.mrc.ac.uk/cgi-bin/man.cgi?section=2&topic=fork
                        > > Solaris> The fork() and fork1() functions create a new process.
                        > The
                        > > Solaris> new process (child process) is an exact copy of the
                        > calling
                        > > Solaris> process (parent process). The child process inherits the
                        > > Solaris> following attributes from the parent process:
                        > > Solaris> ...
                        > > Solaris> open file descriptors
                        > > Solaris> ...
                        > >
                        > > Obviously Solaris does this explicitly, while on Linux is not
                        > quite
                        > > documented but seems likely. Since file locks != file
                        > descriptors,
                        > and I
                        > > don't think resource utilizations would include FD's, I am
                        > assuming
                        > without
                        > > trying it that Linux follows the same behavior as Solaris on this
                        > one.
                        > >
                        > > Can anyone developing on Linux verify this behavior?
                        > >
                        > > Thanks,
                        > > Mike
                        >
                        >
                        > ------------------------ 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 a great connection at Yahoo! Personals.
                        http://personals.yahoo.com
                      • francis_reader@yahoo.co.uk
                        How do you force the same behaviour when using mod_soap and Apache?
                        Message 11 of 12 , Nov 17, 2001
                        • 0 Attachment
                          How do you force the same behaviour when using mod_soap and Apache?
                        • Sean.Meisner@VerizonWireless.com
                          Hi, Having not used mod_soap, I may stand to be corrected on this. However, I would suspect that if forking is not working properly under Apache, then a fix
                          Message 12 of 12 , Nov 19, 2001
                          • 0 Attachment
                            Hi,

                            Having not used mod_soap, I may stand to be corrected on this.
                            However, I would suspect that if forking is not working properly
                            under Apache, then a fix would have to be put into the Apache source
                            code. This is not really a SOAP specific issue, the problem comes
                            from the transport layer. Have you tried forking under mod_soap,
                            and had this problem?

                            Cheers,

                            Sean

                            > -----Original Message-----
                            > From: francis_reader@... [mailto:francis_reader@...]
                            > Sent: Saturday, November 17, 2001 9:44 AM
                            > To: soaplite@yahoogroups.com
                            > Subject: [soaplite] Re: Forking from a dispatched class
                            >
                            >
                            > How do you force the same behaviour when using mod_soap and Apache?
                            >
                            >
                            > ------------------------ Yahoo! Groups Sponsor
                            > ---------------------~-->
                            > Universal Inkjet Refill Kit $29.95
                            > Refill any ink cartridge for less!
                            > Includes black and color ink.
                            > http://us.click.yahoo.com/Vv.L9D/MkNDAA/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/
                            >
                            >
                          Your message has been successfully submitted and would be delivered to recipients shortly.