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

"Bad file descriptor" on Windows

Expand Messages
  • Johan Lindstrom
    I have a problem with a SOAP::Lite client making HTTP calls to a SOAP server. At certain points in time, it stops working. Calls to remote methods die with
    Message 1 of 2 , Jul 28 12:09 PM
    • 0 Attachment
      I have a problem with a SOAP::Lite client making HTTP calls to a SOAP server.

      At certain points in time, it stops working. Calls to "remote methods" die
      with

      Can't connect to my.host.name:80 (Bad file descriptor)

      And that keeps happening until the program is restarted, which makes the
      error message go away. Then it continues to perform around 270 (or more)
      calls and then it breaks again. The number of calls each time are pretty
      much the same when it stops working.

      I used to re-use the SOAP object[1], but stopped doing that. That doesn't
      help, and my current theory is that something doesn't get destroyed
      properly so I'm trying to cache it more aggressively instead. ... Nope,
      doesn't really help.

      I have run this script on Solaris for years in production with no problem,
      and in my Windows development environment during development. I have not
      been able to figure out any other patterns when this happens.

      Searching the Net didn't give me anything useful so I hope someone have
      encountered this thing before.

      Is this a known error message? Is it a known, fixed bug (see below)?

      If not, what could it indicate? Where could I start looking in the
      SOAP::Lite source? Something to do with sockets?

      Is there a fixed number of file descriptors or something I could configure?


      Environment:
      The SOAP::Lite client runs on w2k as a PerlApp application. It uses
      SOAP::Lite 0.51 (I'd like to use a more recent version, but the program
      calls a home-grown, non-compliant "SOAP server" that doesn't play well with
      later versions for some reason). The program is designed to exit and be
      restarted by a shell script after n minutes, to fully release all resources.

      Perl -v
      This is perl, v5.6.1 built for MSWin32-x86-multi-thread
      Binary build 632 provided by ActiveState

      PerlApp version: 2.0 <- old, but it works

      Anything else?


      /J

      [1] This is what I mean by "SOAP object":

      SOAP::Lite
      ->uri("http://$host/soap/Publish")
      ->encoding('iso-8859-1')
      ->proxy("http://$host/soap/publish.asp")


      /J
      -------- ------ ---- --- -- -- -- - - - - -
      Johan Lindström Sourcerer @ Boss Casinos johanl@...

      Latest bookmark: "Clio -- A Schema Mapping Management Tool"
      http://www.cs.toronto.edu/db/clio/
      dmoz (1 of 3): /Computers/Data_Formats/Markup_Languages/XML/ 12
    • Johan Lindstrom
      ... This all turned out to be the fault of PerlApp. It s an old version (v2.0, current version is 4 or 5), and somehow the packaged code didn t work the same
      Message 2 of 2 , Jul 30 12:46 PM
      • 0 Attachment
        I wrote:
        >I have a problem with a SOAP::Lite client making HTTP calls to a SOAP server.
        >
        >At certain points in time, it stops working. Calls to "remote methods" die
        >with
        >
        > Can't connect to my.host.name:80 (Bad file descriptor)

        This all turned out to be the fault of PerlApp. It's an old version (v2.0,
        current version is 4 or 5), and somehow the packaged code didn't work the
        same way as the normal script (file handles weren't released after the SOAP
        call). That was a surprising first...

        I turned to PAR and, while I had some trouble with it, it worked out fine
        in the end.


        /J

        -------- ------ ---- --- -- -- -- - - - - -
        Johan Lindström Sourcerer @ Boss Casinos johanl@...

        Latest bookmark: "Project Management Graph & Diagram for Visualiz..."
        http://www.perlmonks.org/index.pl?node_id=278918
        dmoz (1 of 6): /Arts/Music/Record_Labels/4/ 78
      Your message has been successfully submitted and would be delivered to recipients shortly.