Sybase NNTP forums - End Of Life (EOL)

The NNTP forums from Sybase - forums.sybase.com - are now closed.

All new questions should be directed to the appropriate forum at the SAP Community Network (SCN).

Individual products have links to the respective forums on SCN, or you can go to SCN and search for your product in the search box (upper right corner) to find your specific developer center.

rep agents down

13 posts in Replication Agent Last posting was on 2004-04-20 18:19:42.0Z
Jill G Posted on 2004-04-01 18:44:15.0Z
From: "Jill G" <jill@ici.org>
Newsgroups: sybase.public.rep-agent
Subject: rep agents down
Lines: 54
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Original-NNTP-Posting-Host: client206.ici.org
Message-ID: <406c62fa$1@forums-2-dub>
X-Original-Trace: 1 Apr 2004 10:44:10 -0800, client206.ici.org
X-Original-NNTP-Posting-Host: forums-2-dub.sybase.com
X-Original-Trace: 1 Apr 2004 10:44:12 -0800, forums-2-dub.sybase.com
NNTP-Posting-Host: forums-master.sybase.com
X-Original-NNTP-Posting-Host: forums-master.sybase.com
Date: 1 Apr 2004 10:44:15 -0800
X-Trace: forums-1-dub 1080845055 10.22.108.75 (1 Apr 2004 10:44:15 -0800)
X-Original-Trace: 1 Apr 2004 10:44:15 -0800, forums-master.sybase.com
X-Authenticated-User: ngsysop
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.rep-agent:658
Article PK: 862309

I have a warm standby replication (solaris 9/ase 12.5 rep 12.5) where
everything is working beautifully for the most part. so far i have 29
databases replicating. however, only about 7 are actually active databases.
the others really shouldn't have any consistent transaction processing going
on - but may periodically.

when i do admin who_is_down it ALWAYS shows
1> admin who_is_down
2> go
Spid Name State Info
---- ---------- -------------------- --------------------------------------
--
REP AGENT Down ICI_PRIMARY.InternationalSurvey
REP AGENT Down ICI_PRIMARY.ici_info
REP AGENT Down ICI_PRIMARY.unify_brokdeal
REP AGENT Down ICI_PRIMARY.unify_clexpense
REP AGENT Down ICI_PRIMARY.unify_expsurvey
REP AGENT Down ICI_PRIMARY.unify_icdi
REP AGENT Down ICI_PRIMARY.unify_ics
REP AGENT Down ICI_PRIMARY.unify_newclosed
REP AGENT Down ICI_PRIMARY.unify_operations
REP AGENT Down ICI_PRIMARY.unify_pi
REP AGENT Down ICI_PRIMARY.unify_pistats
REP AGENT Down ICI_PRIMARY.webmonitor
REP AGENT Down ICI_PRIMARY.weeklyflow

however, when i try to start the REP AGENT for any of these i get a message
saying there is already a thread running:
1> use weeklyflow
2> go
1> sp_start_rep_agent weeklyflow
2> go
Msg 9262, Level 16, State 0:
Server 'ICI_PRIMARY', Procedure 'sp_start_rep_agent', Line 174:
Failed to start a Rep Agent Thread for the database specified because a Rep
Agent Thread is already running for that database.
Msg 18421, Level 16, State 1:
Server 'ICI_PRIMARY', Procedure 'sp_start_rep_agent', Line 179:
Failed to start the Replication Agent thread for database 'weeklyflow'.
(return status = 1)

These are ALWAYS the inactive databases. I don't get this for the 6
databases that have constant transaction processing. We are inside a
firewall and the pix is configured to time-out any connections after several
minutes of inactivity. With the databases that are constantly changing -
this doesn't seem to pose any problems. but for the stagnant ones, it seems
as if the rep server is assuming that if the connection from the REP AGENT
timed out then it is down.

In order to get these databases to show the REP AGENT is up, i have to stop
the rep agent and restart it. seems silly to me. any ideas? (and no, i'm not
going to write fake transactions to keep the connections alive).


Carel Cornelius Posted on 2004-04-05 21:40:47.0Z
From: "Carel Cornelius" <carel@sybase.nospam.co.za>
Newsgroups: sybase.public.rep-agent
References: <406c62fa$1@forums-2-dub>
Subject: Re: rep agents down
Lines: 60
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Message-ID: <4072449b_1@sybmail.sybase.co.za>
X-Original-NNTP-Posting-Host: 127.0.0.1
NNTP-Posting-Host: 158.76.48.248
X-Original-NNTP-Posting-Host: 158.76.48.248
Date: 5 Apr 2004 13:40:47 -0800
X-Trace: forums-1-dub 1081197647 158.76.48.248 (5 Apr 2004 13:40:47 -0800)
X-Original-Trace: 5 Apr 2004 13:40:47 -0800, 158.76.48.248
X-Authenticated-User: techsupp
Path: forums-1-dub!sybmail.sybase.co.za
Xref: forums-1-dub sybase.public.rep-agent:661
Article PK: 862312

Jill,

You are probably running into the default limit of 50 threads allowed on
RepServer, or your configured value is still too low for the number of
threads required for all databases configured.

You say that there are 29 databases configured. Not sure if it's 29 DBs in
total or 29 x WS pairs.

That will be a minimum of at least all the "usual" Repserver threads ( about
8 ) + about 9 threads per standard WS connection:

2 x SQM (1 for each SQM - 1 inbound, 1 outbound )
2 x DSI ( one per physical - depends on num DSI threads for parallel
DSI )
2 x DSI EXEC ( one per DSI thread - depends on num DSI threads )
1 for each DIST
1 for each SQT
1 for each RepAgent

You need to increase 'num_threads' config parameter for RepServer to allow
for all of these threads.

Also look at "num_msgqueues" and "num_mutexes" parameters, which should be
higher than "num_threads" config parameter.

Quick way to "thumb-suck" this value is to isql into RepServer and execute
"admin who". Count number of rows returned and add a couple 20-30 or so for
future reference. Use this for 'num_threads' config value.

There are 2 ways to config RepServer :

1) isql into RepServer and execute:
configure replication server set 'num_threads' to '280'
go
configure replication server set 'num_mutexes' to '350'
go
configure replication server set 'num_msgqueues' to '350'
go

2) isql into the RSSD database and execute:
rs_configure 'num_threads', '280'
go
rs_configure 'num_mutexes', '350'
go
rs_configure 'num_msgqueues', '350'
go

