Issue 3666:  Persistent Server Port (interceptors-rtf)
Source: Oracle (Dr. Harold Carr, Ph.D., nobody)
Nature: Uncategorized Issue
Severity: 
Summary: A standard mechanism for providing a persistent server port
information to an activation daemon needs to be defined.  An
activation daemon needs to listen on the same port each time it is
started such that object references created by "persistent" POAs will
be valid.

Proposal:

The persistent port id is assigned by passing a

    -ORBPersistentServerPort=<value>

parameter to the ORB_init() call.  In java this is done using the

    org.omg.CORBA.PersistentServerPort

proprty to indicate the listening port for the activation daemon.


Resolution:  Exact text to be determined as a new issue if this issue passes.
Revised Text: 
Actions taken:
May 30, 2000: received issue
January 9, 2001: closed issue
Discussion: 

End of Annotations:=====
Date: Tue, 30 May 2000 09:26:14 -0700 (PDT)
Message-Id: <200005301626.JAA23366@shorter.eng.sun.com>
From: Harold Carr <harold.carr@eng.sun.com>
To: interceptors-ftf@omg.org, issues@omg.org
Subject: Persistent Server Port
Content-Type: text
X-UIDL: HV]d9B;1e99&,e9PQ;!!


A standard mechanism for providing a persistent server port
information to an activation daemon needs to be defined.  An
activation daemon needs to listen on the same port each time it is
started such that object references created by "persistent" POAs will
be valid.

Proposal:

The persistent port id is assigned by passing a

    -ORBPersistentServerPort=<value>

parameter to the ORB_init() call.  In java this is done using the

    org.omg.CORBA.PersistentServerPort

proprty to indicate the listening port for the activation daemon.

Date: Tue, 30 May 2000 10:33:28 -0700 (PDT)
Message-Id: <200005301733.KAA29297@shorter.eng.sun.com>
From: Harold Carr <harold.carr@eng.sun.com>
To: interceptors-ftf@omg.org, issues@omg.org
Subject: Portable Activation Framework using Portable Interceptors
Content-Type: text
X-UIDL: BMhd9FO!e9BIBe9&$>e9

Jurgen,

this is a discussion of issues I raised earlier, please do not make
this an issue.

All,


OK, as promised, here are how the issues I raised relate to building a
portable activation service.

Please keep in mind, *THIS IS A USE-CASE*.  We are *NOT* trying to
standardize location/activation services.  We are proposing
changes/extensions to portable interceptors based on our prototype of
an activation service built using portable interceptors.

I've identified the portions of the service which require
changes/extensions to the existing PI spec by preceding them with
"PI FTF".


    ORBD Startup

- PI FTF - ORBD is started on same port -ORBPersistentServerPort.
- ORBD specifies its ORBInitializer class.
- ORBDInitializer creates and registers activator reference in 
     initial references.
- ORBDInitializer creates and registers a ServerRequestInterceptor.


    Server Startup

- PI FTF - started with PersistentServerId (passed by activator).
- Activator passes appropriate ORBInitializer class.
- ORBInitializer pre_init creates and registers IORInterceptor.
- ORBInitializer post_init uses
- ORBInitInfo::resolve_initial_references
     to obtain a reference to the Activator which it gives to
- IORInterceptor
     for use during POA creation.


    Server POA Creation

In IORInterceptor:


- PI FTF - everything happens in new point: components_available.
- PI FTF - need access to POA LifeSpanPolicy (to determine if
- PERSISTENT).
- If persistent then do the following steps.
- PI FTF - get the IORTemplate associated with this POA.
- Register that template with the activator.
- Get the activator's template.
- PI FTF - set the adapter's template to the activator's template.
- Now, any references created by this POA will "point" to the
     activator (and contain components appropriate for the activator).
- PI FTF - the IORInterceptor must be called each time a POA is
     (re)created to enable it to exchange information with the
- activator.


    ORBD Server Request Interceptor

- Get the adapter_id from ServerRequestInfo.
- Lookup the template associated with this id.
- If it doesn't exist then request is for the ORBD.
- Otherwise
- Get the object_id from ServerRequestInfo.
- PI FTF - Use the object id to create a new reference from the
- server's
     template.
- Raise ForwardRequest.


    Misc

- PI FTF - not explicit is the fact that Java ORBs need an ORB ID for
     persistent references to be unique: serverId | orbId | poa
     path/name.

- PI FTF - when an object adapter is destroyed it notifies the
     activator of this fact so that the activator may reclaim
     resources.


Cheers,
Harold