No change. (I didn't think it would, but I'd try ANY long shot I could get).
Lincoln 215-444-7973 (office) 267-716-1370 (cellular) -----Original Message----- From: Tim Bunce [mailto:[EMAIL PROTECTED] Sent: Monday, August 04, 2003 6:05 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: FW: crippling problem with signals and Oracle 9i client libriarie s Does adding "use DBD::Oracle;" to the start of the script help? (Just a long-shot related to how dynamic loading a library linked with threads into a binary that isn't interacts with alarms on Solaris.) On Solaris using truss (-v etc) will show what's happening to the signals. Tim. On Mon, Aug 04, 2003 at 11:29:46AM -0400, [EMAIL PROTECTED] wrote: > Hi All, > > > > I thought I would share this message with you, in case you > > > > a) did not know of this problem, or > > b) you know of a "cure" for this problem. > > > > I do not think this a PERL or a DBI issue per se, but it affects the users > of DBI. > > > > Comments/Information welcome... > > > > Lincoln > > > > > > Sent to our internal DBA support group: > > > > > > -----Original Message----- > From: me > Subject: crippling problem with signals and Oracle 9i client libriaries > > Hi all, > > I have found what I believe to be a problem with the Oracle 9.2.0 (9i) > client libraries and signal handling which I think is crippling. It will > PREVENT us from fully upgrading to Oracle 9i until it can be fixed. > > We all know that Oracle client hangs for a VERY long time (something like 10 > minutes), if sqlnet can not reach the box it is told a database is on (i.e. > the box is down). We have worked around this "bug" with the use of SIGALRM > as illustrated in the test program which follows: > > #!/usr/bin/env perl > > use strict; > use warnings; > use DBI; > use Time::HiRes qw( ualarm ); > > > my ( $timeout ) = @ARGV; > $timeout = 3 if not defined $timeout; > print "using timeout of $timeout seconds\n" ; > eval > { > local $SIG{ALRM} = sub > { > die "connect timeout after $timeout seconds" ; > }; > > ualarm($timeout * 1_000_000); > > my $dbh = DBI->connect( "dbi:Oracle:dbfail" ,"foo" ,"bar" > ,{ AutoCommit=>0 ,RaiseError=>1 ,PrintError=>1 } ); > }; > ualarm(0); > if ( $@ ) > { > die $@; > } > > With the Oracle 8.x libraries this code hangs until the timer expires > (default=3 seconds), and then prints: > > connect timeout after 3 seconds at ./test.connect.dbfail.pl line 16. > > This is the desired behavior, because it returns control to the program, > which can then handle the error. > > I have run this code against: > > perl 5.6.1 and Oracle 8.1.7 (sun and HP) (succeeds) > perl 5.6.1 and Oracle 8.1.5 (linux) (succeeds) > perl 5.8.0 and Oracle 8.1.5 (linux) (succeeds) > perl 5.8.0 and Oracle 9.2.0 (sun and HP) (FAILS) > > With Oracle 9.x libraries this code hangs and never returns. Further, the > only signal the process will accept is KILL (9), which it has to accept. > This tells me that the 9.x libraries are disabling all or most signals, > making it impossible for us to use the Oracle 9i libraries in servers. > > DBAs: Please research this on OTN, and if necesssary open a bug report with > Oracle. > > THIS IS A BLOCKING ISSUE for completing the 9.2 Oracle upgrade, and being > able to remove the 8.1.7 client. > > If we can not get a resolution of this issue from Oracle, I will have to > rebuild the perl 5.8.0 tree with Oracle 8.1.7 libraries (instead of the > 9.2.0 libraries it is currently linked with). > > I hope Oracle already has a patch for this problem. > > Lincoln > > > PS, although I think it not relevant, this is DBI version 1.37 and > DBD::Oracle version 1.14. I believe I would be able to replicate this with > earlier versions of DBI and DBD:Oracle. >
