[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference orarep::nomahs::sql_services

Title:	SQL/Services Forum
Notice:	kits(3) ft info(7) QAR access (8) SPR access (10)
Moderator:	SQLSRV::MAVRIS

Created:	Thu Oct 13 1988
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	2214
Total number of notes:	8586

2140.0. "MAX server limit reached" by NLVMS3::ADRIEL () Tue Feb 11 1997 11:25

    Hi,
    
    SQL/Services V6.1-02/VAX
    Oracle Rdb V5.1-11.
    
    Customer has upgraded SQL/Services and since hits te problem described
    in #1977 of this conference.
    This means that he regular has to restart SQL/Services because
    max. execution (generic) server limit is reached.
    According to VMS SHOW SYSTEM and RMU/SHOW USER there not that many
    servers running. It appears that SQL/Services server housekeeping 
    isn't correct.
    SQLSRV$UTL reports show the non-existing server with status 'EXE ABORT'
    
    I read bugreport #350082 which mentions a fix in V7.0.
    Question: will there be V6.1 fix available ?
              Any workaround available, other then increasing MAX limit?
    
    thanks in advance,
    
    Adri van Driel

T.R Title User Personal
Name Date Lines

2140.1 Not planning a new ECO SQLSRV::MAVRIS Sue Mavris - [email protected] Wed Feb 12 1997 17:01 19

T.R	Title	User	Personal Name	Date	Lines
2140.1	Not planning a new ECO	SQLSRV::MAVRIS	Sue Mavris - [email protected]	`Wed Feb 12 1997 17:01`	19
	Hi, There were several windows that could cause this problem. We fixed all we knew about in V6.1-02. We have since identified one more problem (which may or may not be the last one). This remaining condition occurs when a client starts a long running request and aborts before the request is finished. In this case, when the executor is cleaned up, the process slot remains allocated in the comm server and the executor count is not decremented. We are not currently planning on releasing a new ECO for 6.1. The only workarounds are: - stop and restart sql/services on a regular basis (in a nightly batch job for example) - increase max (but this just means you'll run out of slots less frequently) - tell clients not to abort during long running queries (HA!) Sue

Hi,

There were several windows that could cause this problem.  We fixed all we 
knew about in V6.1-02.  We have since identified one more problem (which may 
or may not be the last one).

This remaining condition occurs when a client starts a long running request 
and aborts before the request is finished.  In this case, when the executor 
is cleaned up, the process slot remains allocated in the comm server and the 
executor count is not decremented.

We are not currently planning on releasing a new ECO for 6.1.  The only 
workarounds are:
    - stop and restart sql/services on a regular basis (in a nightly batch 
      job for example)
    - increase max (but this just means you'll run out of slots less frequently)
    - tell clients not to abort during long running queries (HA!)
    
Sue