Issues for Portability RTF List-defunt list, aliases to orb_revision

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 616: POA::id_to_reference()
Issue 648: Server request and oneway operations
Issue 738: DSI servants should support an _is_a method which receives an ObjectId
Issue 750: Setting the value of a DynAny after calling rewind() may be harmful
Issue 752: Invoke a create reference operation passing empty RepositoryID string
Issue 802: POAManager (02)
Issue 958: Separator character for POAs should be specified
Issue 964: No POA hook for future Policies
Issue 1116: DynAny issues
Issue 1118: DynAny issue (03), CORBA 2.2 chapter 7
Issue 1121: DynAny issue (06), CORBA 2.2 chapter 7
Issue 1123: DynAny issue (08), CORBA 2.2 chapter 7
Issue 1135: POAManager transition to same state
Issue 1161: Etherialization when destroying trees of POAs
Issue 1314: Access to the Active Object Map
Issue 1407: Interaction of find_POA() and AdapterActivatorts and create_POA()
Issue 1408: POA destroy() operation is ill-defined
Issue 1409: Multiple threads calling destroy() once destroy() operation has begun
Issue 1410: Changing default servant, etc. after POA activation
Issue 1428: Blocking POA operations
Issue 1628: POA API support for default servant
Issue 1645:
Issue 1646: DynAny assignment
Issue 1647: Inconsistent Typecode?
Issue 1668: DynFixed interface isn"t usefu
Issue 1670: DynAny::current_component if no components?
Issue 1671: DynAny: sometimes Any, sometimes DynAny?

Issue 616: POA::id_to_reference() (port-rtf)

Summary: Within context of request invocation, the POA can return ObjectId for target object. One could pass this to POA::id_to_reference to get references used to invoke target. Not true in non-retain case

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

deferred in June 2011 to the next RTF

Summary:  "DSI servants should support an _is_a method which 
    receives a RepositoryId and is invoked by the ORB to support remote
    _is_a_requests. _is_a should be included in the list of operations 
    that a DSI servant should support"  
 

 Revision:   Section 9.3.1 "The Servant IDL type", page 9-14. Add             

Summary: Instead of making implementations of DynAny more complex, we suggest to clarify that calling rewind() to set the value associated a DynAny object may lead to unpredictable results. It should also be specified that rewind() is only safe if used  to re-read components associated to DynAny or re-write components associated to a DynAny if the type associated to DynAny remains the same and that it is of fixed length

Summary:  In current POA specification, it is not specified
 what is the behaviour of create_reFerence* operations
 that receive an empty RepositoryId string.
 

   The specification should clearly state what"s the
 behaviour in this case, but it doesn"t.
 

Summary: How does a POA associate itself with a POAManager?
 

 closed issue

Summary: The Portability submission should specify a separator charater
 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<string>, 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.
 
 

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);
 
 

Summary: Section 7.1 states:
 
 "Destroying a DynAny object implies deleting the buffer it points to and
 also destroying all DynAny objects obtained from it. Invoking operations
 using references to descendants of a destroyed DynAny object leads to
 unpredictable results. Note that releasing a reference to a DynAny
 object will not delete the buffer pointed by the object, since the
 object indeed exists (it has not been explicitly destroyed)."
 
 This does not seem to completely specify the semantics of how destroying
 a DynAny affects its semantics.  If I have 3 DynAnys, DA1, DA2, and DA3,
 where I created DA2 from DA1 using current_component(), and DA3 from DA2
 also using current_component, what are the effects of the following
 operations:
 
 1.  DA1->destroy()
 
 2.  DA2->destroy()
 
 3.  DA3->destroy()
 
 

Summary: * Page 7-9, section "Iterating through components of a DynAny": The
 first sentence in this section says that DynAny allows iteration
 through structs. It should make it clear that it also allows
 iteration through sequences, arrays, and unions as well.
 

 Revision:   Section 7.2.3 "The DynAny interface", Page 7-9, 

Summary: * Page 7-13, section 7.2.8: the description of the "length" attribute
 for DynSequence says that the length is set to zero for unbounded
 sequences. This is useless as it confuses bound with length. That
 part of the sentence should be removed. If I want to know the
 sequence bound, I can ask its TypeCode. The DynSequence length
 attribute should be used to get/set the actual length of the sequence
 in the DynSequence regardless of whether its bounded or unbounded.
 

Summary: * Page 7-16, C++ example: the do-while loop condition should be
 
 while (!found && dyn_struct->next());
 
 That is, the ! negation of next() currently present in the example is
 wrong.
 
 In the same example, the semicolons after the close braces for the
 two "if" statements and the eval_filter() function are all unnecessary.
 
 * Overall: somebody needs to globally substitute "associated with"
 for "associated to" on this entire chapter.
 
 

Summary: The POAManager processing states diagram does not show an arrow from a
 given state to itself. Does it mean that the state transition from one
 state to the same state is disallowed? The accompanying text does not talk
 about this. 
 
 Suggestion is to allow one state to same state transition without raising
 an exception. The action should be no-op.
 

Summary: There is not (as far as I can see from the spec) any guarantee of
 the order of events when a hierarchy of POAs is destroyed. Because
 ServantActivators are themselves activated in some POA, there is no
 guarantee that when etherialization is performed for one POA that the
 servant activator itself won"t already have been deactivated. 
 

 clarified/fixed

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();
 	};
 
 };
 

Summary: 1. Interaction of find_POA() and AdapterActivators and create_POA().
 
 In a single-threaded environment, one can call find_POA() and cause
 an AdapterActivator to be invoked, which will ultimately call create_POA()
 and return control back to the user after completeing the initialization of
 that POA.
 
 In a multi-threaded environment, things are not that simple.  One can call
 find_POA(), which will invoke an AdapterActivator.  Now from here many
 things can happen.  For instance, another thread can come in and call create_POA()
 and create the POA before the AdapterActivator gets a chance to.  The
 AdapterActivator will then need to handle this unexpected condition.
 Granted, this was probably a poorly written program, but properly designed
 APIs should still have defined behavior for even incorrectly written programs.
 

Summary: The POA destroy() operation is ill-defined with respect to what happens
 to requests which are currently executing when destroy() is called.
 

 received issue

Summary: There is also a problem with multiple threads calling destroy() once a destroy() operation has
 begun.  This is particularly important when they set wait_for_completion to true, or if they
 call destroy with a different etherealize_objects value.  My current thought on this is that
 the first thread which calls destroy determines the etherealization policy for the destroy.
 If subsequent threads call destroy() while destruction is in progress they will wait for completion
 if wait_for_completion is true, otherwise they return immediately, and let the intial thread which
 called destroy() complete the destruction.
 
 

Summary: There is currently no defined behavior for what happens when one attempts
 to change the default servant by calling set_servant() when there are already
 activations on the current default servant.  There is a similar problem for
 calls to set_servant_manager() which are just as dangerous.  For instance,
 one could have a ServantLocator installed and have its preinvoke() method
 called, then change the ServantLocator to a new one, and it would have its
 postinvoke() operation called instead of the original ServantLocator.
 

Summary: Several operations on the POAManager and the POA itself have
 a boolean paramter wait_for_completion which is intended to
 block the thread until the operation has completed.  Unfortunately,
 this is not trivial to implement in an arbitrary multi-threaded implementation
 of the POA (or even a single-threaded for that matter).  The semantics of
 wait_for_completion are also quite  muddy in this situation, and we prefer not
 to add complexity to a system when the only gain is some very murky semantics.
 
 We would like to propose that wait_for_completion parameter is ignored
 and always set to FALSE, when the operation is invoked from a thread
 which is executing in a POA context (i.e. if Current::get_POA() returns
 a POA).  Or put another way, wait_for_completion is only meaningful
 when invoked outside the context of the POA by either a user-created
 thread, or in user-event loop (in single-thread environments).
 

Summary: The current POA APIs do not adequately support the use of
 default servants in the POA.  The particular operations of
 concern are servant_to_id, servant_to_reference, and 
 id_to_servant.
 

 Revision:   Section 9.3.8 "POA Interface".

Summary: The text for the assign operation says:
 
 	If an invalid DynAny object is passed (it has a different typecode
 	or doesn"t contain a meaningful value), the Invalid exception
 	is raised.
 
 Two problems with this:
 
 	- What"s a "meaningful" value, or more pertinently, what"s a
 	  value that isn"t meaningful?
 
 	  I think this needs to be defined a lot more clearly.
 
 	- More seriously, why can"t I assign a DynAny containing a
 	  string to a DynAny containing, say, a structure? I would
 	  have expected assignment to simply do a proper deep copy
 	  of all the components, including the type code. As defined,
 	  I can assign a DynAny to another DynAny only if the target
 	  does not have "a different type code".
 
 	  Was this intentional? If so, what"s the motivation?
 

Summary: The DynAny create operations on the ORB interface use the
 InconsistentTypeCode exception. As far as I can see, that exception is
 never defined. I assume it should be in the ORB interface.
 

Summary: The interface for DynFixed requires me to deal with a fixed-point type
 as an octet sequence. The contents of the octet sequence are simply
 the bytes that would be generated by the CDR marshaling rules for a
 fixed-point value.
 
 Fine, that allows me to get the values in and out, but it is pragmatically
 useless. Do we really expect every application dealing with DynFixed to
 re-implement the marshaling rules? Moreover, at run time, getting the
 value in and out is very complex. Either I use decadic logarithms to
 extract the digit values, or I need to turn the fixed-point value into
 a string and then parse out the digits (never mind that there is no
 standard API call for turning the fixed-point value into a string to
 start with).
 
 >From there, it is still completely unclear how I could turn the fixed-point
 octet sequence (which I now hold as a string or as a series of decimal
 digits) into a value I use to do computation. I would have to multiply
 successive digits into an accumulator, dividing by 10 for every digit.
 
 This is simply useless for all intents and purposes, because it is far
 too much work.
 l

Summary: What does DynAny::CurrentComponent() return if there are no components,
 for example if I iterate over an empty exception or empty sequence?
 

 received issue

Summary: Something a bit strange about component types for DynAny...
 
 For unions, the discriminator and the active member are controlled as
 type DynAny. For sequences and arrays, they are sequences of *any* (not
 DynAny). Yet, when I iterate over a sequence or array, the members are
 dealt with as type DynAny (instead of any).
 
 For structures, if I access the members via iteration, they are accessed
 as type DynAny, whereas if I use set_members() and get_members(), they
 are sequences of name-*any* pairs, not sequences of name-*DynAny* pairs.
 
 I don"t see why, in some cases, components are dealt with as type any,
 and in other cases, they are dealt with as DynAny. Any particular reason?