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

Conference pamsrc::objectbroker_development

Title:ObjectBroker Development - BEA Systems' CORBA
Notice:See note 2 for kit locations; note 4 for training
Moderator:RECV::GUMBELd
Created:Thu Dec 27 1990
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:2482
Total number of notes:13057

2437.0. "OBB_MGT_RIIterator_next_n failure" by STKAI1::T_ANDERSSON (Tomas Andersson) Mon Feb 17 1997 09:46

When using the OBB management API with a VAX/VMS server, a problem
seems to occur with the OBB_MGT_RIIterator_next_n function when
there are several hundreds of implementations running on the
server. The function then returns CORBA_UNKNOWN with the error
code OBB_INV_METHODFAIL. This does not occur with a smaller
number of implementations running.

We use OBB v2.6 with NT clients.

The source code for where the error occurs follows:


int CCONV ISTOBBMGM_CAgent_getFirstObjObjectServer(
  OBB_MGT_RIIterator             objAgentRII, 
  OBB_MGT_RIIterator_ImplInfoSeq *seqAgentRI,
  CORBA_string                   *out_objectServerName,
  CORBA_string                   *out_objectServerVersion,
  CORBA_string                   *out_WellKnownUUID,
  OBB_MGT_RunningImpl            *out_objRunningImpl,
  OBB_MGT_Process                *out_objProcess,
  OBB_MGT_RIIterator             *out_objProcessRII)
{
  CORBA_unsigned_long noOfImpls = 1000000;
  CORBA_Environment   ev;

  /* Reset the iterator to point to the first running impl. */
  OBB_MGT_RIIterator_reset(objAgentRII, &ev);
  if (ev._major!=CORBA_NO_EXCEPTION) {ReportException(&ev);
return(FALSE);}

  /* Get (all) implementations on the agent corresp to the specified RI
iterator */
  OBB_MGT_RIIterator_next_n(objAgentRII, &ev, noOfImpls, seqAgentRI);
  if (ev._major!=CORBA_NO_EXCEPTION) {ReportException(&ev);
return(FALSE);}

  /* Use the _maximum - field to mark the next item to get */
  seqAgentRI->_maximum = 0;

  /* Return the first running impl that represents an objectServer */
  if (!ISTOBBMGM_CAgent_getNextObjObjectServer(
    seqAgentRI, 
    out_objectServerName,
    out_objectServerVersion,
    out_WellKnownUUID,
    out_objRunningImpl, 
    out_objProcess,
    out_objProcessRII)) return(FALSE);
  
  return(TRUE);
}


What could be the cause of this problem?

- Tomas A -

T.RTitleUserPersonal
Name
DateLines
2437.1REQUE::BOWERPeter Bower, ObjectBrokerSun Feb 23 1997 10:2719
    
    I do not see anything in the code that might cause a bug with
    large numbers of server.
    
    Since you are asking for all the servers, it could be that 
    the agent is running out of memory creating the list to be
    returned. The agent returns a list containing all the information
    about each server. This could be quite large. Watch the agent process 
    with a show proc/con. When the call occurs does the virtual pages 
    approach the page file quota amount.
    
    You could try getting in chunks of 100 and see if it works. You
    could also try bumping up the pgflquo for the system account
    and see if it works.
    
    Does ReportException call OBB_exception_errortext ? If not,
    you might want to add it and see if the underlying errorlist
    contains more information.
    
2437.2STKAI1::T_ANDERSSONTomas AnderssonWed Mar 05 1997 06:28142
 According to your suggestions, we've tried getting chunks of 500
 implementations, and this workaround seems to work quite well.

 We think, but we are not sure, that the agent runs out of virtual memory
 on the VMS server. There are two results from OBB_exception_error: 

	*** 
	System exception encountered: CORBA_NO_MEMORY
	OBB_COM_INSUFVM (f), Insufficient memory. 
	***
	System exception encountered: CORBA_UNKNOWN
	OBB_INV_METHODFAIL (e), Method execution failed. 
	***

 When we do a SHOW PROC/ALL on the OBB$AGENT process, we find that
 Pgflquo is down to 0, i.e. we're out of virtual memory? However,
 we also find that the peak virtual size is 28782. Isn't that a
 contradiction? I'm not very good at VMS, unfortunately, but here
 is what we get from SHOW PROC: 

==========

$SHOW PROC/ALL OBB$AGENT

 4-MAR-1997 08:26:48.53   User: ADBMLA           Process ID:   22016E3F
                          Node: H3               Process name:
"OBB$AGENT"

Terminal:
User Identifier:    [ADBMLA]
Base priority:      8
Default file spec:  Not available

Devices allocated:  NET6400:
                    BG447:
                    BG1685:

Process Quotas:
 Account name:
 CPU limit:                      Infinite  Direct I/O limit:       100
 Buffered I/O byte count quota:     39760  Buffered I/O limit:     100
 Timer queue entry quota:              20  Open file quota:        195
 Paging file quota:                     0  Subprocess quota:         8
 Default page fault cluster:           64  AST quota:               96
 Enqueue quota:                      1987  Shared file limit:        0
 Max detached processes:                0  Max active jobs:         10

Accounting information:
 Buffered I/O count:     40544  Peak working set size:      19162
 Direct I/O count:       22758  Peak virtual size:          28782
 Page faults:            45778  Mounted volumes:                0
 Images activated:           0
 Elapsed CPU time:          0 00:03:54.97
 Connect time:              0 11:24:36.66
 
Authorized privileges:
 ACNT      ALLSPOOL  ALTPRI    AUDIT     BUGCHK    BYPASS    CMEXEC
CMKRNL
 DETACH    DIAGNOSE  DOWNGRADE EXQUOTA   GROUP     GRPNAM    GRPPRV
IMPORT
 LOG_IO    MOUNT     NETMBX    OPER      PFNMAP    PHY_IO    PRMCEB
PRMGBL
 PRMMBX    PSWAPM    READALL   SECURITY  SETPRV    SHARE     SHMEM
SYSGBL
 SYSLCK    SYSNAM    SYSPRV    TMPMBX    UPGRADE   VOLPRO    WORLD
 
Process privileges:
 ... 

Process rights:
 ...
 
System rights:
 SYS$NODE_H3
 
Auto-unshelve: on
 
Image Dump: off

There is 1 process in this job: 

  OBB$AGENT (*)

==========

 And here is an output showing what quotas the process can use:

==========

UAF> sh adbmla

Username: ADBMLA                           Owner:  1813
Account:                                   UIC:    [245,256] ([ADBMLA])
CLI:      DCL                              Tables: DCLTABLES
Default:  DBIS:[ADBMLA]
LGICMD:   DB_SYLOGIN:SYLOGIN
Flags:  DisCtlY DefCLI DisPwdDic
Primary days:   Mon Tue Wed Thu Fri
Secondary days:                     Sat Sun
Primary   000000000011111111112222  Secondary 000000000011111111112222
Day Hours 012345678901234567890123  Day Hours 012345678901234567890123
Network:  ##### Full access ######            ##### Full access ######
Batch:    ##### Full access ######            ##### Full access ######
Local:    ##### Full access ######            ##### Full access ######
Dialup:   -----  No access  ------            -----  No access  ------
Remote:   ##### Full access ######            ##### Full access ######
Expiration:            (none)    Pwdminimum:  8   Login Fails:     0
Pwdlifetime:       9999 00:00    Pwdchange:  30-AUG-1995 08:53 
Last Login:  4-MAR-1997 08:22 (interactive),  3-MAR-1997 00:30
(non-interactive)
Maxjobs:        10  Fillm:       200  Bytlm:       150000
Maxacctjobs:     0  Shrfillm:      0  Pbytlm:           0
Maxdetach:       0  BIOlm:       100  JTquota:       2048
Prclm:          10  DIOlm:        24  WSdef:          512
Prio:            4  ASTlm:        24  WSquo:         2048
Queprio:         0  TQElm:        10  WSextent:     32768
CPU:        (none)  Enqlm:      3000  Pgflquo:     150000

===========

 Why doesn't the agent release the memory again? Are there any
 known memory leaks when the server management routines are called,
 or does one have to make a specific call to make the server release
 the memory?

 I ask this because some rather serious problems occur when
 we run out of memory for the agent in a production system
 we're working with at the moment, as you can imagine.

 Anyway, when the agent is restarted, SHOW PROC /ALL for OBB$AGENT
 outputs:

	Paging file quota:                 21937
	Peak virtual size:           6845

 Thus, of the original 150000 pages (in Authorize), there are only
 21937 pages left??? Are we misinterpreting these figures, or what
 is going on?

 - Tomas A -

2437.3REQUE::BOWERPeter Bower, ObjectBrokerWed Mar 05 1997 11:346
    
    I believe there is a sysgen parameter that limits how much of
    pgflquo you can actually use. I seem to remember that it was
    virtualpagecnt. You might want to ask a VMS expert though
    as this might affect size of pagefiles, etc.
    
2437.4METSYS::THOMPSONWed Mar 05 1997 13:2127
> Anyway, when the agent is restarted, SHOW PROC /ALL for OBB$AGENT
 >outputs:

>	Paging file quota:                 21937
>	Peak virtual size:           6845

> Thus, of the original 150000 pages (in Authorize), there are only
> 21937 pages left??? Are we misinterpreting these figures, or what
> is going on?


Is this an Alpha? If so, you are probably getting confused by pages
and pagelets.

A pagelet is the traditional 512 byte page. When you specify PgFlQuo you
specify Pagelets. Most Alpha's seem to go with 16 Pagelets to the Page.
So a 150000 Pagelet quota will only give you up to 9375 pages. When
you run "show process/continuous" that shows Pages - it is usually
a much smaller number.

So 21937 Pagelets means you can only add another 1371 Pages to that
process. Conversly the 6845 Peak Vir Size is 109520 Pagelets. 

It still looks like the Agent is using up lots of memory though.

Mark