Restart RepServer which will now allow more than the 50 (or whatever)
threads.
Also remember to allow for the total memory that will be used by all the
caches for all the DSI threads . . .

Regards

Carel


Jill G Posted on 2004-04-08 19:39:38.0Z
From: "Jill G" <jill@ici.org>
Newsgroups: sybase.public.rep-agent
References: <406c62fa$1@forums-2-dub> <4072449b_1@sybmail.sybase.co.za>
Subject: Re: rep agents down
Lines: 102
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Original-NNTP-Posting-Host: client55.ici.org
Message-ID: <40759c66$1@forums-2-dub>
X-Original-Trace: 8 Apr 2004 11:39:34 -0800, client55.ici.org
X-Original-NNTP-Posting-Host: forums-2-dub.sybase.com
X-Original-Trace: 8 Apr 2004 11:39:35 -0800, forums-2-dub.sybase.com
NNTP-Posting-Host: forums-master.sybase.com
X-Original-NNTP-Posting-Host: forums-master.sybase.com
Date: 8 Apr 2004 11:39:38 -0800
X-Trace: forums-1-dub 1081449578 10.22.108.75 (8 Apr 2004 11:39:38 -0800)
X-Original-Trace: 8 Apr 2004 11:39:38 -0800, forums-master.sybase.com
X-Authenticated-User: ngsysop
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.rep-agent:662
Article PK: 862313

Carel,

Many thanks for your help. I upped the values to the following and rebooted
the replication server. The following are the current values. After I
rebooted the server, all the rep agents came up, however, again, the REP
AGENTS for the same 15 inactive databases now report as being down. This
happened at roughly the same time that the pix timed out my terminal session
for inactivity to the machine hosting the rep server. There are no messages
in the rep server error log regarding these agents, the replicate ASE server
(housing the RSSD), nor the primary error log.


Config Name Config Value Run Value
-------------------------- ---------------------- -------------------------
-
num_threads 450 450
num_mutexes 520 520
num_msgqueues 520 520


I went into one of these databases and made a change to see what would
happen. What happens is that even though the rep server says the REP AGENT
is down it isn't really down. The rep agent definitely detected the change.
The following line was found in the rep server error log:

I. 2004/04/08 14:39:03. Replication Agent for ICI_PRIMARY.ici_info connected
in passthru mode.

(ici_info being the database in which i made the change). Now, when i do an
admin who_is_down this database is not on the list of REP AGENTS that are
down (but i guarentee as soon as it times out it will be).

Any ideas to keep these rep agents alive so the rep server doesn't report
them as down?

"Carel Cornelius" <carel@sybase.nospam.co.za> wrote in message
news:4072449b_1@sybmail.sybase.co.za...
> Jill,
>
> You are probably running into the default limit of 50 threads allowed on
> RepServer, or your configured value is still too low for the number of
> threads required for all databases configured.
>
> You say that there are 29 databases configured. Not sure if it's 29 DBs in
> total or 29 x WS pairs.
>
> That will be a minimum of at least all the "usual" Repserver threads (
about
> 8 ) + about 9 threads per standard WS connection:
>
> 2 x SQM (1 for each SQM - 1 inbound, 1 outbound )
> 2 x DSI ( one per physical - depends on num DSI threads for parallel
> DSI )
> 2 x DSI EXEC ( one per DSI thread - depends on num DSI threads )
> 1 for each DIST
> 1 for each SQT
> 1 for each RepAgent
>
> You need to increase 'num_threads' config parameter for RepServer to allow
> for all of these threads.
>
> Also look at "num_msgqueues" and "num_mutexes" parameters, which should be
> higher than "num_threads" config parameter.
>
> Quick way to "thumb-suck" this value is to isql into RepServer and execute
> "admin who". Count number of rows returned and add a couple 20-30 or so
for
> future reference. Use this for 'num_threads' config value.
>
> There are 2 ways to config RepServer :
>
> 1) isql into RepServer and execute:
> configure replication server set 'num_threads' to '280'
> go
> configure replication server set 'num_mutexes' to '350'
> go
> configure replication server set 'num_msgqueues' to '350'
> go
>
> 2) isql into the RSSD database and execute:
> rs_configure 'num_threads', '280'
> go
> rs_configure 'num_mutexes', '350'
> go
> rs_configure 'num_msgqueues', '350'
> go
>
> Restart RepServer which will now allow more than the 50 (or whatever)
> threads.
> Also remember to allow for the total memory that will be used by all the
> caches for all the DSI threads . . .
>
> Regards
>
> Carel
>
>
>
>


Greg Carter Posted on 2004-04-12 17:41:58.0Z
Message-ID: <407AC6D2.4030402@workmail.com>
From: Greg Carter <greg.carter@workmail.com>
Reply-To: greg.carter@workmail.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
Newsgroups: sybase.public.rep-agent
To: Jill G <jill@ici.org>
Subject: Re: rep agents down
References: <406c62fa$1@forums-2-dub> <4072449b_1@sybmail.sybase.co.za> <40759c66$1@forums-2-dub>
In-Reply-To: <40759c66$1@forums-2-dub>
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: vpn-dub-043.sybase.com
X-Original-NNTP-Posting-Host: vpn-dub-043.sybase.com
Date: 12 Apr 2004 09:41:58 -0800
X-Trace: forums-1-dub 1081788118 10.22.120.43 (12 Apr 2004 09:41:58 -0800)
X-Original-Trace: 12 Apr 2004 09:41:58 -0800, vpn-dub-043.sybase.com
Lines: 147
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.rep-agent:664
Article PK: 862314

Jill,

Unless there are changes that will force the RepAgent to send something to RepServer, then following a reboot of RepServer, RepServer will think that the RepAgent has not connected. My guess is that since these databases are rarely updated with replicated changes, then when RepServer is re-booted (for what ever reason) it reports these RepAgent as down (or "not connected" would be better) until a changes is mode that forces the RepAgent to re-cycle their connections.

-- Thanks, G.Carter Sybase Replication Server Engineering mailto:greg.carter@workmail.com


Jill G wrote:

Carel, Many thanks for your help. I upped the values to the following and rebooted the replication server. The following are the current values. After I rebooted the server, all the rep agents came up, however, again, the REP AGENTS for the same 15 inactive databases now report as being down. This happened at roughly the same time that the pix timed out my terminal session for inactivity to the machine hosting the rep server. There are no messages in the rep server error log regarding these agents, the replicate ASE server (housing the RSSD), nor the primary error log. Config Name Config Value Run Value -------------------------- ---------------------- ------------------------- - num_threads 450 450 num_mutexes 520 520 num_msgqueues 520 520 I went into one of these databases and made a change to see what would happen. What happens is that even though the rep server says the REP AGENT is down it isn't really down. The rep agent definitely detected the change. The following line was found in the rep server error log: I. 2004/04/08 14:39:03. Replication Agent for ICI_PRIMARY.ici_info connected in passthru mode. (ici_info being the database in which i made the change). Now, when i do an admin who_is_down this database is not on the list of REP AGENTS that are down (but i guarentee as soon as it times out it will be). Any ideas to keep these rep agents alive so the rep server doesn't report them as down? "Carel Cornelius" <carel@sybase.nospam.co.za> wrote in message news:4072449b_1@sybmail.sybase.co.za...
Jill, You are probably running into the default limit of 50 threads allowed on RepServer, or your configured value is still too low for the number of threads required for all databases configured. You say that there are 29 databases configured. Not sure if it's 29 DBs in total or 29 x WS pairs. That will be a minimum of at least all the "usual" Repserver threads (
about
8 ) + about 9 threads per standard WS connection: 2 x SQM (1 for each SQM - 1 inbound, 1 outbound ) 2 x DSI ( one per physical - depends on num DSI threads for parallel DSI ) 2 x DSI EXEC ( one per DSI thread - depends on num DSI threads ) 1 for each DIST 1 for each SQT 1 for each RepAgent You need to increase 'num_threads' config parameter for RepServer to allow for all of these threads. Also look at "num_msgqueues" and "num_mutexes" parameters, which should be higher than "num_threads" config parameter. Quick way to "thumb-suck" this value is to isql into RepServer and execute "admin who". Count number of rows returned and add a couple 20-30 or so
for
future reference. Use this for 'num_threads' config value. There are 2 ways to config RepServer : 1) isql into RepServer and execute: configure replication server set 'num_threads' to '280' go configure replication server set 'num_mutexes' to '350' go configure replication server set 'num_msgqueues' to '350' go 2) isql into the RSSD database and execute: rs_configure 'num_threads', '280' go rs_configure 'num_mutexes', '350' go rs_configure 'num_msgqueues', '350' go Restart RepServer which will now allow more than the 50 (or whatever) threads. Also remember to allow for the total memory that will be used by all the caches for all the DSI threads . . . Regards Carel


Greg Carter Posted on 2004-04-12 17:34:03.0Z
Message-ID: <407AC4F6.1050304@workmail.com>
From: Greg Carter <greg.carter@workmail.com>
Reply-To: greg.carter@workmail.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
Newsgroups: sybase.public.rep-agent
To: Jill G <jill@ici.org>
Subject: Re: rep agents down
References: <406c62fa$1@forums-2-dub> <4072449b_1@sybmail.sybase.co.za> <40759c66$1@forums-2-dub>
In-Reply-To: <40759c66$1@forums-2-dub>
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: vpn-dub-043.sybase.com
X-Original-NNTP-Posting-Host: vpn-dub-043.sybase.com
Date: 12 Apr 2004 09:34:03 -0800
X-Trace: forums-1-dub 1081787643 10.22.120.43 (12 Apr 2004 09:34:03 -0800)
X-Original-Trace: 12 Apr 2004 09:34:03 -0800, vpn-dub-043.sybase.com
Lines: 147
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.rep-agent:663
Article PK: 862315

Jill,

Unless there are changes that will force the RepAgent to send something to RepServer, then following a reboot of RepServer, RepServer will think that the RepAgent has not connected. My guess is that since these databases are rarely updated with replicated changes, then when RepServer is re-booted (for what ever reason) it reports these RepAgent as down (or "not connected" would be better) until a changes is mode that forces the RepAgent to re-cycle their connections.

-- Thanks, G.Carter Sybase Replication Server Engineering mailto:greg.carter@workmail.com


Jill G wrote:

Carel, Many thanks for your help. I upped the values to the following and rebooted the replication server. The following are the current values. After I rebooted the server, all the rep agents came up, however, again, the REP AGENTS for the same 15 inactive databases now report as being down. This happened at roughly the same time that the pix timed out my terminal session for inactivity to the machine hosting the rep server. There are no messages in the rep server error log regarding these agents, the replicate ASE server (housing the RSSD), nor the primary error log. Config Name Config Value Run Value -------------------------- ---------------------- ------------------------- - num_threads 450 450 num_mutexes 520 520 num_msgqueues 520 520 I went into one of these databases and made a change to see what would happen. What happens is that even though the rep server says the REP AGENT is down it isn't really down. The rep agent definitely detected the change. The following line was found in the rep server error log: I. 2004/04/08 14:39:03. Replication Agent for ICI_PRIMARY.ici_info connected in passthru mode. (ici_info being the database in which i made the change). Now, when i do an admin who_is_down this database is not on the list of REP AGENTS that are down (but i guarentee as soon as it times out it will be). Any ideas to keep these rep agents alive so the rep server doesn't report them as down? "Carel Cornelius" <carel@sybase.nospam.co.za> wrote in message news:4072449b_1@sybmail.sybase.co.za...
Jill, You are probably running into the default limit of 50 threads allowed on RepServer, or your configured value is still too low for the number of threads required for all databases configured. You say that there are 29 databases configured. Not sure if it's 29 DBs in total or 29 x WS pairs. That will be a minimum of at least all the "usual" Repserver threads (
about
8 ) + about 9 threads per standard WS connection: 2 x SQM (1 for each SQM - 1 inbound, 1 outbound ) 2 x DSI ( one per physical - depends on num DSI threads for parallel DSI ) 2 x DSI EXEC ( one per DSI thread - depends on num DSI threads ) 1 for each DIST 1 for each SQT 1 for each RepAgent You need to increase 'num_threads' config parameter for RepServer to allow for all of these threads. Also look at "num_msgqueues" and "num_mutexes" parameters, which should be higher than "num_threads" config parameter. Quick way to "thumb-suck" this value is to isql into RepServer and execute "admin who". Count number of rows returned and add a couple 20-30 or so
for
future reference. Use this for 'num_threads' config value. There are 2 ways to config RepServer : 1) isql into RepServer and execute: configure replication server set 'num_threads' to '280' go configure replication server set 'num_mutexes' to '350' go configure replication server set 'num_msgqueues' to '350' go 2) isql into the RSSD database and execute: rs_configure 'num_threads', '280' go rs_configure 'num_mutexes', '350' go rs_configure 'num_msgqueues', '350' go Restart RepServer which will now allow more than the 50 (or whatever) threads. Also remember to allow for the total memory that will be used by all the caches for all the DSI threads . . . Regards Carel


