CORBA 2.4 MAILINGLIST Avatar
  1. OMG Issue

CORBA24 — Problem with text of POAManager::deactivate()

  • Key: CORBA24-23
  • Legacy Issue Number: 2911
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The first paragraph of 11.3.2.6 says:

    This operation changes the state of the POA manager to inactive. If
    issued while the POA manager is in the inactive state, the
    AdapterInactive exception is raised. Entering the inactive state causes
    the associated POAs to reject requests that have not begun to be
    executed as well as any new requests.

    But the last paragraph says:

    If deactivate is called multiple times before destruction is complete
    (because there are active requests), the etherealize_objects parameter
    applies only to the first call of deactivate; subsequent calls with
    conflicting etherealize_objects settings will use the value of the
    etherealize_objects from the first call. The wait_for_completion
    parameter will be handled as defined above for each individual call
    (some callers may choose to block, while others may not).

    So which is right? Is does a subsequent call to deactivate() raise
    AdapterInactive, or does it succeed, perhaps blocking until completion?

  • Reported: CORBA 2.3.1 — Mon, 18 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Incorporate changes and close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT