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.

"FORWARD TO" hangs

4 posts in General Discussion Last posting was on 2003-09-29 14:50:06.0Z
philb Posted on 2003-09-26 18:12:15.0Z
Sender: 40c4.3f748164.1804289383@sybase.com
From: philb
Newsgroups: ianywhere.public.general
Subject: "FORWARD TO" hangs
X-Mailer: WebNews to Mail Gateway v1.1s
Message-ID: <3f74817f.40ca.846930886@sybase.com>
NNTP-Posting-Host: 10.22.241.41
X-Original-NNTP-Posting-Host: 10.22.241.41
Date: 26 Sep 2003 11:12:15 -0700
X-Trace: forums-1-dub 1064599935 10.22.241.41 (26 Sep 2003 11:12:15 -0700)
X-Original-Trace: 26 Sep 2003 11:12:15 -0700, 10.22.241.41
Lines: 50
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub ianywhere.public.general:1807
Article PK: 17305

We have two SQlanywhere databases (7.0.4 3472 ebf).
We create a server DBRES in the 'master' db that points to
the 'results' db (create server dbres class 'asodb' using
'odbc_name_for_results_db').

OK, if we then "forward to DBRES { 'call psb1' }" and while
that procedure is running try to log into the master DB
(from say isql), the login works.

However, if we do a second concurrent forward to DBRES (from
say a different connection) to call some other procedure,
and THEN you try to log into the master DB (from say isql),
the login sits, eventually times out, and won't connect.

However, once either one of the two active calls completes
and returns, then the login works again. What, a single
entry stack?

Anyway, it acts like a second 'forward to' makes the whole
DB wait for something. It also seems that if that something
never happens (like maybe the remote procedure crashes or
something???), we have seen cases where the master db then
just proceeds to sit there forever. You cannot connect
sqlcentral or isql to examine/fix whatever.

A sample procedure that can demonstrate is this: it runs for
about 30 seconds in the remote db.
==== do theis on the remote side ====
create procedure psb1 ()
begin
declare @i int;
set @i = 0;
while @i < 30000 loop
message now(), ' the value of i is ', @i;
set @i = @i + 1;
end loop;
end

==== use this in the master side ====
execute immediate 'create server ' + 'fred' +
' class ' + '''' + 'asaodbc' + '''' +
' using ' + '''' + 'worldcat_server_results' + '''';

execute immediate 'forward to fred ' + ' { ' + 'call psb1'
+ ' } ' ;

execute immediate 'drop server fred';
======
do that in two separate isql sessions (use 'fred2' in the
second one) and then try to loginto a third...no go


Nick Elson Posted on 2003-09-26 20:07:52.0Z
From: "Nick Elson" <no_spam_nicelson@sybase.com>
Newsgroups: ianywhere.public.general
References: <3f74817f.40ca.846930886@sybase.com>
Subject: Re: "FORWARD TO" hangs
Lines: 75
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
X-Original-NNTP-Posting-Host: vpn-concord-170.sybase.com
Message-ID: <3f749d36$1@forums-2-dub>
X-Original-Trace: 26 Sep 2003 13:10:30 -0700, vpn-concord-170.sybase.com
X-Original-NNTP-Posting-Host: forums-2-dub.sybase.com
X-Original-Trace: 26 Sep 2003 13:03:27 -0700, forums-2-dub.sybase.com
NNTP-Posting-Host: forums-master.sybase.com
X-Original-NNTP-Posting-Host: forums-master.sybase.com
Date: 26 Sep 2003 13:07:52 -0700
X-Trace: forums-1-dub 1064606872 10.22.108.75 (26 Sep 2003 13:07:52 -0700)
X-Original-Trace: 26 Sep 2003 13:07:52 -0700, forums-master.sybase.com
X-Authenticated-User: ngsysop
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub ianywhere.public.general:1808
Article PK: 17314

If you using the 'Personal' server, you may have just
exceeded the number of connections (10).

Each 'forward to' represents 2 connections.
And you did say you also have another one
(so that makes 5 so far).

Sybase Central makes 7 ...

Any bets on what the other 3 are?


An alternate limitation could be -gn threads.


Oh and execute immediate has some extra overhead too ...


See if any of those suggestions help .... If you sure there is something
broken here feel free to submit a bug case.

<philb> wrote in message news:3f74817f.40ca.846930886@sybase.com...
> We have two SQlanywhere databases (7.0.4 3472 ebf).
> We create a server DBRES in the 'master' db that points to
> the 'results' db (create server dbres class 'asodb' using
> 'odbc_name_for_results_db').
>
> OK, if we then "forward to DBRES { 'call psb1' }" and while
> that procedure is running try to log into the master DB
> (from say isql), the login works.
>
> However, if we do a second concurrent forward to DBRES (from
> say a different connection) to call some other procedure,
> and THEN you try to log into the master DB (from say isql),
> the login sits, eventually times out, and won't connect.
>
> However, once either one of the two active calls completes
> and returns, then the login works again. What, a single
> entry stack?
>
> Anyway, it acts like a second 'forward to' makes the whole
> DB wait for something. It also seems that if that something
> never happens (like maybe the remote procedure crashes or
> something???), we have seen cases where the master db then
> just proceeds to sit there forever. You cannot connect
> sqlcentral or isql to examine/fix whatever.
>
> A sample procedure that can demonstrate is this: it runs for
> about 30 seconds in the remote db.
> ==== do theis on the remote side ====
> create procedure psb1 ()
> begin
> declare @i int;
> set @i = 0;
> while @i < 30000 loop
> message now(), ' the value of i is ', @i;
> set @i = @i + 1;
> end loop;
> end
>
> ==== use this in the master side ====
> execute immediate 'create server ' + 'fred' +
> ' class ' + '''' + 'asaodbc' + '''' +
> ' using ' + '''' + 'worldcat_server_results' + '''';
>
> execute immediate 'forward to fred ' + ' { ' + 'call psb1'
> + ' } ' ;
>
> execute immediate 'drop server fred';
> ======
> do that in two separate isql sessions (use 'fred2' in the
> second one) and then try to loginto a third...no go


philb Posted on 2003-09-26 21:47:00.0Z
Sender: 43a9.3f74af14.1804289383@sybase.com
From: philb
Newsgroups: ianywhere.public.general
Subject: Re: "FORWARD TO" hangs
X-Mailer: WebNews to Mail Gateway v1.1s
Message-ID: <3f74b3d4.442f.846930886@sybase.com>
References: <3f74817f.40ca.846930886@sybase.com><3f749d36$1@forums-2-dub>
NNTP-Posting-Host: 10.22.241.41
X-Original-NNTP-Posting-Host: 10.22.241.41
Date: 26 Sep 2003 14:47:00 -0700
X-Trace: forums-1-dub 1064612820 10.22.241.41 (26 Sep 2003 14:47:00 -0700)
X-Original-Trace: 26 Sep 2003 14:47:00 -0700, 10.22.241.41
Lines: 86
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub ianywhere.public.general:1809
Article PK: 17304

Well, thanks for the thought, but in our case we're on a
real server using dbeng7 with 100's of connections. And
it's not so much you can't connect: that's just the symptom.
The problem is the engine has stopped. No messages come
out to the console; background events do not fire; it just
plain stops. In at least one scenario it does not show up
under 'dblocate'. With just one forward to, seems oK. The
second one is the killer..

> If you using the 'Personal' server, you may have just
> exceeded the number of connections (10).
>
> Each 'forward to' represents 2 connections.
> And you did say you also have another one
> (so that makes 5 so far).
>
> Sybase Central makes 7 ...
>
> Any bets on what the other 3 are?
>
>
> An alternate limitation could be -gn threads.
>
>
> Oh and execute immediate has some extra overhead too ...
>
>
> See if any of those suggestions help .... If you sure
> there is something broken here feel free to submit a bug
> case.
>
>
> <philb> wrote in message
> > news:3f74817f.40ca.846930886@sybase.com... We have two
> > SQlanywhere databases (7.0.4 3472 ebf). We create a
> > server DBRES in the 'master' db that points to the
> > 'results' db (create server dbres class 'asodb' using
> 'odbc_name_for_results_db'). >
> > OK, if we then "forward to DBRES { 'call psb1' }" and
> > while that procedure is running try to log into the
> > master DB (from say isql), the login works.
> >
> > However, if we do a second concurrent forward to DBRES
> > (from say a different connection) to call some other
> > procedure, and THEN you try to log into the master DB
> > (from say isql), the login sits, eventually times out,
> and won't connect. >
> > However, once either one of the two active calls
> > completes and returns, then the login works again. What
> > , a single entry stack?
> >
> > Anyway, it acts like a second 'forward to' makes the
> > whole DB wait for something. It also seems that if that
> > something never happens (like maybe the remote procedure
> > crashes or something???), we have seen cases where the
> > master db then just proceeds to sit there forever. You
> > cannot connect sqlcentral or isql to examine/fix
> whatever. >
> > A sample procedure that can demonstrate is this: it runs
> > for about 30 seconds in the remote db.
> > ==== do theis on the remote side ====
> > create procedure psb1 ()
> > begin
> > declare @i int;
> > set @i = 0;
> > while @i < 30000 loop
> > message now(), ' the value of i is ', @i;
> > set @i = @i + 1;
> > end loop;
> > end
> >
> > ==== use this in the master side ====
> > execute immediate 'create server ' + 'fred' +
> > ' class ' + '''' + 'asaodbc' + '''' +
> > ' using ' + '''' + 'worldcat_server_results' + '''';
> >
> > execute immediate 'forward to fred ' + ' { ' + 'call
> > psb1' + ' } ' ;
> >
> > execute immediate 'drop server fred';
> > ======
> > do that in two separate isql sessions (use 'fred2' in
> > the second one) and then try to loginto a third...no go
>
>


