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

SOAP::Lite, WSDL and execution loops/delays

Expand Messages
  • Scott Francis
    So I m using SOAP::Lite to build a Perl interface to a NetScaler load balancer (end goal is to have servers added and removed from a pool in an automated
    Message 1 of 3 , Jun 19, 2006
    • 0 Attachment
      So I'm using SOAP::Lite to build a Perl interface to a NetScaler load
      balancer (end goal is to have servers added and removed from a pool in
      an automated fashion). The interface is via WSDL[0], and my code[1]
      successfully connects (uses HTTP::Cookies for authentication),
      executes a command and parses the response.

      However ... (you knew that was coming :))

      I'm running into a strange delay during execution. It appears to
      happen when my SOAP object is instantiated (client-side), as opposed
      to being an HTTP transport delay or a server-side delay. The delay
      appears to be about the same regardless of command - approx. 70-80
      seconds on my Ubuntu desktop (similar results on an unloaded OpenBSD
      server and an OS X iBook). During the delay, CPU is pegged (although
      the system functions normally otherwise).

      Output with trace turned off:

      [sfrancis@basalt:~]$ time ./netscaler_soap.pl
      version string: "NetScaler NS6.0: Build 47.18, Date: Jul 25 2005, 12:54:43 "
      ./netscaler_soap.pl 76.02s user 0.47s system 89% cpu 1:25.30 total


      When I turned on
      SOAP::Lite->import(+trace => "all");
      and directed output to a temp file[2], I found that the code was doing
      a little over 560,000 apparently empty
      SOAP::Data::new()/SOAP::Data::DESTROY() loops during the instantiation
      of the SOAP object. I have run my code past a few other pairs of eyes,
      and haven't received any gotchas so far; it appears to be fairly
      standard. The advice I've received thus far is that WSDL support in
      Perl (and SOAP::Lite in particular) is somewhat sketchy, but that's
      about as far as anybody's gotten. I'm hoping that somebody with more
      knowledge of the SOAP::Lite internals (hi Byrne!) can show me what I'm
      doing wrong (if anything), and how to patch my code to avoid this
      execution delay.

      (The code is a patch to a larger Perl script that is itself part of a
      CGI that is a bandaid to some broken behavior of code on IIS servers
      that must be reset every so often or they die. A 70+ second delay per
      machine is probably going to be untenable, and I haven't had any luck
      getting any of the actual developers to take a look at fixing this
      problem in .NET (which would make sense, since the bandaid itself is a
      set of ASP scripts running on IIS that reset IIS servers) - nobody
      wants to touch the thing, so it ends up in the UNIX admins' laps. :))

      This is SOAP::Lite v0.67, by the way; primary test platform is
      perl-5.8.7 on Ubuntu (Dapper), kernel-2.6.15.

      thanks in advance for giving this the once-over!
      Comments/errata/patches welcome.

      cheers,
      --
      darkuncle@{gmail.com,darkuncle.net} || 0x5537F527
      encrypted email to the latter address please
      http://darkuncle.net/pubkey.asc for public key

      [0] http://darkuncle.net/perl/NSConfig.wsdl # the NetScaler WSDL config file
      [1] http://darkuncle.net/perl/netscaler_soap.pl # the code
      [2] http://darkuncle.net/perl/getnsversion.out.gz # gzipped output;
      trace => "all"
    • Scott Francis
      ... Following up with code inline, in hopes of soliciting some comments: #!/usr/bin/perl -w # # use Perl and NetScaler s SOAP API service - primarily useful #
      Message 2 of 3 , Jun 23, 2006
      • 0 Attachment
        On 6/19/06, Scott Francis <darkuncle@...> wrote:
        > So I'm using SOAP::Lite to build a Perl interface to a NetScaler load
        > balancer (end goal is to have servers added and removed from a pool in
        > an automated fashion). The interface is via WSDL[0], and my code[1]
        > successfully connects (uses HTTP::Cookies for authentication),
        > executes a command and parses the response.

        Following up with code inline, in hopes of soliciting some comments:

        #!/usr/bin/perl -w

        #
        # use Perl and NetScaler's SOAP API service - primarily useful
        # for scripted activity, since NS already has a java-based GUI and runs sshd
        #

        use strict;
        use SOAP::Lite;
        use Data::Dumper;

        # uncomment the following to dump complete SOAP::Lite output
        # this is EXCEEDINGLY verbose - you have been warned!
        #SOAP::Lite->import(+trace => [ "all", "-objects" ]);

        # NetScaler SOAP API uses cookie-based authentication
        use HTTP::Cookies;

        # non-HTTP debugging - if enabled, debug("foo") prints "foo\n" to stderr
        # set to 1 to enable, 0 to disable
        use constant DEBUG => 1 ;
        sub debug { print STDERR "@_\n" if DEBUG; }

        # take CLI argument for operation, or default to getnsversion()
        my $operation = shift @ARGV || "getnsversion";
        my @arguments = @ARGV;

        debug("operation: $operation");
        debug("arguments: @arguments");

        # login credentials
        my $username = 'user';
        my $password = 'pass';

        debug("username: $username");
        debug("password: $password");

        # location of WSDL file and SOAP proxy
        my $ns_wsdl = 'file:./NSConfig.wsdl';
        my $ns_proxy = 'http://10.10.10.254/soap/';

        debug("ns_wsdl: $ns_wsdl");
        debug("ns_proxy: $ns_proxy");

        # instantiate SOAP object - this is where our 563K create/destroy loop begins
        ####
        # BEGIN EXECUTION DELAY
        ####
        my $soapobj = SOAP::Lite
        ->service("$ns_wsdl")
        ->proxy("$ns_proxy",
        cookie_jar => HTTP::Cookies->new(ignore_discard => 1),
        timeout => 5)
        ;
        ####
        # END EXECUTION DELAY
        ####

        # print perl object we'll be sending to the proxy
        DEBUG && print "dumping request - \$soapobj perl object:\n", Dumper($soapobj);

        # login
        my $login = $soapobj->login("$username", "$password") or die "login
        failure: $@\n";

        # use SOAP object to create $soapres object that actually performs our
        $operation
        my $soapres = $soapobj->$operation(@arguments) or die "$operation
        failure: $@\n";

        # Data::Dumper++ - we can see the output that's returned as Perl sees it!
        DEBUG && print "dumping response - \$soapres perl object:\n", Dumper($soapres);

        # the name and type of object returned varies with each $operation
        # our code is not yet smart enough to automagically PTRT (print the right thing)

        if ($operation eq "getnsversion") {
        # getnsversion()->version returns scalar
        print "version string: ", $soapres->{List}->[0]->{version}, "\n";
        } elsif ($operation eq "getlbvserver") {
        # getlbvserver()->serviceName returns array
        local $" = "\n ";
        print "getlbvserver list:\n @{$soapres->{List}->[0]->{serviceName}}\n";
        }

        DEBUG && print "return code: ", $soapres->{rc}, "\n";
        DEBUG && print "message: ", $soapres->{message}, "\n";

        unless ($soapres->{rc} == 0) {
        print "an error occurred: ", $soapres->{message}, "\n";
        }


        thanks for any comments, folks.
        --
        darkuncle@{gmail.com,darkuncle.net} || 0x5537F527
        encrypted email to the latter address please
        http://darkuncle.net/pubkey.asc for public key
      • Christopher Heschong
        ... ... Just as an FYI, I have reproduced this myself. Although I don t have any suggestions to help, I thought it might help to note that the problem seems
        Message 3 of 3 , Jun 27, 2006
        • 0 Attachment
          --- In soaplite@yahoogroups.com, "Scott Francis" <darkuncle@...> wrote:

          ...

          > When I turned on
          > SOAP::Lite->import(+trace => "all");
          > and directed output to a temp file[2], I found that the code was doing
          > a little over 560,000 apparently empty
          > SOAP::Data::new()/SOAP::Data::DESTROY() loops during the instantiation
          > of the SOAP object.

          ...


          Just as an FYI, I have reproduced this myself. Although I don't have any suggestions to
          help, I thought it might help to note that the problem seems to lie within generating the
          definitions from the service :

          use SOAP::Lite; my $soapobj = SOAP::Lite->service( "file:./NSConfig.wsdl" ); # Hangs


          Anyone have any ideas?
        Your message has been successfully submitted and would be delivered to recipients shortly.