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

HTTP Timeouts

Expand Messages
  • Michael Percy
    Paul, Thank you very much for such a great SOAP library, SOAP-Lite is really fantastic. Just wanted to express that. I was wondering if you could help solve
    Message 1 of 11 , Apr 3, 2001
    • 0 Attachment
      Paul,
      Thank you very much for such a great SOAP library, SOAP-Lite is really
      fantastic. Just wanted to express that.

      I was wondering if you could help solve something that is bothering me a
      bit. I have found a workaround, but I don't really like it very much.

      My situation is that I am calling functions via SOAP that can take five or
      ten minutes to complete. With the default HTTP client under SOAP::Lite, the
      HTTP response timeout is set to 180 seconds. I would like to make the
      timeout 0, so that the client will wait indefinitely.

      There is a method timeout() of HTTP-UserAgent I have not been able to access
      via the SOAP object (or maybe I just don't know how). The only way to set
      the timeout is by doing this:

      my $soap = SOAP::Lite
      -> proxy($proxy)
      -> uri($uri);

      # Disable UserAgent timeouts
      $soap->{_transport}->{_proxy}->{timeout} = 0;

      Do you know what I could be doing wrong? I know this does not affect
      anything other than code maintainability because it works but I was hoping
      you knew of a more elegant solution. I am currently using SOAP-Lite 0.46.

      Thanks,
      Mike
    • Mathieu Longtin
      Is there a way to send multiple requests on the same http connection? Using SOAP::Lite of course. -Mathieu
      Message 2 of 11 , Apr 4, 2001
      • 0 Attachment
        Is there a way to send multiple requests on the same http connection? Using SOAP::Lite of course.
         
        -Mathieu
      • Paul Kulchenko
        Hi, Michael! Actually you have a couple of choices: you may pass transport dependent parameters right after endpoint address in proxy call: my $soap =
        Message 3 of 11 , Apr 4, 2001
        • 0 Attachment
          Hi, Michael!

          Actually you have a couple of choices:

          you may pass transport dependent parameters right after endpoint
          address in proxy call:

          my $soap = SOAP::Lite
          -> proxy($proxy, timeout => 10)
          -> uri($uri);

          you'll find examples with this syntax with cookie_jar and options.

          you may also change it anytime after that, using transport() method:

          $soap->transport->timeout(10);

          Any transport specific method (LWP::UserAgent in this case) you can
          call with both syntaxes. Hope it helps. Examples for both you may
          find in documentation and I set timeout in test suite to get answer
          quicker if other side is dead or unreachable.

          Best wishes, Paul.

          --- Michael Percy <mpercy@...> wrote:
          > Paul,
          > Thank you very much for such a great SOAP library, SOAP-Lite is
          > really
          > fantastic. Just wanted to express that.
          >
          > I was wondering if you could help solve something that is bothering
          > me a
          > bit. I have found a workaround, but I don't really like it very
          > much.
          >
          > My situation is that I am calling functions via SOAP that can take
          > five or
          > ten minutes to complete. With the default HTTP client under
          > SOAP::Lite, the
          > HTTP response timeout is set to 180 seconds. I would like to make
          > the
          > timeout 0, so that the client will wait indefinitely.
          >
          > There is a method timeout() of HTTP-UserAgent I have not been able
          > to access
          > via the SOAP object (or maybe I just don't know how). The only way
          > to set
          > the timeout is by doing this:
          >
          > my $soap = SOAP::Lite
          > -> proxy($proxy)
          > -> uri($uri);
          >
          > # Disable UserAgent timeouts
          > $soap->{_transport}->{_proxy}->{timeout} = 0;
          >
          > Do you know what I could be doing wrong? I know this does not
          > affect
          > anything other than code maintainability because it works but I was
          > hoping
          > you knew of a more elegant solution. I am currently using SOAP-Lite
          > 0.46.
          >
          > 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!?
          Get email at your own domain with Yahoo! Mail.
          http://personal.mail.yahoo.com/
        • Mathieu Longtin
          is there a way to build SOAP::LIte with no user intervention? I need that for an install script, and it calls for minimal user input... Thanks -Mathieu
          Message 4 of 11 , Apr 4, 2001
          • 0 Attachment
            is there a way to build SOAP::LIte with no user intervention?
             
            I need that for an install script, and it calls for minimal user input...
             
            Thanks
             
            -Mathieu
          • Philip Molter
            ... Well, considering that SOAP::Lite uses LWP::UserAgent for its transport, probably not. I may be wrong, but I don t think LWP::UserAgent supports HTTP
            Message 5 of 11 , Apr 4, 2001
            • 0 Attachment
              On Wed, Apr 04, 2001 at 11:04:53AM -0400, Mathieu Longtin wrote:
              : Is there a way to send multiple requests on the same http connection? Using
              : SOAP::Lite of course.

              Well, considering that SOAP::Lite uses LWP::UserAgent for its
              transport, probably not. I may be wrong, but I don't think
              LWP::UserAgent supports HTTP keep-alive (at least, that's been my
              experience with it). We wrote a little custom HTTP transport agent for
              an other XML-RPC app that we wrote in-house. It's worlds faster.

              * Philip Molter
              * DataFoundry.net
              * http://www.datafoundry.net/
              * philip@...
            • Paul Kulchenko
              Hi, Mathieu! ... If you redirect output somewhere (/dev/null or other file): perl Makefile.PL /dev/null it s smart enough to take default values and create
              Message 6 of 11 , Apr 4, 2001
              • 0 Attachment
                Hi, Mathieu!

                > is there a way to build SOAP::LIte with no user intervention?
                > I need that for an install script, and it calls for minimal user
                > input...
                If you redirect output somewhere (/dev/null or other file):

                perl Makefile.PL >/dev/null

                it's smart enough to take default values and create makefile with
                them. Then just run make, make test, make install, it doesn't require
                user intervention. It should help.

                Best wishes, Paul.

                --- Mathieu Longtin <damnfrenchy@...> wrote:
                > is there a way to build SOAP::LIte with no user intervention?
                >
                > I need that for an install script, and it calls for minimal user
                > input...
                >
                > Thanks
                >
                > -Mathieu
                >


                __________________________________________________
                Do You Yahoo!?
                Get email at your own domain with Yahoo! Mail.
                http://personal.mail.yahoo.com/
              • Paul Kulchenko
                Hi, Philip! ... I don t think so either. I ve added patch that makes it work with server that returns keep-alive connection (it died on timeout before), but
                Message 7 of 11 , Apr 4, 2001
                • 0 Attachment
                  Hi, Philip!

                  --- Philip Molter <philip@...> wrote:
                  > Well, considering that SOAP::Lite uses LWP::UserAgent for its
                  > transport, probably not. I may be wrong, but I don't think
                  > LWP::UserAgent supports HTTP keep-alive (at least, that's been
                  I don't think so either. I've added patch that makes it work with
                  server that returns keep-alive connection (it died on timeout
                  before), but looking in the code it still closes the connection
                  (though it may be changed). At the same time it's socket
                  manipulation, so probably it's something that can be fixed. It's not
                  my field, but given some advices I can try to do it.

                  > experience with it). We wrote a little custom HTTP transport agent
                  for
                  > an other XML-RPC app that we wrote in-house. It's worlds faster.
                  Is it in Perl? Is it something you want to share?
                  Speaking about XML-RPC, next version will include XMLRPC::Lite with
                  SOAP::Lite interface, but XMLRPC payload. It was tested with
                  userland's validator and it works just fine (for the first version).
                  It gives you access to all features of SOAP::Lite (authentication,
                  compression, SSL support, etc), access to all transports, and works
                  on client and server side. Will it be interesting?

                  Best wishes, Paul.


                  __________________________________________________
                  Do You Yahoo!?
                  Get email at your own domain with Yahoo! Mail.
                  http://personal.mail.yahoo.com/
                • Philip Molter
                  ... It is in Perl, but this company has a strict non-disclosure policy. It s really a very simple module, though. Basically, send the keep-alive, and don t
                  Message 8 of 11 , Apr 4, 2001
                  • 0 Attachment
                    On Wed, Apr 04, 2001 at 09:02:36AM -0700, Paul Kulchenko wrote:
                    : Is it in Perl? Is it something you want to share?

                    It is in Perl, but this company has a strict non-disclosure policy.
                    It's really a very simple module, though. Basically, send the
                    keep-alive, and don't close the socket until you get a request for a
                    new site. The thing is, it's written for a very special case for some
                    quick machine monitoring we're doing. It doesn't implement nearly the
                    number of features that LWP does (no SSL, very little configurability,
                    etc.).

                    : Speaking about XML-RPC, next version will include XMLRPC::Lite with
                    : SOAP::Lite interface, but XMLRPC payload. It was tested with
                    : userland's validator and it works just fine (for the first version).
                    : It gives you access to all features of SOAP::Lite (authentication,
                    : compression, SSL support, etc), access to all transports, and works
                    : on client and server side. Will it be interesting?

                    That's going to be very nice to have.

                    * Philip Molter
                    * DataFoundry.net
                    * http://www.datafoundry.net/
                    * philip@...
                  • Robert Barta
                    ... OH, YES! One issue I will have in the next future is: speed. Currently SOAP::Lite is using Expat, which is stable and working. But in the case of SOAP and
                    Message 9 of 11 , Apr 4, 2001
                    • 0 Attachment
                      > : Speaking about XML-RPC, next version will include XMLRPC::Lite with
                      > : SOAP::Lite interface, but XMLRPC payload. It was tested with
                      > : userland's validator and it works just fine (for the first version).
                      > : It gives you access to all features of SOAP::Lite (authentication,
                      > : compression, SSL support, etc), access to all transports, and works
                      > : on client and server side. Will it be interesting?

                      OH, YES!

                      One issue I will have in the next future is: speed.

                      Currently SOAP::Lite is using Expat, which is stable and working. But
                      in the case of SOAP and XML-RPC the payload format is not completely
                      arbitrary but has a rather predictable syntax.

                      I'm sure that a "SOAP-XML" or "XML-RPC-XML" parser can be considerable
                      faster than the generic Expat.

                      Any ideas (a) which parser to use and (b) how to tell SOAP::Lite to use
                      it?

                      \rho
                    • Paul Kulchenko
                      Hi, Robert! ... Actually you ll be able to specify any parser (SOAP::Lite has SOAP::Serializer which has SOAP::Parser which refers to XML::Parser). You may
                      Message 10 of 11 , Apr 4, 2001
                      • 0 Attachment
                        Hi, Robert!

                        > Any ideas (a) which parser to use and (b) how to tell SOAP::Lite to
                        > use it?
                        Actually you'll be able to specify any parser (SOAP::Lite has
                        SOAP::Serializer which has SOAP::Parser which refers to XML::Parser).
                        You may insert your parser in any plca of this chain and in fact next
                        version will be shipped with regexp-based XML parser that can be used
                        instead of XML::Parser (it'll be used automatically or you may
                        specify it explicitly).

                        But the main problem is not in parser's speed. Result of parsing is
                        represented as Perl data structures and that part affects
                        performance. Just try to specify Style = 'Tree' (similar to what I
                        have) for XML::Parser and you'll see the difference.

                        I was even thinking about do NOT parse the whole message, just
                        extract the information about method and parameters and represent
                        them as tied variable, so as soon as you need it, I'll use XPath or
                        something like that and will get you value, but I don't think that
                        it'll be really benefitial. The problem is that if you get request
                        with parameters a, b, and c that basically means that you'll need all
                        of them and there is no value in delaying parsing. I'm moving toward
                        internal infrastructure that will let you specify streamin
                        processing, but it won't work with MIME messages and with
                        XML::Parser::Lite (I need to have whole message before parsing it).

                        Any comments and ideas are greatly appreciated.

                        Best wishes, Paul.

                        --- Robert Barta <rho@...> wrote:
                        > > : Speaking about XML-RPC, next version will include XMLRPC::Lite
                        > with
                        > > : SOAP::Lite interface, but XMLRPC payload. It was tested with
                        > > : userland's validator and it works just fine (for the first
                        > version).
                        > > : It gives you access to all features of SOAP::Lite
                        > (authentication,
                        > > : compression, SSL support, etc), access to all transports, and
                        > works
                        > > : on client and server side. Will it be interesting?
                        >
                        > OH, YES!
                        >
                        > One issue I will have in the next future is: speed.
                        >
                        > Currently SOAP::Lite is using Expat, which is stable and working.
                        > But
                        > in the case of SOAP and XML-RPC the payload format is not
                        > completely
                        > arbitrary but has a rather predictable syntax.
                        >
                        > I'm sure that a "SOAP-XML" or "XML-RPC-XML" parser can be
                        > considerable
                        > faster than the generic Expat.
                        >
                        > Any ideas (a) which parser to use and (b) how to tell SOAP::Lite to
                        > use
                        > it?
                        >
                        > \rho
                        >
                        > ------------------------ 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!?
                        Get email at your own domain with Yahoo! Mail.
                        http://personal.mail.yahoo.com/
                      • Robert Barta
                        ... How is it done currently? Is it first parsed into some DOM/grove-like structure and then into the Perl data structure? Or is it done in one sweep? In the
                        Message 11 of 11 , Apr 6, 2001
                        • 0 Attachment
                          Paul Kulchenko wrote:
                          > > Any ideas (a) which parser to use and (b) how to tell SOAP::Lite to
                          > > use it?
                          > Actually you'll be able to specify any parser (SOAP::Lite has
                          > SOAP::Serializer which has SOAP::Parser which refers to XML::Parser).
                          > You may insert your parser in any plca of this chain and in fact next
                          > version will be shipped with regexp-based XML parser that can be used
                          > instead of XML::Parser (it'll be used automatically or you may
                          > specify it explicitly).

                          :-O. I'm certainly looking forward to that.

                          > But the main problem is not in parser's speed. Result of parsing is
                          > represented as Perl data structures and that part affects
                          > performance.

                          How is it done currently? Is it first parsed into some DOM/grove-like
                          structure and then into the Perl data structure? Or is it done in
                          one sweep?

                          In the early days of RPC programming (Sun-RPC) the developer had
                          to specify the interface between server and client in a language
                          independent way (people nowadays would create a WDSL).

                          Then a 'compiler' (rpcgen in that case) would create

                          - a client stub (faking a local subroutine, serializing, sending)
                          - a server stub (server infrastructure, dispatcher)
                          - and all serializing/deserializing routines

                          This means, that, if you had a C structure like

                          struct A {
                          int i;
                          char[30] s;
                          struct B b;
                          }

                          A serializing routine in C-source was created:

                          encode_A {
                          do something trivial with i;
                          do trivial with b;
                          &encode_B (b);
                          }

                          Similar for deserialization.

                          This means, that we could trade of flexibility (interpretation at
                          runtime)
                          with speed. Something I would be happy to do.

                          > I was even thinking about do NOT parse the whole message, just
                          > extract the information about method and parameters and represent
                          > them as tied variable, so as soon as you need it, I'll use XPath or
                          > something like that and will get you value, but I don't think that
                          > it'll be really benefitial. The problem is that if you get request
                          > with parameters a, b, and c that basically means that you'll need all
                          > of them and there is no value in delaying parsing.

                          Well, maybe but sometimes this could be useful. This concept is known as
                          'futures' or 'delayed/lazy evaluation'.

                          As an example of a server-side method:

                          sub do_important_stuff {
                          my ($a, $b) = @_;

                          # do validation of some parameters
                          unless ($a->id) {
                          die "inconsistent data, go away";
                          };

                          # only now the rest matters
                          ..... $b ....

                          }

                          I could even imagine that for SOAP (server-side AND client-side) this
                          could be almost transparent:

                          sub do_important_stuff_lazy {
                          my ($a, $b) = @_; # not real values, only XPath-like expressions
                          to the message

                          unless ( $a->id ) { # this is 'overloaded', resolves XPath, returns
                          value
                          ....
                          }
                          }

                          This works fine for objects where I can do overloading. For arrays,
                          hashes, ...
                          this does not work (as [], ->, {} cannot be overloaded in Perl).

                          \rho
                        Your message has been successfully submitted and would be delivered to recipients shortly.