Title: | ObjectBroker - BEA Systems' CORBA |
Notice: | See note 3 for kits; note 5 for training; note 1134 for releases |
Moderator: | TLE::PARODI d |
Created: | Tue Jul 11 1989 |
Last Modified: | Thu Jun 05 1997 |
Last Successful Update: | Fri Jun 06 1997 |
Number of topics: | 1413 |
Total number of notes: | 6391 |
VMS V6.1 DECedi V2.1c I have a customer that has a problem with stuck documents that is currently being worked on by engineering. To workaround the stuck documents they have written a routine that goes through a track list (list of available docs) and makes sure that all documents can be fetched. The routines they have written are all in Cobol and a 'C' interface has been written so that they can communicate with DECedi V2.1c. Sometimes they receive the following errors in the DECedi Error log file: DECEDI-I-ORBSTATMSG, Object Broker satus message = %OBB-E-INV_NOTAUTHORIS, client user is not authorised to access server DECEDI-E-ORBERROR, An error was encountered calling the Object Broker routine CORBA_BOA_activate_obj, decedi condition logged DECEDI-I-ORBSTATMSG, %OBB-E-INV_SRVNOTREG, server is not registered. DECEDI-E-ORBERROR, An error was encountered calling the Object Broker routine OBB_BOA_DISPATCH decedi condition logged DECEDI-I-ORBSTATMSG, %OBB-E-INV_SRVNOTREG, server is not registered. DECEDI-E-ORBERROR, An error was encountered calling the Object Broker routine OBB_BOA_IMPL_UNREGISTER This then kills their API programs. They then stop DECedi. All the OBB_pid processes do not close down and so have to be deleted by hand. They then start DECedi up again and it all works again. This problem appears to occur when they have 60/70 docs being stuck at any one time. Could it be that the max no of server instances has been reached? He says that at any one time 2 or 4 copies of the server could be be going through their tests and hammering Object Broker. Also on separate occasions they see the following problem: %DECEDI-I-ORBSTATMSG, Object Broker status message= %OBB-E-COM_BADUUID, Bad UUID '<NIL>' failure OBB dispatch OBB_BOA_DISPATCH decedi condition logged Any ideas? Richard Simpson.
T.R | Title | User | Personal Name | Date | Lines |
---|---|---|---|---|---|
1395.1 | KERNEL::SIMPSONR | fred | Wed Apr 23 1997 05:48 | 51 | |
The problem is still with them even though the stuck documents problem has been resolved. I rang the customer and he said that the problem is still occurring. They get an extra error that now mentions deactivate instead of activate: DECEDI-I-ORBSTATMSG, Object Broker status message = %OBB-E-INV_NOTAUTHORIS, client user is not authorised to access server DECEDI-E-ORBERROR, An error was encountered calling the Object Broker routine CORBA_BOA_deactivate_obj, decedi condition logged Then he gets the following errors logged after the DECEDI$ERROR log errors in a file called DECEDI.ERR. This file is found in SYS$LOGIN of the detached server that is using Objectbroker. Module : DECEDI_API_FETCH , %OBB-E-BOA_OBJNOTACTIV, The Object Reference is Not Active. Module : DECEDI_API_FETCH , %ACAS-E-INV_HOSTNOTFND, A host node could not be found to execute the request. -ACAS-E-INV_NOTAUTHORIZ, CLient user is not authorized to access server. Module : DECEDI_API_TRACK , %ACAS-E-INV_HOSTNOTFND, A host node could not be found to execute the request. -ACAS-E-INV_NOTAUTHORIZ, CLient user is not authorized to access server. Module : DECEDI_API_FETCH , %ACAS-E-INV_HOSTNOTFND, A host node could not be found to execute the request. -ACAS-E-INV_NOTAUTHORIZ, CLient user is not authorized to access server. Module : DECEDI_API_TRACK , %ACAS-E-INV_HOSTNOTFND, A host node could not be found to execute the request. -ACAS-F-COM_INSUFVM, Insufficient Memory Module : DECEDI_API_TRACK , %ACAS-E-INV_HOSTNOTFND, A host node could not be found to execute the request. -ACAS-E-INV_DISCONN, The connection has been disconnected. -ACAS-E-INV_TRANSERR, Transport error 'broken pipe'. Module : DECEDI_API_TRACK , %ACAS-E-INV_HOSTNOTFND, A host node could not be found to execute the request. Module : DECEDI_API_FETCH , %ACAS-E-INV_HOSTNOTFND, A host node could not be found to execute the request. -ACAS-F-COM_INSUFVM, Insufficient Memory Please can someone have a look at this problem and provide some ideas as to what information is required to further this problem, Cheers, Richard. | |||||
1395.2 | METSYS::THOMPSON | Wed Apr 23 1997 14:07 | 7 | ||
One thing we have observed here is that Objectbroker Agent is is exhausting it's Pagefile quota. Any ideas what can cause the agent to leak so? M | |||||
1395.3 | What version of ObjectBroker? | RECV::VLATAS | WARNING: Do not swallow the battery door | Thu Apr 24 1997 07:56 | 15 |
What version of ObjectBroker is being used? There was a problem that was corrected for V2.6 where failed proxy lookups would cause a >1K per-invoke memory leak. The output in 1395.1 indicates that there are proxy lookup failures so this could be why you are running out of memory. This was QAR 2872. Note that invokes can appear to be working OK and you will still get this leak. For example: if you don't have a proxy setup for a specific host/user combination but do have one setup for a host/default combination, it will leak when the check for a specific host/user proxy is made and then it will match the host/default proxy. Tony | |||||
1395.4 | METSYS::THOMPSON | Thu Apr 24 1997 12:08 | 28 | ||
Hi, This is ObjectBroker V2.5A. OpenVMS VAX V6.x, TCP/IP transport. What we did was alter obb$startup.com to give the agent about 200,000 block Page File quota. Their test has about 5000 operations (fetches). When they ran the test they got a 'leak' of 30,000 blocks. They did a re-run of the same test and got a leak of 'only' 9000 blocks. So we passed their test but now that they are able to estimate the memory leak they realise they would have to re-start the Agent every day. This is not really acceptable, they estimate 10 days as a reasonable memory leak crash period. They are now using CORBA interfaces only. The DEC/EDI client and server processes do not appear to be leaking, only the agent. The Authorization problems are now resolved. So it does look as though those failures were caused by lack of memory. I don't know why the Agent leaks so badly for this customer. We can't upgrade to V2.7 as this release has problems when we register our interfaces. Mark | |||||
1395.5 | METSYS::THOMPSON | Thu Apr 24 1997 12:11 | 6 | ||
One last detail ... this is a single node system. All operations are launched from a single account. So I don't know why it's trying to authorize anyway. The proxy database is empty. Mark |