RE: sybperl ct_config CS_RETRY_COUNT
| Newsgroups | gmane.comp.lang.perl.modules.dbi.sybase |
|---|---|
| Message-ID | <[email protected]> |
I tried your a.pl script here, and it ran as I would expect it to: [pepm01a@sgvlin01 perl]$ perl a.pl Open Client Message: Message number: LAYER = (5) ORIGIN = (3) SEVERITY = (5) NUMBER = (4) Message String: ct_connect(): network packet layer: internal net library error: Net-Lib protocol driver call to connect two endpoints failed connection failed... at a.pl line 15. Can't call method "ct_sql" on an undefined value at a.pl line 18. I'm running OpenClient 12.5.1 EBF 11776 on linux in this instance. I still don't understand why isql exits immediately after a failed connection, and sqsh and perl scripts don't. They all three use the same underlying OpenClient calls, AFAIK. Michael Internet [email protected] - 01/09/2005 05:18 Please respond to [email protected] To: Michael PEPPLER cc: sybperl-l Subject: RE: sybperl ct_config CS_RETRY_COUNT Hi Michael, I did not change anything in the OCS-12_5/config/ directory. The files are : /home/sybase/OCS-12_5/config> ls -l total 18 -rw-r--r-- 1 sybase sybase 463 Apr 30 2003 libtcl.cfg -rw-r--r-- 1 sybase sybase 1529 Sep 27 1996 sample.cfg -rw-r--r-- 1 sybase sybase 2021 Nov 22 2002 sybase-schema.conf -rw-r--r-- 1 sybase sybase 3488 Nov 22 2002 sybase.schema /home/sybase/OCS-12_5/config> I had installed the servers about 3-4 months ago. The timestamps show that they have not been altered. I checked again, that if I add retry_count etc. info in the interfaces file, both sybperl and sqsh do not pick it up and try indefinitely to connect to a server which is down. On the contrary, isql too does not pick it up, but returns after the first attempt. I am attaching a simple script - a.pl. If you have some time, please try it on your machine. On my machine, it carries on indefinitely. I could simulate the functionality expected of CS_RETRY_COUNT by putting in some code in the callback routine. After some number of tries, instead of CS_SUCCEED, I return CS_FAIL. Since the manual says: "In the case of timeout errors, CS_SUCCEED causes Client-Library to wait for one additional timeout period." And this seems to work fine. Please see script b.pl So, for the time, I have a workaround. Thanks a lot for your kind support. Best regards, Ashish -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: Wednesday, August 31, 2005 6:41 PM To: [email protected] Cc: [email protected] Subject: RE: sybperl ct_config CS_RETRY_COUNT There's got to be something fishy about your setup, or about your script. In general when a connection fails it shouldn't retry forever - it should abort and return control to the script, where you can connect to the next db, or whatever. Do you have anything special in the OCS-12_5/config/ directory that might enable a non-default behavior? Michael Internet [email protected]@peppler.org - 30/08/2005 09:53 Please respond to [email protected] Sent by: [email protected] To: oladar cc: Michael PEPPLER, mpeppler, sybperl-l Subject: RE: sybperl ct_config CS_RETRY_COUNT Thanks Sean. I tried this too. But it did not work for sybperl and sqsh. It worked for isql. Regards, Ashish -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Sean Dwyer Sent: Tuesday, August 30, 2005 4:23 PM To: [email protected] Cc: [email protected]; [email protected]; [email protected] Subject: Re: sybperl ct_config CS_RETRY_COUNT it has been a long time since I used this but in the interfaces file it used to be possible ((11.5)) to set the retry count and retry interval. CTlib would read this and give you a finite loop. For example: sybserver 2 3 master tcp ether server.domain 11002 query tcp ether server.domain 11002 The client library would read this and try 2 times on 3 second intervals. Where if the entry was: sybserver master tcp ether server.domain 11002 query tcp ether server.domain 11002 you could be caught in a near infinite loop. I haven't tried this since 11.5 and may have it reversed. Worth a try though. Sean On Aug 29, 2005, at 6:27 PM, Ashish Gupta wrote: > Hi Michael, > > Thanks for the patch information. > I changed CTlib.xs as suggested by you. > I re-installed sybperl. > I checked that the CTlib.c has the line and also that CTlib.o also has > the string CS_RETRY_COUNT. > > Still, the property is not settable. > In my script, I set the value to 2, but the connection retries > carry on > until I stop the program with a control-c. > > I am pasting my program below for your reference. > In this, I have brought the second server - SYB_DBA62_TKD - down for > testing. > > use Sybase::CTlib; > > $user = "uuuuu"; $pass = "ppppp"; > $charset = "iso_1"; $Host = "tktecwsd20"; > > ct_config(CS_SET, CS_LOGIN_TIMEOUT, 2, CS_INT_TYPE); > foreach $server (qw(SYB_DBA61_TKD SYB_DBA62_TKD SYB_DBA63_TKD)){ > $dbh = Sybase::CTlib->ct_connect($user, $pass, $server, $Me, > { CON_PROPS => { CS_SYB_CHARSET => > "$charset", > CS_HOSTNAME > => "$Host", > CS_RETRY_COUNT > => 2 > } > } ); > @rrows = $dbh->ct_sql("select count(*) from sysdatabases"); > $dbcount = ${$rrows[0]}[0]; > print "Server: $server, Number of Databases: $dbcount \n"; > } > > > Thanks again for your kind help. > > Best regards, > Ashish > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] > Sent: Monday, August 29, 2005 5:54 PM > To: [email protected] > Cc: [email protected]; [email protected] > Subject: RE: sybperl ct_config CS_RETRY_COUNT > > > Actually the patch is very simple: > > Around line 6089 (in the ct_connect() function), just add this: > > SV **svp = hv_fetch((HV*)SvRV(attr), "CON_PROPS", 9, 0); > SV *sv; > HV *hv; > if(svp && SvROK(*svp)) { > int i; > CS_RETCODE ret; > static struct props { > char *name; int attr; int type; > } props[] = { > { "CS_HOSTNAME", CS_HOSTNAME, CS_CHAR_TYPE}, > { "CS_ANSI_BINDS", CS_ANSI_BINDS, CS_INT_TYPE}, > { "CS_PACKETSIZE", CS_PACKETSIZE, CS_INT_TYPE}, > { "CS_SEC_APPDEFINED", CS_SEC_APPDEFINED, > CS_INT_TYPE}, > { "CS_SEC_CHALLENGE", CS_SEC_CHALLENGE, CS_INT_TYPE}, > { "CS_SEC_ENCRYPTION", CS_SEC_ENCRYPTION, > CS_INT_TYPE}, > { "CS_SEC_NEGOTIATE", CS_SEC_NEGOTIATE, CS_INT_TYPE}, > { "CS_TDS_VERSION", CS_TDS_VERSION, CS_INT_TYPE}, > #if defined(CS_HAFAILOVER) > { "CS_HAFAILOVER", CS_HAFAILOVER, CS_INT_TYPE}, > #endif > { "CS_BULK_LOGIN", CS_BULK_LOGIN, CS_INT_TYPE}, > #if defined(CS_SEC_NETWORKAUTH) > { "CS_SEC_NETWORKAUTH", CS_SEC_NETWORKAUTH, > CS_INT_TYPE}, > #endif > #if defined(CS_SEC_SERVERPRINCIPAL) > { "CS_SEC_SERVERPRINCIPAL", CS_SEC_SERVERPRINCIPAL, > CS_CHAR_TYPE}, > #endif > #if defined(CS_SERVERADDR) > { "CS_SERVERADDR", CS_SERVERADDR, CS_CHAR_TYPE}, > #endif > { "CS_RETRY_COUNT", CS_RETRY_COUNT, CS_INT_TYPE }, /* > <----------------- add this!! */ > { "CS_SYB_LANG", CS_SYB_LANG, -1 }, > { "CS_SYB_CHARSET", CS_SYB_CHARSET, -1 }, > { "CS_DATA_LCHAR", CS_DATA_LCHAR, -2 }, > { "", 0, 0} > }; > hv = (HV*)SvRV(*svp); > > > and rebuild, and all should be well. > > Michael > > > > > Internet > [email protected]@peppler.org - 29/08/2005 03:01 > > Please respond to [email protected] > Sent by: [email protected] > To: mpeppler > cc: sybperl-l > Subject: RE: sybperl ct_config CS_RETRY_COUNT > > > Hi Michael, > > Thanks for your prompt and helpful response. > > I tried to look at the code in CTlib.xs and I think it will be next to > impossible for me to attempt a patch. You of course will be busy with > other responsibilities, and so will need some time for this. > > Please can you suggest some workaround? > > Please allow me to explain my requirement and current problem. > > I am trying to write a small library of functions based on perl and > sybperl. These will be used by the other DBA scripts. These will > provide > functions for connecting, writing to errorlog, sending emails etc. > > Usually, for a script such as dump_database, if the server is not > available, the callback routine is invoked, and from there we can exit > with appropriate messages and emails. > > But what I am trying to do is to store information about each > execution > of each script in a central database. This is useful to check at a > glance which scripts failed and which scripts are pending completion. > This is useful for us as we have about 150 servers. So, my > procedure is > as follows: initially at the start of each script, I will record the > "start" in the database. Then, after the completion or abort of the > script, I will record a "finish" or an "abort" in the database. > Now, the > problem is, if a server is down and the dump database script fails > on a > ct_connect (and as a result keeps on trying since I cannot set > CS_RETRY_COUNT), then I cannot even try another ct_connect (to the > central database). The message I get is : > > ct_con_alloc failed at dba_syb_lib.pm line 1073. > ct_con_props(CS_HOSTNAME, 'tktecwsd20') failed. at > dba_syb_lib.pm line 1073. > ct_con_props(CS_LOC_PROP) failed at dba_syb_lib.pm line 1073. > connection failed... at dba_syb_lib.pm line 1073. > > Maybe this message on the next ct_connect will not come if I can set > CS_RETRY_COUNT to 1. > > Another reason (apart from recording in a database) I would like to > connect to multiple servers within the same script (and not be worried > about the ct_connect looping infinitely on a server which is down) > is to > write a script for pinging all the servers. I want to periodically > connect to all servers and check for a successful connection. If I > could > set CS_RETRY_COUNT = 1, then maybe the next ct_connect will be ok. > > This is a long winded explanation. Maybe I can put it simply as > follows. > If my first ct_connect is looping, trying to connect to a server which > is down, how is it possible for me to stop or ignore this and carry on > with the next ct_connect to another server. > > > Thanks again for your kind help. > > Best regards, > Ashish > > > -----Original Message----- > From: Michael Peppler [mailto:[email protected]] > Sent: Friday, August 26, 2005 8:23 PM > To: [email protected] > Cc: [email protected] > Subject: RE: sybperl ct_config CS_RETRY_COUNT > > > On Fri, 2005-08-26 at 15:33 +0900, Ashish Gupta wrote: > >> Hi Michael, >> >> I still get an error. >> >> I tried the command : >> >> ct_config(CS_SET, 9173, 2, CS_INT_TYPE); >> >> >> And the following error was reported : >> >> Open Client Message: >> Message number: LAYER = (1) ORIGIN = (1) SEVERITY = (1) NUMBER = (5) >> Message String: ct_config(): user api layer: external error: An >> > illegal > >> value of 9173 given for parameter property. >> > > Indeed - the problem is that CS_RETRY_COUNT is a connection > property, to > be set with ct_con_props() before the connection is attempted. This is > handled differently in this module, and will require a patch to the > code > to get working. You can see how the other connection properties are > handled in CTlib.xs around line 6065 in my copy. > > Michael > -- > Michael Peppler - [email protected] - http://www.peppler.org/ > Sybase DBA/Developer > Sybase on Linux FAQ: http://www.peppler.org/FAQ/linux.html > > > Note: This e-mail contains privileged and confidential information and > is > for the sole use of the intended recipient(s). If you are not an > intended > recipient, you are hereby kindly requested to refrain from printing, > copying, or distributing the information contained herein. > Furthermore, > > any other use of the information contained herein is strictly > prohibited. > If you have received this transmission in error, please kindly notify > the > sender immediately and destroy all copies of the original message. > > > > This message and any attachments (the "message") is > intended solely for the addressees and is confidential. > If you receive this message in error, please delete it and > immediately notify the sender. Any use not in accord with > its purpose, any dissemination or disclosure, either whole > or partial, is prohibited except formal approval. The internet > can not guarantee the integrity of this message. > BNP PARIBAS (and its subsidiaries) shall (will) not > therefore be liable for the message if modified. > > --------------------------------------------- > > Ce message et toutes les pieces jointes (ci-apres le > "message") sont etablis a l'intention exclusive de ses > destinataires et sont confidentiels. Si vous recevez ce > message par erreur, merci de le detruire et d'en avertir > immediatement l'expediteur. Toute utilisation de ce > message non conforme a sa destination, toute diffusion > ou toute publication, totale ou partielle, est interdite, sauf > autorisation expresse. L'internet ne permettant pas > d'assurer l'integrite de ce message, BNP PARIBAS (et ses > filiales) decline(nt) toute responsabilite au titre de ce > message, dans l'hypothese ou il aurait ete modifie. > > Note: This e-mail contains privileged and confidential information > and is for the sole use of the intended recipient(s). If you are > not an intended recipient, you are hereby kindly requested to > refrain from printing, copying, or distributing the information > contained herein. Furthermore, any other use of the information > contained herein is strictly prohibited. If you have received this > transmission in error, please kindly notify the sender immediately > and destroy all copies of the original message. > > Note: This e-mail contains privileged and confidential information and is for the sole use of the intended recipient(s). If you are not an intended recipient, you are hereby kindly requested to refrain from printing, copying, or distributing the information contained herein. Furthermore, any other use of the information contained herein is strictly prohibited. If you have received this transmission in error, please kindly notify the sender immediately and destroy all copies of the original message. Note: This e-mail contains privileged and confidential information and is for the sole use of the intended recipient(s). If you are not an intended recipient, you are hereby kindly requested to refrain from printing, copying, or distributing the information contained herein. Furthermore, any other use of the information contained herein is strictly prohibited. If you have received this transmission in error, please kindly notify the sender immediately and destroy all copies of the original message. (See attached file: a.pl) (See attached file: b.pl)
a.pl
(application/octet-stream, 1.4 KB)
#!/export/home/guptaash/perl/bin/perl -w
use Sybase::CTlib;
ct_callback(CS_CLIENTMSG_CB, "f_ctlib_cli_cb");
ct_callback(CS_SERVERMSG_CB, "f_ctlib_srv_cb");
$me = "b.pl";
$server = "SYB_DBA62_TKD"; # server intentionally down.
$user = "u";
$pass = "p";
ct_config(CS_SET, CS_LOGIN_TIMEOUT, 2, CS_INT_TYPE);
$dbh = Sybase::CTlib->ct_connect($user, $pass, $server, $me,
{ CON_PROPS => { CS_RETRY_COUNT => 5 } } );
@rrows = $dbh->ct_sql("select count(*) from sysdatabases");
$dbcount = ${$rrows[0]}[0];
print "Server: $server, Number of Databases: $dbcount \n";
exit;
sub f_ctlib_cli_cb
{
my($layer, $origin, $severity, $number, $msg, $osmsg) = @_;
$err_str = "\nOpen Client Message:\n";
$err_str .= "Message number: LAYER = ($layer) ORIGIN = ($origin) ";
$err_str .= "SEVERITY = ($severity) NUMBER = ($number)\n";
$err_str .= "Message String: $msg\n";
$err_str .= "Op. System Error: $osmsg\n" if (defined($osmsg));
print "$err_str \n";
CS_SUCCEED;
}
sub f_ctlib_srv_cb
{
my($cmd, $number, $sev, $state, $line, $server, $proc, $msg) = @_;
$err_str = "\nServer message:\n";
$err_str .= "Msg no. $number, Svty $sev, State $state, Line $line\n";
$err_str .= "Server $server\n" if (defined($server));
$err_str .= " Procedure $proc\n" if (defined($proc));
$err_str .= "Message String: $msg\n";
print "$err_str \n";
CS_SUCCEED;
}
b.pl
(application/octet-stream, 1.8 KB)
#!/export/home/guptaash/perl/bin/perl -w
use Sybase::CTlib;
ct_callback(CS_CLIENTMSG_CB, "f_ctlib_cli_cb");
ct_callback(CS_SERVERMSG_CB, "f_ctlib_srv_cb");
$me = "b.pl";
$server = "SYB_DBA62_TKD"; # server intentionally down.
$user = "u";
$pass = "p";
$RetryCount = 2;
$ConnectionTry = 1;
ct_config(CS_SET, CS_LOGIN_TIMEOUT, 2, CS_INT_TYPE);
$dbh = Sybase::CTlib->ct_connect($user, $pass, $server, $me,
{ CON_PROPS => { CS_RETRY_COUNT => 2 } } );
if ($ConnectionTry == $RetryCount){
print "Sorry, we coud not connect to the server.\n";
} else {
@rrows = $dbh->ct_sql("select count(*) from sysdatabases");
$dbcount = ${$rrows[0]}[0];
print "Server: $server, Number of Databases: $dbcount \n";
}
exit;
sub f_ctlib_cli_cb
{
my($layer, $origin, $severity, $number, $msg, $osmsg) = @_;
$err_str = "\nOpen Client Message:\n";
$err_str .= "Message number: LAYER = ($layer) ORIGIN = ($origin) ";
$err_str .= "SEVERITY = ($severity) NUMBER = ($number)\n";
$err_str .= "Message String: $msg\n";
$err_str .= "Op. System Error: $osmsg\n" if (defined($osmsg));
print "$err_str \n";
if ($msg =~ /Read from the server has timed out/){
if ($ConnectionTry == $RetryCount){
return CS_FAIL;
} else {
$ConnectionTry++;
return CS_SUCCEED;
}
}
}
sub f_ctlib_srv_cb
{
my($cmd, $number, $sev, $state, $line, $server, $proc, $msg) = @_;
$err_str = "\nServer message:\n";
$err_str .= "Msg no. $number, Svty $sev, State $state, Line $line\n";
$err_str .= "Server $server\n" if (defined($server));
$err_str .= " Procedure $proc\n" if (defined($proc));
$err_str .= "Message String: $msg\n";
print "$err_str \n";
CS_SUCCEED;
}