[sf-perl] Bad file number

[Michael Friedman]

I've had a similar problem with too-many-database-connections-causing- 
problems with Sybperl. Not due to filehandles in my case, but a  
similar solution might help you. In my case, the solution was to  
cache those connections and reuse them.

I don't know what your code looks like, but perhaps you could open  
the DB connections in a larger scope and reuse them instead of  
creating and destroying them as you go along. So rather than having  
35 DB connections open, you might only have 5 or 6 that you can share.

In my system, we have a separate object (a Singleton) that holds the  
cache of DB connections and other objects check out a connection, use  
it, and check it back in when they're done. New connections are only  
created if you run out of existing ones. And since my code is pretty  
much single-threaded, we almost never use more than 2 connections at  
a time this way.

YMMV, but it might be a way to get around the problem.

-- Mike

On Jun 22, 2007, at 9:18 AM, Loo, Peter # PHX wrote:

> Thanks again Steve.  I was going crazy looking for any clues that  
> would
> lead to the reason why I would get this error message.  I walked  
> through
> the logic to make sure that there is one close() for every open() and
> also checked the result of both.  It turns out that the ODBC driver  
> that
> I am using for Netezza database is opening the odbc.ini file 7  
> times for
> every connect to the database and is not closing the file.  I wrote a
> simple program to loop through and connect and disconnect from the
> database and watched my PID using lsof and learn that each connection
> added 7 file handles for odbc.ini file.  It continued until it reached
> the threshold of 256 file handles.  I wanted to look through the  
> code to
> the ODBC driver, but because it is compiled and was given to us by the
> vendor, we have opened a ticket with them.
>
> Thanks for all your help.  Have a nice weekend.
>
> Peter
>
> -----Original Message-----
> From: sanfrancisco-pm-bounces 
> +peter.loo=source.wolterskluwer.com at pm.org
> [mailto:sanfrancisco-pm-bounces 
> +peter.loo=source.wolterskluwer.com at pm.or
> g] On Behalf Of Steve Fink
> Sent: Thursday, June 21, 2007 9:46 PM
> To: San Francisco Perl Mongers User Group
> Subject: Re: [sf-perl] Bad file number
>
> On 6/21/07, Quinn Weaver <quinn at fairpath.com> wrote:
>> On Thu, Jun 21, 2007 at 02:30:40PM -0700, Loo, Peter # PHX wrote:
>>> I have checked the logic and it appears that there is a
>>> corresponding close() for every open().  I don't know why Perl is
>>> warning me with this error.
>>
>> Just "checking the logic" by looking at your code doesn't cut it.
>> You need to test empirically whether your code is doing what you  
>> think
> it is.
>>
>> Try putting warn "closed file MYFILE successfully" after your close
>> statements... just to verify that what you think is happening is
>> actually happening.
>>
>> Make a habit of testing your assumptions this way.  It is the royal
>> road to figuring out bugs.  Debugging is a matter of practice, not
>> theory-- because if the code were working the way that you think in
>> theory it should be, you wouldn't have a bug!
>
> Good general advice, but I'm not sure how well it applies in this
> situation. How many ways can close() fail in such a way that the file
> descriptor is not closed? If it did, what would the user be able to do
> about it? (There are many ways for close() to fail, as many as  
> there are
> ways that write() can fail, but close() should still close the
> fd.)
>
> There *is* actually one way, if close() returned EINTR, but I doubt
> that's what is happening here. I'm guessing the logic isn't quite  
> right.
> Checking the result of close() may indeed point out valuable clues,
> though. (eg if it is returning EINVAL, perhaps you're not closing what
> you think.) _______________________________________________
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm
>
>
> This E-mail message is for the sole use of the intended recipient 
> (s) and
> may contain confidential and privileged information.  Any unauthorized
> review, use, disclosure or distribution is prohibited.  If you are not
> the intended recipient, please contact the sender by reply E-mail, and
> destroy all copies of the original message.
> _______________________________________________
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm

---------------------------------------------------------------------
Michael Friedman                     HighWire Press
Phone: 650-725-1974                  Stanford University
FAX:   270-721-8034                  <friedman at highwire.stanford.edu>
---------------------------------------------------------------------