Greg Carter Posted on 2004-04-12 17:43:08.0Z
Message-ID: <407AC718.7070908@workmail.com>
From: Greg Carter <greg.carter@workmail.com>
Reply-To: greg.carter@workmail.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
Newsgroups: sybase.public.rep-agent
To: Jill G <jill@ici.org>
Subject: Re: rep agents down
References: <406c62fa$1@forums-2-dub> <4072449b_1@sybmail.sybase.co.za> <40759c66$1@forums-2-dub>
In-Reply-To: <40759c66$1@forums-2-dub>
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: vpn-dub-043.sybase.com
X-Original-NNTP-Posting-Host: vpn-dub-043.sybase.com
Date: 12 Apr 2004 09:43:08 -0800
X-Trace: forums-1-dub 1081788188 10.22.120.43 (12 Apr 2004 09:43:08 -0800)
X-Original-Trace: 12 Apr 2004 09:43:08 -0800, vpn-dub-043.sybase.com
Lines: 147
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.rep-agent:665
Article PK: 862316

Jill,

Unless there are changes that will force the RepAgent to send something to RepServer, then following a reboot of RepServer, RepServer will think that the RepAgent has not connected. My guess is that since these databases are rarely updated with replicated changes, then when RepServer is re-booted (for what ever reason) it reports these RepAgent as down (or "not connected" would be better) until a changes is mode that forces the RepAgent to re-cycle their connections.

-- Thanks, G.Carter Sybase Replication Server Engineering mailto:greg.carter@workmail.com


Jill G wrote:

Carel, Many thanks for your help. I upped the values to the following and rebooted the replication server. The following are the current values. After I rebooted the server, all the rep agents came up, however, again, the REP AGENTS for the same 15 inactive databases now report as being down. This happened at roughly the same time that the pix timed out my terminal session for inactivity to the machine hosting the rep server. There are no messages in the rep server error log regarding these agents, the replicate ASE server (housing the RSSD), nor the primary error log. Config Name Config Value Run Value -------------------------- ---------------------- ------------------------- - num_threads 450 450 num_mutexes 520 520 num_msgqueues 520 520 I went into one of these databases and made a change to see what would happen. What happens is that even though the rep server says the REP AGENT is down it isn't really down. The rep agent definitely detected the change. The following line was found in the rep server error log: I. 2004/04/08 14:39:03. Replication Agent for ICI_PRIMARY.ici_info connected in passthru mode. (ici_info being the database in which i made the change). Now, when i do an admin who_is_down this database is not on the list of REP AGENTS that are down (but i guarentee as soon as it times out it will be). Any ideas to keep these rep agents alive so the rep server doesn't report them as down? "Carel Cornelius" <carel@sybase.nospam.co.za> wrote in message news:4072449b_1@sybmail.sybase.co.za...
Jill, You are probably running into the default limit of 50 threads allowed on RepServer, or your configured value is still too low for the number of threads required for all databases configured. You say that there are 29 databases configured. Not sure if it's 29 DBs in total or 29 x WS pairs. That will be a minimum of at least all the "usual" Repserver threads (
about
8 ) + about 9 threads per standard WS connection: 2 x SQM (1 for each SQM - 1 inbound, 1 outbound ) 2 x DSI ( one per physical - depends on num DSI threads for parallel DSI ) 2 x DSI EXEC ( one per DSI thread - depends on num DSI threads ) 1 for each DIST 1 for each SQT 1 for each RepAgent You need to increase 'num_threads' config parameter for RepServer to allow for all of these threads. Also look at "num_msgqueues" and "num_mutexes" parameters, which should be higher than "num_threads" config parameter. Quick way to "thumb-suck" this value is to isql into RepServer and execute "admin who". Count number of rows returned and add a couple 20-30 or so
for
future reference. Use this for 'num_threads' config value. There are 2 ways to config RepServer : 1) isql into RepServer and execute: configure replication server set 'num_threads' to '280' go configure replication server set 'num_mutexes' to '350' go configure replication server set 'num_msgqueues' to '350' go 2) isql into the RSSD database and execute: rs_configure 'num_threads', '280' go rs_configure 'num_mutexes', '350' go rs_configure 'num_msgqueues', '350' go Restart RepServer which will now allow more than the 50 (or whatever) threads. Also remember to allow for the total memory that will be used by all the caches for all the DSI threads . . . Regards Carel


Greg Carter Posted on 2004-04-12 18:19:52.0Z
Message-ID: <407ACFB4.9060909@workmail.com>
From: Greg Carter <greg.carter@workmail.com>
Reply-To: greg.carter@workmail.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
Newsgroups: sybase.public.rep-agent
To: Jill G <jill@ici.org>
Subject: Re: rep agents down
References: <406c62fa$1@forums-2-dub> <4072449b_1@sybmail.sybase.co.za> <40759c66$1@forums-2-dub>
In-Reply-To: <40759c66$1@forums-2-dub>
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: vpn-dub-043.sybase.com
X-Original-NNTP-Posting-Host: vpn-dub-043.sybase.com
Date: 12 Apr 2004 10:19:52 -0800
X-Trace: forums-1-dub 1081790392 10.22.120.43 (12 Apr 2004 10:19:52 -0800)
X-Original-Trace: 12 Apr 2004 10:19:52 -0800, vpn-dub-043.sybase.com
Lines: 147
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.rep-agent:667
Article PK: 862317

Jill,

Unless there are changes that will force the RepAgent to send something to RepServer, then following a reboot of RepServer, RepServer will think that the RepAgent has not connected. My guess is that since these databases are rarely updated with replicated changes, then when RepServer is re-booted (for what ever reason) it reports these RepAgent as down (or "not connected" would be better) until a changes is mode that forces the RepAgent to re-cycle their connections.

-- Thanks, G.Carter Sybase Replication Server Engineering mailto:greg.carter@workmail.com


Jill G wrote:

Carel, Many thanks for your help. I upped the values to the following and rebooted the replication server. The following are the current values. After I rebooted the server, all the rep agents came up, however, again, the REP AGENTS for the same 15 inactive databases now report as being down. This happened at roughly the same time that the pix timed out my terminal session for inactivity to the machine hosting the rep server. There are no messages in the rep server error log regarding these agents, the replicate ASE server (housing the RSSD), nor the primary error log. Config Name Config Value Run Value -------------------------- ---------------------- ------------------------- - num_threads 450 450 num_mutexes 520 520 num_msgqueues 520 520 I went into one of these databases and made a change to see what would happen. What happens is that even though the rep server says the REP AGENT is down it isn't really down. The rep agent definitely detected the change. The following line was found in the rep server error log: I. 2004/04/08 14:39:03. Replication Agent for ICI_PRIMARY.ici_info connected in passthru mode. (ici_info being the database in which i made the change). Now, when i do an admin who_is_down this database is not on the list of REP AGENTS that are down (but i guarentee as soon as it times out it will be). Any ideas to keep these rep agents alive so the rep server doesn't report them as down? "Carel Cornelius" <carel@sybase.nospam.co.za> wrote in message news:4072449b_1@sybmail.sybase.co.za...
Jill, You are probably running into the default limit of 50 threads allowed on RepServer, or your configured value is still too low for the number of threads required for all databases configured. You say that there are 29 databases configured. Not sure if it's 29 DBs in total or 29 x WS pairs. That will be a minimum of at least all the "usual" Repserver threads (
about
8 ) + about 9 threads per standard WS connection: 2 x SQM (1 for each SQM - 1 inbound, 1 outbound ) 2 x DSI ( one per physical - depends on num DSI threads for parallel DSI ) 2 x DSI EXEC ( one per DSI thread - depends on num DSI threads ) 1 for each DIST 1 for each SQT 1 for each RepAgent You need to increase 'num_threads' config parameter for RepServer to allow for all of these threads. Also look at "num_msgqueues" and "num_mutexes" parameters, which should be higher than "num_threads" config parameter. Quick way to "thumb-suck" this value is to isql into RepServer and execute "admin who". Count number of rows returned and add a couple 20-30 or so
for
future reference. Use this for 'num_threads' config value. There are 2 ways to config RepServer : 1) isql into RepServer and execute: configure replication server set 'num_threads' to '280' go configure replication server set 'num_mutexes' to '350' go configure replication server set 'num_msgqueues' to '350' go 2) isql into the RSSD database and execute: rs_configure 'num_threads', '280' go rs_configure 'num_mutexes', '350' go rs_configure 'num_msgqueues', '350' go Restart RepServer which will now allow more than the 50 (or whatever) threads. Also remember to allow for the total memory that will be used by all the caches for all the DSI threads . . . Regards Carel


Greg Carter Posted on 2004-04-12 17:44:06.0Z
Message-ID: <407AC753.5010705@workmail.com>
From: Greg Carter <greg.carter@workmail.com>
Reply-To: greg.carter@workmail.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
Newsgroups: sybase.public.rep-agent
To: Jill G <jill@ici.org>
Subject: Re: rep agents down
References: <406c62fa$1@forums-2-dub> <4072449b_1@sybmail.sybase.co.za> <40759c66$1@forums-2-dub>
In-Reply-To: <40759c66$1@forums-2-dub>
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: vpn-dub-043.sybase.com
X-Original-NNTP-Posting-Host: vpn-dub-043.sybase.com
Date: 12 Apr 2004 09:44:06 -0800
X-Trace: forums-1-dub 1081788246 10.22.120.43 (12 Apr 2004 09:44:06 -0800)
X-Original-Trace: 12 Apr 2004 09:44:06 -0800, vpn-dub-043.sybase.com
Lines: 147
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.rep-agent:666
Article PK: 862318

Jill,

Unless there are changes that will force the RepAgent to send something to RepServer, then following a reboot of RepServer, RepServer will think that the RepAgent has not connected. My guess is that since these databases are rarely updated with replicated changes, then when RepServer is re-booted (for what ever reason) it reports these RepAgent as down (or "not connected" would be better) until a changes is mode that forces the RepAgent to re-cycle their connections.

-- Thanks, G.Carter Sybase Replication Server Engineering mailto:greg.carter@workmail.com


Jill G wrote:

Carel, Many thanks for your help. I upped the values to the following and rebooted the replication server. The following are the current values. After I rebooted the server, all the rep agents came up, however, again, the REP AGENTS for the same 15 inactive databases now report as being down. This happened at roughly the same time that the pix timed out my terminal session for inactivity to the machine hosting the rep server. There are no messages in the rep server error log regarding these agents, the replicate ASE server (housing the RSSD), nor the primary error log. Config Name Config Value Run Value -------------------------- ---------------------- ------------------------- - num_threads 450 450 num_mutexes 520 520 num_msgqueues 520 520 I went into one of these databases and made a change to see what would happen. What happens is that even though the rep server says the REP AGENT is down it isn't really down. The rep agent definitely detected the change. The following line was found in the rep server error log: I. 2004/04/08 14:39:03. Replication Agent for ICI_PRIMARY.ici_info connected in passthru mode. (ici_info being the database in which i made the change). Now, when i do an admin who_is_down this database is not on the list of REP AGENTS that are down (but i guarentee as soon as it times out it will be). Any ideas to keep these rep agents alive so the rep server doesn't report them as down? "Carel Cornelius" <carel@sybase.nospam.co.za> wrote in message news:4072449b_1@sybmail.sybase.co.za...
Jill, You are probably running into the default limit of 50 threads allowed on RepServer, or your configured value is still too low for the number of threads required for all databases configured. You say that there are 29 databases configured. Not sure if it's 29 DBs in total or 29 x WS pairs. That will be a minimum of at least all the "usual" Repserver threads (
about
8 ) + about 9 threads per standard WS connection: 2 x SQM (1 for each SQM - 1 inbound, 1 outbound ) 2 x DSI ( one per physical - depends on num DSI threads for parallel DSI ) 2 x DSI EXEC ( one per DSI thread - depends on num DSI threads ) 1 for each DIST 1 for each SQT 1 for each RepAgent You need to increase 'num_threads' config parameter for RepServer to allow for all of these threads. Also look at "num_msgqueues" and "num_mutexes" parameters, which should be higher than "num_threads" config parameter. Quick way to "thumb-suck" this value is to isql into RepServer and execute "admin who". Count number of rows returned and add a couple 20-30 or so
for
future reference. Use this for 'num_threads' config value. There are 2 ways to config RepServer : 1) isql into RepServer and execute: configure replication server set 'num_threads' to '280' go configure replication server set 'num_mutexes' to '350' go configure replication server set 'num_msgqueues' to '350' go 2) isql into the RSSD database and execute: rs_configure 'num_threads', '280' go rs_configure 'num_mutexes', '350' go rs_configure 'num_msgqueues', '350' go Restart RepServer which will now allow more than the 50 (or whatever) threads. Also remember to allow for the total memory that will be used by all the caches for all the DSI threads . . . Regards Carel


