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

Re: [soaplite] client daemon increasing memory

Expand Messages
  • Duncan Cameron
    ... Hi Alex I was puzzled as to why you had an eval {} around the creation of the SOAP::Lite object, then noticed that you have a namespace() call. This is
    Message 1 of 5 , Nov 10, 2004
    • 0 Attachment
      At 2004-11-10, 01:17:09 zperlcoder <zperlcoder@...> wrote:

      >I have a daemon monitoring a directory and sending files using
      >SOAP::Lite to a .NET SOAP service. Everything seemed ok until I
      >looked at the memory...my daemon kept on growing and I believe I
      >narrowed it down to the SOAP::Lite portion of the code (not claiming
      >to have found the culprit...). The following snippet reproduces the
      >behaviour:
      >
      >while(1){
      > my $soap;
      > unless( eval { $soap = SOAP::Lite
      > -> proxy("http://ipaddress/blabla.asmx")
      > -> uri("http://blabla/")
      > -> namespace("blabla")
      > -> on_action(sub{join '', @_});
      > }
      > ){
      > print "ERROR: $@\n";
      > }else{
      > my $response = $soap->Method() };
      > etc...
      > }
      > sleep(5);
      >}
      >If the client can't connect to the server (HTTP return code 5xx or
      >4xx) which is caught by the eval statement and continues to run in
      >its while loop, the memory size keeps on growing...is that the
      >expected behaviour? If it is, which changes do I need to make to
      >keep a constant memory footprint? (version .60a)
      >
      >Thanks in advance for your help!
      >
      Hi Alex

      I was puzzled as to why you had an eval {} around the creation of the
      SOAP::Lite object, then noticed that you have a namespace() call. This
      is incorrect, there is no such method for a S::L object, so it will be
      treated as a remote method to be called.

      To catch the errors the eval needs to be around the call to the remote
      method

      use strict;
      use SOAP::Lite;

      while(1){
      my $soap;
      $soap = SOAP::Lite
      -> proxy("http://ipaddress/blabla.asmx")
      -> uri("http://blabla/")
      -> on_action(sub{join '', @_})
      ;
      eval {
      my $response = $soap->Method() ;
      # do something with the response
      };
      print "ERROR: $@\n" if $@;
      sleep(5);
      }

      Try this and see whether the memory usage improves.

      Duncan
    • zperlcoder
      Duncan, thanks for your quick response. I removed the namespace call and put the eval statement around the method call (the way it should have been...) but my
      Message 2 of 5 , Nov 10, 2004
      • 0 Attachment
        Duncan,
         
        thanks for your quick response.  I removed the namespace call and put the eval statement around the method call (the way it should have been...) but my mem requirements keep increasing.  It seems that the $soap object should go out of scope and destroy itself....even putting a block {} around the entire soap call makes no difference...
         
        Let me know if anyone has any suggestions....
         
        Thanks again,
         
        Alex

        Duncan Cameron <duncan_cameron2002@...> wrote:
        At 2004-11-10, 01:17:09 zperlcoder wrote:

        >I have a daemon monitoring a directory and sending files using
        >SOAP::Lite to a .NET SOAP service. Everything seemed ok until I
        >looked at the memory...my daemon kept on growing and I believe I
        >narrowed it down to the SOAP::Lite portion of the code (not claiming
        >to have found the culprit...). The following snippet reproduces the
        >behaviour:
        >
        >while(1){
        > my $soap;
        > unless( eval { $soap = SOAP::Lite
        > -> proxy("http://ipaddress/blabla.asmx")
        > -> uri("http://blabla/")
        > -> namespace("blabla")
        > -> on_action(sub{join '', @_});
        > }
        > ){
        > print "ERROR: $@\n";
        > }else{
        > my $response = $soap->Method() };
        > etc...
        > }
        > sleep(5);
        >}
        >If the client can't connect to the server (HTTP return code 5xx or
        >4xx) which is caught by the eval statement and continues to run in
        >its while loop, the memory size keeps on growing...is that the
        >expected behaviour? If it is, which changes do I need to make to
        >keep a constant memory footprint? (version .60a)
        >
        >Thanks in advance for your help!
        >
        Hi Alex

        I was puzzled as to why you had an eval {} around the creation of the
        SOAP::Lite object, then noticed that you have a namespace() call. This
        is incorrect, there is no such method for a S::L object, so it will be
        treated as a remote method to be called.

        To catch the errors the eval needs to be around the call to the remote
        method

        use strict;
        use SOAP::Lite;

        while(1){
        my $soap;
        $soap = SOAP::Lite
        -> proxy("http://ipaddress/blabla.asmx")
        -> uri("http://blabla/")
        -> on_action(sub{join '', @_})
        ;
        eval {
        my $response = $soap->Method() ;
        # do something with the response
        };
        print "ERROR: $@\n" if $@;
        sleep(5);
        }

        Try this and see whether the memory usage improves.

        Duncan



        Do you Yahoo!?
        Check out the new Yahoo! Front Page. www.yahoo.com

      • zperlcoder
        Duncan, I used Devel::Leak::Object to check whether the $soap object was destroyed at the end of the run....here is the code I used: my $i = 0; while($i
        Message 3 of 5 , Nov 10, 2004
        • 0 Attachment
          Duncan,
           
          I used Devel::Leak::Object to check whether the $soap object was destroyed at the end of the run....here is the code I used:
           
            my $i = 0;
            while($i < 2){
              {
                my $LocationCode = SOAP::Data->name('LocationCode')
                                                                 ->type('string')
                                                                 ->value("location_code")
                                                                 ->uri("http://blabla/");
                my $soap = new SOAP::Lite;
                Devel::Leak::Object::track($soap);

                $soap->proxy("http://blabla/blabla.asmx")
                     -> uri("http://blabla/")
                     -> on_action(sub{join '', @_});
           
                my $response = eval { $soap->MachineList($LocationCode) };
                if($@){
                  print "ERROR: $@\n";
                } 
                if($response->fault){
                  print "ERROR: " . $response->faultstring ."\n";
                }else{
                  print "Success\n";
                }
              }
              $i++;
            }
           
           the result is:
          ---------------------------------------------------------------------------------------------
          Status of all classes:
          SOAP::Lite                               2
           
          so turning on the SOAP::Lite +trace shows me that in my while loop I keep on creating new SOAP::Lite objects and none of them are destroyed until the loop ends when the code exits.
           
          Is there an explicit destroy or exit method that I could call to force the object to disappear?
           
          Alex

          Duncan Cameron <duncan_cameron2002@...> wrote:
          At 2004-11-10, 01:17:09 zperlcoder wrote:

          >I have a daemon monitoring a directory and sending files using
          >SOAP::Lite to a .NET SOAP service. Everything seemed ok until I
          >looked at the memory...my daemon kept on growing and I believe I
          >narrowed it down to the SOAP::Lite portion of the code (not claiming
          >to have found the culprit...). The following snippet reproduces the
          >behaviour:
          >
          >while(1){
          > my $soap;
          > unless( eval { $soap = SOAP::Lite
          > -> proxy("http://ipaddress/blabla.asmx")
          > -> uri("http://blabla/")
          > -> namespace("blabla")
          > -> on_action(sub{join '', @_});
          > }
          > ){
          > print "ERROR: $@\n";
          > }else{
          > my $response = $soap->Method() };
          > etc...
          > }
          > sleep(5);
          >}
          >If the client can't connect to the server (HTTP return code 5xx or
          >4xx) which is caught by the eval statement and continues to run in
          >its while loop, the memory size keeps on growing...is that the
          >expected behaviour? If it is, which changes do I need to make to
          >keep a constant memory footprint? (version .60a)
          >
          >Thanks in advance for your help!
          >
          Hi Alex

          I was puzzled as to why you had an eval {} around the creation of the
          SOAP::Lite object, then noticed that you have a namespace() call. This
          is incorrect, there is no such method for a S::L object, so it will be
          treated as a remote method to be called.

          To catch the errors the eval needs to be around the call to the remote
          method

          use strict;
          use SOAP::Lite;

          while(1){
          my $soap;
          $soap = SOAP::Lite
          -> proxy("http://ipaddress/blabla.asmx")
          -> uri("http://blabla/")
          -> on_action(sub{join '', @_})
          ;
          eval {
          my $response = $soap->Method() ;
          # do something with the response
          };
          print "ERROR: $@\n" if $@;
          sleep(5);
          }

          Try this and see whether the memory usage improves.

          Duncan



          Do you Yahoo!?
          Check out the new Yahoo! Front Page. www.yahoo.com

        • Duncan Cameron
          ... Sorry, that is getting beyond my knowledge. As a workaround can you look at re-using the S::L object each time, rather than creating a new one? I would
          Message 4 of 5 , Nov 10, 2004
          • 0 Attachment
            On 2004-11-10 at 22:17:27 zperlcoder wrote:

            >Duncan,
            >
            >I used Devel::Leak::Object to check whether the $soap object was
            >destroyed at the end of the run....here is the code I used:
            >
            > my $i = 0;
            > while($i < 2){
            > {
            > my $LocationCode = SOAP::Data->name('LocationCode')
            > ->type('string')
            > -
            >>value("location_code")
            > -
            >>uri("http://blabla/");
            > my $soap = new SOAP::Lite;
            > Devel::Leak::Object::track($soap);
            >
            > $soap->proxy("http://blabla/blabla.asmx")
            > -> uri("http://blabla/")
            > -> on_action(sub{join '', @_});
            >
            > my $response = eval { $soap->MachineList($LocationCode) };
            > if($@){
            > print "ERROR: $@\n";
            > }
            > if($response->fault){
            > print "ERROR: " . $response->faultstring ."\n";
            > }else{
            > print "Success\n";
            > }
            > }
            > $i++;
            > }
            >
            > the result is:
            >-----------------------------------------------------------------------
            >----------------------
            >Status of all classes:
            >SOAP::Lite 2
            >
            >so turning on the SOAP::Lite +trace shows me that in my while loop I
            >keep on creating new SOAP::Lite objects and none of them are destroyed
            >until the loop ends when the code exits.
            >
            >Is there an explicit destroy or exit method that I could call to force
            >the object to disappear?

            Sorry, that is getting beyond my knowledge. As a workaround can you
            look at re-using the S::L object each time, rather than creating a new
            one? I would guess that the object is reusable by calling the proxy()
            and uri() methods again.

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