Conference pamsrc::objectbroker_development

Hi,

As a consequence of this problem we may need to inquire of the Agent what
it knows about the health of an Implementation Server instance.

For example if you issue the "show server" command it will display 
information like "process died". Is there a programatic interface that
will yield the same information?

A quick scan of my 1994 ObjectBroker Reference manual didn't suggest any
routines that may provide this information.

Thanks

Mark
 

Check the reference manual for documentation about 
ObjectBroker's management API.


Paul

The management API was just exactly what I asked for, alas I can't
quite make it do what I need it to do. 


We have an Object factory that doles out 1 out of a pool of pre-defined 
"Initial Object References". We have code that recycles these, apart from
when an Implementation Server crashes.  

The Mgt API seems to be able to easily tell me that a process has crashed, it
tells me it's one of my processes and will let me terminate them. 

What it doesn't seem to do is allow me to locate the "Initial Object Reference"
that was used to create it. How do you work back from RII to Initial Object?

Thanks

Mark
 

ObjectBroker does not track objects at this level.



Paul Patrick

While ObjectBroker does not track objects used, the server
applications you write can do that themselves. You can establish a
convention that all your servers store the object references 
that they use in a file or datsbase.

Mary Ann - but how do the Servers know what the initial object reference
was?

Thanks
Mark

Mark, I dont know the details of your servers but it's
fairly easy for servers to find details about object
references used for making requests to them.

Look at either OBB_BOA_initialize or the ACTIVATE_IMPL_ROUTINE
or the ACTIVATE_OBJ_ROUTINE. Or of course you get the objref
in the method arguments.

John D.

re: .8 .10

Thanks - alas it doesn't help.

In our application, once a server is active it usually completes it's task.
The area that's giving problems is when ObjectBroker fails to start or
find a server (the reasons for this are in .0, .1 of this note).

Currently we allocate  one of the pool of Initial Object References and then
depend upon the Server to `release' it (this happens by a private channel).
If ObjectBroker fails to route the request to a server it never gets 
released. So once again I need to ask the Agent what it knows about this
Object Reference so that I can recover it.

Passing the association between a server instance and an Object Reference, as
suggested earlier, will not help much here. I believe in V2.6 OBB introduced
a scheme to round-robin amongst multiple servers that implement the
same interface. So there is no long lived association between an
Initial Object Reference and a Server instance. 
It seems that the 'conformance to standard' that was introduce into V2.5B
only applies to the one-off association between Object Reference and
the autostarted server. OBB then seems to revert to old behaviour.


moving on ..

One of the alternatives being considered is generating an Initial Object
Referece upon demand. The reason we chose pre-defined references is that
it seems to be an expensive process. Better to do it offline than while
a customer is trying to post lots of documents. What are the consequences
for the Agent of doing this? If the Agent remembers every Object Reference
it was given it could end up with 100,000's object references.
Does the Agent have a mechanism for releasing these?

Mark


   

The Agent know nothing about the object reference because it
never sees them and does not know about it.

>> It seems that the 'conformance to standard' that was introduce ...

What does you mean when you say 'conformance to standard'?


Paul Patrick

>Currently we allocate  one of the pool of Initial Object References and then
>depend upon the Server to `release' it (this happens by a private channel).
>If ObjectBroker fails to route the request to a server it never gets 
>released. So once again I need to ask the Agent what it knows about this

Who allocated this object reference? 

If the client allocated it, then if no server is found, the client
should "release" the reference for re-use. The agent does not keep 
track of this at all, so there is nothing to ask the agent about such 
references. 

re: .12

>> Conformance to standard

sorry, bad choice of words here. 

In the era of ObjectBroker V2.5A,  we [EDI] used to create a single hard-coded
`Initial Object Reference' and let all our clients use it. This used to work
fairly well as the Agent would auto-start as many Server instances as there
were simultaneous Clients. 

With the introduction of V2.5B (V2.6 and later) this behaviour changed, the
Agent queued up all requests to a single Implementation Server instance.
There is a long note in here somewhere where there is a debate which 
culminated in the conclusion that this represents 'conformance to the CORBA
standard' (which permits only a single active instance of an Object). 


What I'm complaining about here is that the Agent only seems to do this
when it is Auto-starting Servers. Our new scheme uses multiple Initial Object
References, this permits multiple Server Instances to run. These share
the same Interface and Code - they are just different Objects. Once these
Servers are active the Agent seems quite happy to share work out amongst 
them. . What this means for me is that I can't associate a Server Instance
with an Object. If I could I could call the Mgt API and presume the Object
was free if the Server died. 


Btw - I think I can hack around thus now - my main concern is the problem
reported in .0.

Mark

re: .13 (Mary Ann)


> Who allocated this object reference?

They are hard-coded in a pool of 20. We have a Server that hands these
references out to a client [an `object factory' well perhaps I should say
warehouse]
  

>If the client allocated it, then if no server is found, the client
>should "release" the reference for re-use. The agent does not keep 
>track of this at all, so there is nothing to ask the agent about such 
>references

As far as the client is concerned, it receives an error. In my case there
seems to be a failure of the underlying DECnet link. If the client knew
the outcome of the last request - it certainly would "release" the
reference. 

Just as an fyi, I think I can code around this now. 

My main concern is the problem reported in .0.

This is the latest problem:

In order to re-use Object References we now have an 'Object Warehouse'. 
Unlike all our other implementation servers we really do only want one
of these ... alas the Agent creates multiples of them. 
What's the best way to progress this?

Cheers

Mark

 

Well when it rains it pours ... 

We are now trying OBB V2.7 on OpenVMS Alpha V7.1, DECnet plus V7.1 and 
TCP/IP V4.1.

As far as I can tell the DECnet transport works but the TCP/IP transport
seems to be looking for a non-existant node for authorization information.
Commands that look at files work but those that ask the agent (sho server ...)
return this error:



OBB> show conf/all

 Configurations
 -------------------------------------------------------
   "DECnet and TCP/IP Configuration" (Current)
   "DECnet-Only Configuration"
   "TCP/IP-Only Configuration"

OBB> set conf "TCP/IP-Only Configuration"
OBB> show server
%OBB-E-CMD_SRVFETFAIL, Could not find the requested servers.
-OBB-E-INV_CANTGETAUTH, Could not get an authentication key from node `$Node$'.
-OBB-E-INV_CANTGETAUTH, Could not get an authentication key from node `<nil>'.
OBB> set conf "DECnet and TCP/IP Configuration"
OBB> show serv
%OBB-E-CMD_SRVFETFAIL, Could not find the requested servers.
-OBB-E-INV_CANTGETAUTH, Could not get an authentication key from node `$Node$'.
-OBB-E-INV_CANTGETAUTH, Could not get an authentication key from node `<nil>'.
OBB> exit
$ obb
OBB> show serv
%OBB-I-CMD_NOMSRVSFND, No implementation server found matching the criteria.
OBB>

Any idea what could be causing this?

OBB> show conf/all

 Configurations
 -------------------------------------------------------
   "DECnet and TCP/IP Configuration" (Current)
   "DECnet-Only Configuration"
   "TCP/IP-Only Configuration"

OBB> set conf "TCP/IP-Only Configuration"
OBB> show server
%OBB-E-CMD_SRVFETFAIL, Could not find the requested servers.
-OBB-E-INV_CANTGETAUTH, Could not get an authentication key from node `$Node$'.
-OBB-E-INV_CANTGETAUTH, Could not get an authentication key from node `<nil>'.
OBB> set conf "DECnet and TCP/IP Configuration"
OBB> show serv
%OBB-E-CMD_SRVFETFAIL, Could not find the requested servers.
-OBB-E-INV_CANTGETAUTH, Could not get an authentication key from node `$Node$'.
-OBB-E-INV_CANTGETAUTH, Could not get an authentication key from node `<nil>'.
OBB> exit
$ obb
OBB> show serv
%OBB-I-CMD_NOMSRVSFND, No implementation server found matching the criteria.
OBB>
Thanks

Mark

The trace file:

$ define OBB_TRACE_FLAGS RTSA
$ obb
OBB> show server

*** Load Agent implementation OrbV12
        FamilyName<3> <OBB>
ImagePath<30> <sys$share:obb$agent_client.exe>
        LibraryName: sys$share:obb$agent_client.exe

*** Load Network implementation TCP
        FamilyName<5> <TCPIP>
ImagePath<31> <sys$share:obb$transport_tcp.exe>
        LibraryName: sys$share:obb$transport_tcp.exe
--- Connecting to NITRO2.reo.dec.com
---   Port: 62
--- Attempting connect on socket: 3
Obtaining Security Key for Client ID 7ae1039c58ba.02.10.24.70.bb.00.00.00
 Impl ID 65e448ecbd2c.0c.7e.0b.00.00.00.00.00

List of server supported sec. types isn't known yet. Trying client sec types in
turn

 Number of client supported security types: 1
Trying each of the sectypes from above list


*** Load Authentication implementation Trusted
        FamilyName<3> <TRS>
ImagePath<26> <sys$share:obb$security.exe>
        LibraryName: sys$share:obb$security.exe
Trying to get security key using Trusted package

Failed to obtain key/esatablish context using security package Trusted



************** Error ****************************
Could not successfully get key/establish context with any of the supported secur
ity package(s)*************

 Status of this operation: %OBB-E-INV_CANTGETAUTH, Could not get an authenticati
on key from node `$Node$'.
--- Closing socket: 3
%OBB-E-CMD_SRVFETFAIL, Could not find the requested servers.
-OBB-E-INV_CANTGETAUTH, Could not get an authentication key from node `$Node$'.
-OBB-E-INV_CANTGETAUTH, Could not get an authentication key from node `<nil>'.
OBB> 

	It's a long story however due to a bug in the DECNet Trusted package it is
necessary to MODIFY CONFIGURATION to set AuthrWOAuthn = Enabled. With "Trusted" you
are essentially doing just this; permitting authorization without the need to first
sucessfully authenticate. 
	This is only true for the Trusted package on VMS. With the GSS Package or
services AuthrWOAuthn means to authorize after a message authentication failure.
Additional information can be found in:

OB V2.7 Release Note 
1.12 Known Problems with Security

The VMS syntax for setting  AuthrWOAuthn is:

	MODIFY CONFIGURATION "Current Configuration /ACCEPT_AUTHR_WO_AUTHN

-Fred

Fred,

thanks, that was very helpful,

I also tried it on the DECnet only system and it seems to have cured the
problem I reported in .0. 

Mark