-
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
CORBA24 — Problem with text of POAManager::deactivate()
- Key: CORBA24-23
- OMG Task Force: CORBA Core 2.4 RTF