Issue 1314: Access to the Active Object Map (port-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: How about adding visibility to the Active Object Map. This would be beneficial to a factory-type server application that created and activated Servants and also periodically reported status on what it is in its AOM. Changes to the spec would look something like: module PortableServer { typedef sequence<Object> ObjectSequence; interface POA { ObjectSequence get_active_objects(); }; }; Resolution: Revised Text: Actions taken: May 11, 1998: received issue July 30, 1998: closed issue Discussion: End of Annotations:===== Return-Path: X-Sender: tcasalet@visigenic.com Date: Fri, 08 May 1998 17:21:11 -0700 To: port-rtf@omg.org From: Tom Casaletto Subject: Access to the Active Object Map How about adding visibility to the Active Object Map. This would be beneficial to a factory-type server application that created and activated Servants and also periodically reported status on what it is in its AOM. Changes to the spec would look something like: module PortableServer { typedef sequence ObjectSequence; interface POA { ObjectSequence get_active_objects(); }; }; Return-Path: Sender: jon@floorboard.com Date: Fri, 08 May 1998 18:06:07 -0700 From: Jonathan Biggar To: Tom Casaletto CC: port-rtf@omg.org Subject: Re: Access to the Active Object Map References: <3.0.2.32.19980508172111.00914830@visigenic.com> [Whoops! Hit send too soon.] Tom Casaletto wrote: > > How about adding visibility to the Active Object Map. This would be > beneficial to a factory-type server application that created and > activated > Servants and also periodically reported status on what it is in its > AOM. > > Changes to the spec would look something like: > > module PortableServer > { > typedef sequence ObjectSequence; > interface POA > { > ObjectSequence get_active_objects(); > }; > > }; This doesn't scale for POAs that hold thousands of objects. You are asking to chew up an incredible amount of memory to create all of those references and stick them in a sequence. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: From: "Daniel R. Frantz" To: "'Tom Casaletto'" , Subject: RE: Access to the Active Object Map Date: Mon, 11 May 1998 13:25:33 -0400 X-MSMail-Priority: Normal Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 >How about adding visibility to the Active Object Map. This >would be beneficial to a factory-type server application >that created >and activated Servants and also periodically >reported status on what it is in its AOM. It's very unclear whether this would result in anything useful. The Active Object Map doesn't have object references in it, only ObjectIds and their associated Servant language pointers. The POA would have to manufacture an object reference for each entry in the AOM, but there are many potential object references corresponding to an entry in the AOM because a servant can be used for many different interfaces. To be more precise... To manufacture an object reference, the POA needs a repository interface id. In this case the POA can't know the correct repository interface id to use. It can find *one* interface to use (see below) but that isn't necessarily the "correct" one. Why can't the POA do the equivalent of the POA::id_to_reference, you may ask? The answer is that it's not necessarily meaningful in this situation. POA::id_to_reference yields a reference created using the "most derived interface" from the skeleton of a servant or the "primary interface" for a DSI servant. The most derived interface is one that may or may not be the correct interface for this particular ObjectId. The use of the "most derived or primary interface" was there originally for the purpose of supporting the _this() operation (and equivalents in other languages). It's not really useful for anything else. That means, really, that servant_to_reference and id_to_reference are pretty useless operations. Even during method execution, they can't be guaranteed to give you the same reference that invoked the method. Dan Frantz Return-Path: From: "Daniel R. Frantz" To: Subject: Suggestions for issues 614, 648, 676, 744, 958, 964, 1314: no action Date: Mon, 29 Jun 1998 17:10:20 -0400 X-MSMail-Priority: Normal Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 I suggest we close the following issues with no action. Some enhancement issues were discussed and said to be impractical. Some met with opposition and will clearly never be accepted. Some answers are my own replies for enhancement requests that seem impractical. I think this shoots down a suggestion from almost everybody who's made more than one. I apologize if I've missed anybody. :-) Let me know if you disagree. We can take an email vote next week. Dan ======================================================== Issue 1314: Access to the Active Object Map Nature: Enhancement Summary: How about adding visibility to the Active Object Map. This would be beneficial to a factory-type server application that created and activated Servants and also periodically reported status on what it is in its AOM. Changes to the spec would look something like: module PortableServer { typedef sequenceObjectSequence; interface POA { ObjectSequence get_active_objects(); }; }; Resolution: Closed with no action. It is not possible to generate such a list given the information known to the POA because an ID and servant (the information the AOM) do not uniquely specify an object reference. Return-Path: Date: Tue, 30 Jun 1998 07:22:12 +0100 From: jhierro@jam.tid.es (Juan Jose Hierro Sureda) To: port-rtf@omg.org Subject: Re: Suggestions for issues 614, 648, 676, 744, 958, 964, 1314: no action X-Sun-Charset: US-ASCII > > I suggest we close the following issues with no action. > > Some enhancement issues were discussed and said to be > impractical. Some met with opposition and will clearly never be > accepted. Some answers are my own replies for enhancement > requests that seem impractical. I think this shoots down a > suggestion from almost everybody who's made more than one. I > apologize if I've missed anybody. :-) > > Let me know if you disagree. We can take an email vote next week. > > Dan I vote yes to the proposed resolutions and also agree with Jeff's sugestion regarding inclusion of the create_policy proposal in this RTF. -- Juanjo > > Issue 614: Threading and shutdown interfaces > Nature: Enhancement > Summary: The ORB interface for shutdown is incomplete and > underspecified. work_pending and perform_work as > specified are inadequate. See suggested changes > in communicating archive file. > Resolution: Closed with no action. It's not clear that the > enhancements are useful. > > Issue 648: Server request and oneway operations > Nature: Enhancement > Summary: Given it's optional to call set_result operation of > CORBA::ServerRequest, an ORB can't determine whether > operation supported is oneway or not. > Resolution: Closed with no action. The information is available > in GIOP. > > Issue 676: Use of root POA to implement root POA and POAMAnager > impossible > Nature: Error > Summary: It's impossible to use root POA to implement the root > POA and its POAManager, due to a deadlock because > POAManager starts in the HOLDING state. > Resolution: Closed with no action. The POA and POAManager are > implemented by the ORB so they must be special-cased > already. > > Issue 744: get_servant_manager and set_servant_manager > Nature: Revision > Summary: get_servant_manager and set_servant_manager > operations should not require the USE_SERVANT_MANAGER > policy to work. > Resolution: Closed with no action. The change would be > incompatible with the current specification. A > proposal for different entity on which to hang the > seemingly requested feature might be in order, such > as Issue 1162. > > Issue 958: Separator character for POAs should be specified > Nature: Enhancement > Summary: The Portability submission should specify a separator > character for POAs that may not be used in a POA name. > We propose that "/" be the separator character in POA > name, and that a "/" is not valid if used in a POA > name. This provides for vendors to provide a more > compact on-the-wire encoding, rather than use > sequence, and also is a convenience for the user if we > allow compound POA names to be used anywhere an > adapter_name is currently used in the POA APIs. > Resolution: Close with no action. On-the-wire representation of > POA name is implementer-defined. Providing a "compound > POA" name is not a feature that is universally > acclaimed. > > Issue 964: No POA hook for future Policies > Nature: Enhancement > Summary: The POA spec currently provides no hook for adding > future POA Policies. Several submission currently in > the works will be adding new policies to the POA. We > propose a generic create_policy() method which can be > used to create any Policy. We are open for discussion > on the signature, but a current thought is something > like this: Policy create_policy(PolicyType policyType, > Any policyValue); > Resolution: Closed with no action. The joint messaging RFP > submission had already included the ORB::create_policy > operation as part of the submission. > > Issue 1314: Access to the Active Object Map > Nature: Enhancement > Summary: How about adding visibility to the Active Object Map. > This would be beneficial to a factory-type server > application that created and activated Servants and > also periodically reported status on what it is in its > AOM. Changes to the spec would look something like: > module PortableServer { > typedef sequenceObjectSequence; > interface POA { ObjectSequence > get_active_objects(); > }; > }; > Resolution: Closed with no action. It is not possible to generate > such a list given the information known to the POA > because an ID and servant (the information the AOM) > do not uniquely specify an object reference. > > Return-Path: Date: Tue, 30 Jun 1998 19:01:02 -0400 From: Jonathan Biggar Organization: Floorboard Software To: "Daniel R. Frantz" CC: port-rtf@omg.org Subject: Re: Suggestions for issues 614, 648, 676, 744, 958, 964, > 1314: no action References: <005201bda3a2$53f81a80$3fc5bdce@idler.beasys.com> My comments on each one of these are included inline below: Daniel R. Frantz wrote: > I suggest we close the following issues with no action. > > Some enhancement issues were discussed and said to be > impractical. Some met with opposition and will clearly never be > accepted. Some answers are my own replies for enhancement > requests that seem impractical. I think this shoots down a > suggestion from almost everybody who's made more than one. I > apologize if I've missed anybody. :-) > > Let me know if you disagree. We can take an email vote next week. > > Dan > ======================================================== > Issue 1314: Access to the Active Object Map > Nature: Enhancement > Summary: How about adding visibility to the Active Object Map. > This would be beneficial to a factory-type server > application that created and activated Servants and > also periodically reported status on what it is in its > AOM. Changes to the spec would look something like: > module PortableServer { > typedef sequenceObjectSequence; > interface POA { ObjectSequence > get_active_objects(); > }; > }; > Resolution: Closed with no action. It is not possible to generate > such a list given the information known to the POA > because an ID and servant (the information the AOM) > do not uniquely specify an object reference. Right. The POA does not know the RepositoryIds to be used to construct the object references. Besides, it is quite feasible to implement the POA and Active Object Map so that incoming requests off the wire do not have to create a real object reference in order to dispatch the request. Building a sequence of all objects managed by the POA is not scalable for POAs managing millions of objects. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org