Jason Hinsperger Posted on 2003-09-29 14:50:06.0Z
From: "Jason Hinsperger" <NOJason_HinspergerSPAM@hotmail.com>
Newsgroups: ianywhere.public.general
References: <3f74817f.40ca.846930886@sybase.com><3f749d36$1@forums-2-dub> <3f74b3d4.442f.846930886@sybase.com>
Subject: Re: "FORWARD TO" hangs
Lines: 108
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
NNTP-Posting-Host: hinsperg-pc1.sybase.com
X-Original-NNTP-Posting-Host: hinsperg-pc1.sybase.com
Message-ID: <3f78469e$1@forums-1-dub>
Date: 29 Sep 2003 07:50:06 -0700
X-Trace: forums-1-dub 1064847006 172.31.143.226 (29 Sep 2003 07:50:06 -0700)
X-Original-Trace: 29 Sep 2003 07:50:06 -0700, hinsperg-pc1.sybase.com
X-Authenticated-User: techsupp
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub ianywhere.public.general:1813
Article PK: 17409

Your remote procedure calls are tying up all of the OS threads that handle
database requests. You can use the -gx switch to increase the number of
threads available to service database requests. It should be set to one
more than the maximum number of long running remote data access requests you
expect to be active at any one time.

For details on threading in ASA, read the online doc. section "Threading in
Adaptive Server Anywhere"

--
Jason Hinsperger
International and Sustaining Engineering
iAnywhere Solutions

Whitepapers, TechDocs, and bug fixes are all available through the iAnywhere
Developer Community at www.ianywhere.com/developer
--

<philb> wrote in message news:3f74b3d4.442f.846930886@sybase.com...
> Well, thanks for the thought, but in our case we're on a
> real server using dbeng7 with 100's of connections. And
> it's not so much you can't connect: that's just the symptom.
> The problem is the engine has stopped. No messages come
> out to the console; background events do not fire; it just
> plain stops. In at least one scenario it does not show up
> under 'dblocate'. With just one forward to, seems oK. The
> second one is the killer..
>
>
> > If you using the 'Personal' server, you may have just
> > exceeded the number of connections (10).
> >
> > Each 'forward to' represents 2 connections.
> > And you did say you also have another one
> > (so that makes 5 so far).
> >
> > Sybase Central makes 7 ...
> >
> > Any bets on what the other 3 are?
> >
> >
> > An alternate limitation could be -gn threads.
> >
> >
> > Oh and execute immediate has some extra overhead too ...
> >
> >
> > See if any of those suggestions help .... If you sure
> > there is something broken here feel free to submit a bug
> > case.
> >
> >
> > <philb> wrote in message
> > > news:3f74817f.40ca.846930886@sybase.com... We have two
> > > SQlanywhere databases (7.0.4 3472 ebf). We create a
> > > server DBRES in the 'master' db that points to the
> > > 'results' db (create server dbres class 'asodb' using
> > 'odbc_name_for_results_db'). >
> > > OK, if we then "forward to DBRES { 'call psb1' }" and
> > > while that procedure is running try to log into the
> > > master DB (from say isql), the login works.
> > >
> > > However, if we do a second concurrent forward to DBRES
> > > (from say a different connection) to call some other
> > > procedure, and THEN you try to log into the master DB
> > > (from say isql), the login sits, eventually times out,
> > and won't connect. >
> > > However, once either one of the two active calls
> > > completes and returns, then the login works again. What
> > > , a single entry stack?
> > >
> > > Anyway, it acts like a second 'forward to' makes the
> > > whole DB wait for something. It also seems that if that
> > > something never happens (like maybe the remote procedure
> > > crashes or something???), we have seen cases where the
> > > master db then just proceeds to sit there forever. You
> > > cannot connect sqlcentral or isql to examine/fix
> > whatever. >
> > > A sample procedure that can demonstrate is this: it runs
> > > for about 30 seconds in the remote db.
> > > ==== do theis on the remote side ====
> > > create procedure psb1 ()
> > > begin
> > > declare @i int;
> > > set @i = 0;
> > > while @i < 30000 loop
> > > message now(), ' the value of i is ', @i;
> > > set @i = @i + 1;
> > > end loop;
> > > end
> > >
> > > ==== use this in the master side ====
> > > execute immediate 'create server ' + 'fred' +
> > > ' class ' + '''' + 'asaodbc' + '''' +
> > > ' using ' + '''' + 'worldcat_server_results' + '''';
> > >
> > > execute immediate 'forward to fred ' + ' { ' + 'call
> > > psb1' + ' } ' ;
> > >
> > > execute immediate 'drop server fred';
> > > ======
> > > do that in two separate isql sessions (use 'fred2' in
> > > the second one) and then try to loginto a third...no go
> >
> >