Greg Carter Posted on 2004-04-12 20:05:21.0Z
Message-ID: <407AE86D.7020107@workmail.com>
From: Greg Carter <greg.carter@workmail.com>
Reply-To: greg.carter@workmail.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
Newsgroups: sybase.public.rep-agent
To: Jill G <jill@ici.org>
Subject: Re: rep agents down
References: <406c62fa$1@forums-2-dub> <4072449b_1@sybmail.sybase.co.za> <40759c66$1@forums-2-dub>
In-Reply-To: <40759c66$1@forums-2-dub>
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: vpn-dub-043.sybase.com
X-Original-NNTP-Posting-Host: vpn-dub-043.sybase.com
Date: 12 Apr 2004 12:05:21 -0800
X-Trace: forums-1-dub 1081796721 10.22.120.43 (12 Apr 2004 12:05:21 -0800)
X-Original-Trace: 12 Apr 2004 12:05:21 -0800, vpn-dub-043.sybase.com
Lines: 147
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.rep-agent:668
Article PK: 862319

Jill,

Unless there are changes that will force the RepAgent to send something to RepServer, then following a reboot of RepServer, RepServer will think that the RepAgent has not connected. My guess is that since these databases are rarely updated with replicated changes, then when RepServer is re-booted (for what ever reason) it reports these RepAgent as down (or "not connected" would be better) until a changes is mode that forces the RepAgent to re-cycle their connections.

-- Thanks, G.Carter Sybase Replication Server Engineering mailto:greg.carter@workmail.com


Jill G wrote:

Carel, Many thanks for your help. I upped the values to the following and rebooted the replication server. The following are the current values. After I rebooted the server, all the rep agents came up, however, again, the REP AGENTS for the same 15 inactive databases now report as being down. This happened at roughly the same time that the pix timed out my terminal session for inactivity to the machine hosting the rep server. There are no messages in the rep server error log regarding these agents, the replicate ASE server (housing the RSSD), nor the primary error log. Config Name Config Value Run Value -------------------------- ---------------------- ------------------------- - num_threads 450 450 num_mutexes 520 520 num_msgqueues 520 520 I went into one of these databases and made a change to see what would happen. What happens is that even though the rep server says the REP AGENT is down it isn't really down. The rep agent definitely detected the change. The following line was found in the rep server error log: I. 2004/04/08 14:39:03. Replication Agent for ICI_PRIMARY.ici_info connected in passthru mode. (ici_info being the database in which i made the change). Now, when i do an admin who_is_down this database is not on the list of REP AGENTS that are down (but i guarentee as soon as it times out it will be). Any ideas to keep these rep agents alive so the rep server doesn't report them as down? "Carel Cornelius" <carel@sybase.nospam.co.za> wrote in message news:4072449b_1@sybmail.sybase.co.za...
Jill, You are probably running into the default limit of 50 threads allowed on RepServer, or your configured value is still too low for the number of threads required for all databases configured. You say that there are 29 databases configured. Not sure if it's 29 DBs in total or 29 x WS pairs. That will be a minimum of at least all the "usual" Repserver threads (
about
8 ) + about 9 threads per standard WS connection: 2 x SQM (1 for each SQM - 1 inbound, 1 outbound ) 2 x DSI ( one per physical - depends on num DSI threads for parallel DSI ) 2 x DSI EXEC ( one per DSI thread - depends on num DSI threads ) 1 for each DIST 1 for each SQT 1 for each RepAgent You need to increase 'num_threads' config parameter for RepServer to allow for all of these threads. Also look at "num_msgqueues" and "num_mutexes" parameters, which should be higher than "num_threads" config parameter. Quick way to "thumb-suck" this value is to isql into RepServer and execute "admin who". Count number of rows returned and add a couple 20-30 or so
for
future reference. Use this for 'num_threads' config value. There are 2 ways to config RepServer : 1) isql into RepServer and execute: configure replication server set 'num_threads' to '280' go configure replication server set 'num_mutexes' to '350' go configure replication server set 'num_msgqueues' to '350' go 2) isql into the RSSD database and execute: rs_configure 'num_threads', '280' go rs_configure 'num_mutexes', '350' go rs_configure 'num_msgqueues', '350' go Restart RepServer which will now allow more than the 50 (or whatever) threads. Also remember to allow for the total memory that will be used by all the caches for all the DSI threads . . . Regards Carel


Greg Carter Posted on 2004-04-12 20:07:24.0Z
Message-ID: <407AE8E8.1060405@workmail.com>
From: Greg Carter <greg.carter@workmail.com>
Reply-To: greg.carter@workmail.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
Newsgroups: sybase.public.rep-agent
To: Jill G <jill@ici.org>
Subject: Re: rep agents down
References: <406c62fa$1@forums-2-dub> <4072449b_1@sybmail.sybase.co.za> <40759c66$1@forums-2-dub>
In-Reply-To: <40759c66$1@forums-2-dub>
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: vpn-dub-043.sybase.com
X-Original-NNTP-Posting-Host: vpn-dub-043.sybase.com
Date: 12 Apr 2004 12:07:24 -0800
X-Trace: forums-1-dub 1081796844 10.22.120.43 (12 Apr 2004 12:07:24 -0800)
X-Original-Trace: 12 Apr 2004 12:07:24 -0800, vpn-dub-043.sybase.com
Lines: 147
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.rep-agent:669
Article PK: 862320

Jill,

Unless there are changes that will force the RepAgent to send something to RepServer, then following a reboot of RepServer, RepServer will think that the RepAgent has not connected. My guess is that since these databases are rarely updated with replicated changes, then when RepServer is re-booted (for what ever reason) it reports these RepAgent as down (or "not connected" would be better) until a changes is mode that forces the RepAgent to re-cycle their connections.

-- Thanks, G.Carter Sybase Replication Server Engineering mailto:greg.carter@workmail.com


Jill G wrote:

Carel, Many thanks for your help. I upped the values to the following and rebooted the replication server. The following are the current values. After I rebooted the server, all the rep agents came up, however, again, the REP AGENTS for the same 15 inactive databases now report as being down. This happened at roughly the same time that the pix timed out my terminal session for inactivity to the machine hosting the rep server. There are no messages in the rep server error log regarding these agents, the replicate ASE server (housing the RSSD), nor the primary error log. Config Name Config Value Run Value -------------------------- ---------------------- ------------------------- - num_threads 450 450 num_mutexes 520 520 num_msgqueues 520 520 I went into one of these databases and made a change to see what would happen. What happens is that even though the rep server says the REP AGENT is down it isn't really down. The rep agent definitely detected the change. The following line was found in the rep server error log: I. 2004/04/08 14:39:03. Replication Agent for ICI_PRIMARY.ici_info connected in passthru mode. (ici_info being the database in which i made the change). Now, when i do an admin who_is_down this database is not on the list of REP AGENTS that are down (but i guarentee as soon as it times out it will be). Any ideas to keep these rep agents alive so the rep server doesn't report them as down? "Carel Cornelius" <carel@sybase.nospam.co.za> wrote in message news:4072449b_1@sybmail.sybase.co.za...
Jill, You are probably running into the default limit of 50 threads allowed on RepServer, or your configured value is still too low for the number of threads required for all databases configured. You say that there are 29 databases configured. Not sure if it's 29 DBs in total or 29 x WS pairs. That will be a minimum of at least all the "usual" Repserver threads (
about
8 ) + about 9 threads per standard WS connection: 2 x SQM (1 for each SQM - 1 inbound, 1 outbound ) 2 x DSI ( one per physical - depends on num DSI threads for parallel DSI ) 2 x DSI EXEC ( one per DSI thread - depends on num DSI threads ) 1 for each DIST 1 for each SQT 1 for each RepAgent You need to increase 'num_threads' config parameter for RepServer to allow for all of these threads. Also look at "num_msgqueues" and "num_mutexes" parameters, which should be higher than "num_threads" config parameter. Quick way to "thumb-suck" this value is to isql into RepServer and execute "admin who". Count number of rows returned and add a couple 20-30 or so
for
future reference. Use this for 'num_threads' config value. There are 2 ways to config RepServer : 1) isql into RepServer and execute: configure replication server set 'num_threads' to '280' go configure replication server set 'num_mutexes' to '350' go configure replication server set 'num_msgqueues' to '350' go 2) isql into the RSSD database and execute: rs_configure 'num_threads', '280' go rs_configure 'num_mutexes', '350' go rs_configure 'num_msgqueues', '350' go Restart RepServer which will now allow more than the 50 (or whatever) threads. Also remember to allow for the total memory that will be used by all the caches for all the DSI threads . . . Regards Carel


Greg Carter Posted on 2004-04-12 20:08:38.0Z
Message-ID: <407AE932.3050003@workmail.com>
From: Greg Carter <greg.carter@workmail.com>
Reply-To: greg.carter@workmail.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
Newsgroups: sybase.public.rep-agent
To: Jill G <jill@ici.org>
Subject: Re: rep agents down
References: <406c62fa$1@forums-2-dub> <4072449b_1@sybmail.sybase.co.za> <40759c66$1@forums-2-dub>
In-Reply-To: <40759c66$1@forums-2-dub>
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: vpn-dub-043.sybase.com
X-Original-NNTP-Posting-Host: vpn-dub-043.sybase.com
Date: 12 Apr 2004 12:08:38 -0800
X-Trace: forums-1-dub 1081796918 10.22.120.43 (12 Apr 2004 12:08:38 -0800)
X-Original-Trace: 12 Apr 2004 12:08:38 -0800, vpn-dub-043.sybase.com
Lines: 147
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.rep-agent:670
Article PK: 862321

Jill,

Unless there are changes that will force the RepAgent to send something to RepServer, then following a reboot of RepServer, RepServer will think that the RepAgent has not connected. My guess is that since these databases are rarely updated with replicated changes, then when RepServer is re-booted (for what ever reason) it reports these RepAgent as down (or "not connected" would be better) until a changes is mode that forces the RepAgent to re-cycle their connections.

-- Thanks, G.Carter Sybase Replication Server Engineering mailto:greg.carter@workmail.com


Jill G wrote:

Carel, Many thanks for your help. I upped the values to the following and rebooted the replication server. The following are the current values. After I rebooted the server, all the rep agents came up, however, again, the REP AGENTS for the same 15 inactive databases now report as being down. This happened at roughly the same time that the pix timed out my terminal session for inactivity to the machine hosting the rep server. There are no messages in the rep server error log regarding these agents, the replicate ASE server (housing the RSSD), nor the primary error log. Config Name Config Value Run Value -------------------------- ---------------------- ------------------------- - num_threads 450 450 num_mutexes 520 520 num_msgqueues 520 520 I went into one of these databases and made a change to see what would happen. What happens is that even though the rep server says the REP AGENT is down it isn't really down. The rep agent definitely detected the change. The following line was found in the rep server error log: I. 2004/04/08 14:39:03. Replication Agent for ICI_PRIMARY.ici_info connected in passthru mode. (ici_info being the database in which i made the change). Now, when i do an admin who_is_down this database is not on the list of REP AGENTS that are down (but i guarentee as soon as it times out it will be). Any ideas to keep these rep agents alive so the rep server doesn't report them as down? "Carel Cornelius" <carel@sybase.nospam.co.za> wrote in message news:4072449b_1@sybmail.sybase.co.za...
Jill, You are probably running into the default limit of 50 threads allowed on RepServer, or your configured value is still too low for the number of threads required for all databases configured. You say that there are 29 databases configured. Not sure if it's 29 DBs in total or 29 x WS pairs. That will be a minimum of at least all the "usual" Repserver threads (
about
8 ) + about 9 threads per standard WS connection: 2 x SQM (1 for each SQM - 1 inbound, 1 outbound ) 2 x DSI ( one per physical - depends on num DSI threads for parallel DSI ) 2 x DSI EXEC ( one per DSI thread - depends on num DSI threads ) 1 for each DIST 1 for each SQT 1 for each RepAgent You need to increase 'num_threads' config parameter for RepServer to allow for all of these threads. Also look at "num_msgqueues" and "num_mutexes" parameters, which should be higher than "num_threads" config parameter. Quick way to "thumb-suck" this value is to isql into RepServer and execute "admin who". Count number of rows returned and add a couple 20-30 or so
for
future reference. Use this for 'num_threads' config value. There are 2 ways to config RepServer : 1) isql into RepServer and execute: configure replication server set 'num_threads' to '280' go configure replication server set 'num_mutexes' to '350' go configure replication server set 'num_msgqueues' to '350' go 2) isql into the RSSD database and execute: rs_configure 'num_threads', '280' go rs_configure 'num_mutexes', '350' go rs_configure 'num_msgqueues', '350' go Restart RepServer which will now allow more than the 50 (or whatever) threads. Also remember to allow for the total memory that will be used by all the caches for all the DSI threads . . . Regards Carel


Carel Cornelius Posted on 2004-04-15 19:57:46.0Z
From: "Carel Cornelius" <carel@sybase.nospam.co.za>
Newsgroups: sybase.public.rep-agent
References: <406c62fa$1@forums-2-dub> <4072449b_1@sybmail.sybase.co.za> <40759c66$1@forums-2-dub>
Subject: Re: rep agents down
Lines: 45
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Message-ID: <407f5b5f$1_2@sybmail.sybase.co.za>
X-Original-NNTP-Posting-Host: 127.0.0.1
X-Original-NNTP-Posting-Host: 158.76.48.248
X-Original-Trace: 15 Apr 2004 11:57:40 -0800, 158.76.48.248
X-Original-NNTP-Posting-Host: forums-2-dub.sybase.com
X-Original-Trace: 15 Apr 2004 11:57:43 -0800, forums-2-dub.sybase.com
NNTP-Posting-Host: forums-master.sybase.com
X-Original-NNTP-Posting-Host: forums-master.sybase.com
Date: 15 Apr 2004 11:57:46 -0800
X-Trace: forums-1-dub 1082055466 10.22.108.75 (15 Apr 2004 11:57:46 -0800)
X-Original-Trace: 15 Apr 2004 11:57:46 -0800, forums-master.sybase.com
X-Authenticated-User: ngsysop
Path: forums-1-dub!sybmail.sybase.co.za
Xref: forums-1-dub sybase.public.rep-agent:674
Article PK: 862325

Jill,

Just another totally different thought on this: Do a "ulimit -a" in the
session where RepServer is normally started from. It should report something
similar to this:

> ulimit -a
time(seconds) unlimited
file(blocks) unlimited
data(kbytes) 2097148
stack(kbytes) 8192
coredump(blocks) unlimited
nofiles(descriptors) 64
vmemory(kbytes) unlimited

If nofiles(descriptors) indicates a "soft" limit of 32 or 64, this could
very well be your problem. Unix uses one file descriptor for each open
TCP/IP connection and file. If the per session limit or "soft" limit does
not cater for enough open file descriptors to accept new incoming
connections, the RepAgents will also not be able to connect, especially
after all of the DSI threads have already attempted to connect or have
connected to the respective data servers.

I would normally expect an error message from RepServer in this regard, but
cannot remember that I have ever seen this with RepServer. I know for a fact
that ASE will complain about it when a client attempts to connect and there
are not enough file handles available. This will be reflected in the ASE
errorlog, but not sent to the client as the TCP connection cannot be
established.
Please check if you can see any messages to this effect - or similar in
nature - in the RepServer errorlog.

You may also want to verify in your ASE config or "session" that this is not
a problem that could be prohibiting the RepAgents from attempting to connect
to RepServer. Each open file and device will use one descriptor, as well as
each remote server connection and each incoming client connection. If the
RepAgent cannot connect due to an insufficient amount of file descriptors,
this should also be reflected in the ASE errorlog. If this is the case, you
may also experience some client disconnects from your ASE Server/s.

Regards

Carel


Jill G Posted on 2004-04-20 18:19:42.0Z
From: "Jill G" <jill@ici.org>
Newsgroups: sybase.public.rep-agent
References: <406c62fa$1@forums-2-dub> <4072449b_1@sybmail.sybase.co.za> <40759c66$1@forums-2-dub> <407f5b5f$1_2@sybmail.sybase.co.za>
Subject: Re: rep agents down
Lines: 66
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
NNTP-Posting-Host: client55.ici.org
X-Original-NNTP-Posting-Host: client55.ici.org
Message-ID: <408569be$1@forums-1-dub>
Date: 20 Apr 2004 11:19:42 -0700
X-Trace: forums-1-dub 1082485182 198.6.202.55 (20 Apr 2004 11:19:42 -0700)
X-Original-Trace: 20 Apr 2004 11:19:42 -0700, client55.ici.org
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.rep-agent:678
Article PK: 862327

many thanks. (our nofiles(descriptors)= 256 )

the problem is definitely a timeout issue do to the pix configuration. i've
added a table to each database called rs_updstat and put in a single row
(key, date). a script will update this row in every database on a scheduled
basis to keep these connections alive.

thanks for everyone's help.

"Carel Cornelius" <carel@sybase.nospam.co.za> wrote in message
news:407f5b5f$1_2@sybmail.sybase.co.za...
> Jill,
>
> Just another totally different thought on this: Do a "ulimit -a" in the
> session where RepServer is normally started from. It should report
something
> similar to this:
>
> > ulimit -a
> time(seconds) unlimited
> file(blocks) unlimited
> data(kbytes) 2097148
> stack(kbytes) 8192
> coredump(blocks) unlimited
> nofiles(descriptors) 64
> vmemory(kbytes) unlimited
>
> If nofiles(descriptors) indicates a "soft" limit of 32 or 64, this could
> very well be your problem. Unix uses one file descriptor for each open
> TCP/IP connection and file. If the per session limit or "soft" limit does
> not cater for enough open file descriptors to accept new incoming
> connections, the RepAgents will also not be able to connect, especially
> after all of the DSI threads have already attempted to connect or have
> connected to the respective data servers.
>
> I would normally expect an error message from RepServer in this regard,
but
> cannot remember that I have ever seen this with RepServer. I know for a
fact
> that ASE will complain about it when a client attempts to connect and
there
> are not enough file handles available. This will be reflected in the ASE
> errorlog, but not sent to the client as the TCP connection cannot be
> established.
> Please check if you can see any messages to this effect - or similar in
> nature - in the RepServer errorlog.
>
> You may also want to verify in your ASE config or "session" that this is
not
> a problem that could be prohibiting the RepAgents from attempting to
connect
> to RepServer. Each open file and device will use one descriptor, as well
as
> each remote server connection and each incoming client connection. If the
> RepAgent cannot connect due to an insufficient amount of file descriptors,
> this should also be reflected in the ASE errorlog. If this is the case,
you
> may also experience some client disconnects from your ASE Server/s.
>
> Regards
>
> Carel
>
>