|
|
sybperl-l Archive
Up Prev Next
From: Sean Dwyer <oladar at drizzle dot com>
Subject: Re: sybperl ct_config CS_RETRY_COUNT
Date: Aug 30 2005 7:22AM
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: michael.peppler@bnpparibas.com
> [mailto:michael.peppler@bnpparibas.com]
> Sent: Monday, August 29, 2005 5:54 PM
> To: ashish.gupta@mizuho-sc.com
> Cc: mpeppler@peppler.org; sybperl-l@peppler.org
> 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
> ashish.gupta@mizuho-sc.com@peppler.org - 29/08/2005 03:01
>
> Please respond to ashish.gupta@mizuho-sc.com
> Sent by: owner-sybperl-l@peppler.org
> 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:mpeppler@peppler.org]
> Sent: Friday, August 26, 2005 8:23 PM
> To: ashish.gupta@mizuho-sc.com
> Cc: sybperl-l@peppler.org
> 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 - mpeppler@peppler.org - 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.
>
>
|
