Issue 1410: Changing default servant, etc. after POA activation (port-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: 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. Resolution: Revised Text: Actions taken: June 1, 1998: received issue July 30, 1998: closed issue Discussion: End of Annotations:===== Return-Path: Sender: gscott@inprise.com Date: Sat, 30 May 1998 14:35:37 -0700 From: "George M. Scott" Organization: Borland International, Inc. To: issues@omg.org CC: port-rtf@omg.org Subject: Changing default servant, etc. after POA activation 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. Proposal: The act of setting the default servant, servant manager, and adapter activator may only be performed while the POA's manager is not in the active state (i.e. the POA manager must be holding, discarding, or inactive) and there are no currently executing requests in the POA. Attempting to set any of the three values with the POA Manager in the active state will throw the OBJ_ADAPTER system exception. Attempting to set any of the three values while the POA Manager is not in the active state, but with requests currently executing will result in the call blocking until all requests have completed and then completing as normal. George Return-Path: Date: Thu, 04 Jun 1998 20:16:46 -0400 From: Paul H Kyzivat Organization: NobleNet To: "George M. Scott" CC: issues@omg.org, port-rtf@omg.org Subject: Re: Changing default servant, etc. after POA activation References: <35707BA9.E967DD95@inprise.com> George M. Scott wrote: > > 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. > > Proposal: The act of setting the default servant, servant manager, > and > adapter activator may only be performed while the POA's manager is > not in the active state (i.e. the POA manager must be holding, > discarding, > or inactive) and there are no currently executing requests in the > POA. > Attempting to set any of the three values with the POA Manager in > the > active state will throw the OBJ_ADAPTER system exception. > Attempting > to set any of the three values while the POA Manager is not in the > active > state, but with requests currently executing will result in the call > blocking > until all requests have completed and then completing as normal. > > George Once again, I see no reason to add extra machinery to every ORB implementation to protect server developers from themselves, when there is no risk to the ORB itself and sufficent mechanisms for the developer to do things in a safe way. If the developer wants to guarantee safety by putting the POAManager into holding or discarding before making such a change s/he is free to do so. If he fails to do so and screws up, it will not hurt the ORB. There are plenty of situations where there are other ways to know the operation is safe to perform. For instance, when creating a new POA that shares a POAManager with an existing POA, if no references are held anywhere that refer to the new POA then the changes are safe even if it is active. Also, during server initialization it may be safe to make changes on active POAs prior to calling ORB::run. How swaps may also be safe between different instances that vary in subtle ways that it is hard for any but the developer to envision. Replacing the servant is more of a problem than the others, because it is not inherently reference counted like the others. The problem is knowing when it is ok to destroy the old one rather than anything having to do with the new one. In general it will be difficult to know when to destroy a dynamically allocated default servant whether or not it has been replaced with another. Return-Path: Sender: gscott@inprise.com Date: Fri, 05 Jun 1998 14:09:07 -0700 From: "George M. Scott" Organization: Borland International, Inc. To: Paul H Kyzivat CC: issues@omg.org, port-rtf@omg.org Subject: Re: Changing default servant, etc. after POA activation References: <35707BA9.E967DD95@inprise.com> Paul H Kyzivat wrote: > George M. Scott wrote: > > > > 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. > > > > Proposal: The act of setting the default servant, servant > manager, > > and > > adapter activator may only be performed while the POA's manager is > > not in the active state (i.e. the POA manager must be holding, > > discarding, > > or inactive) and there are no currently executing requests in the > POA. > > Attempting to set any of the three values with the POA Manager in > the > > active state will throw the OBJ_ADAPTER system exception. > Attempting > > to set any of the three values while the POA Manager is not in the > > active > > state, but with requests currently executing will result in the > call > > blocking > > until all requests have completed and then completing as normal. > > > > George > > Once again, I see no reason to add extra machinery to every ORB > implementation to protect server developers from themselves, when > there > is no risk to the ORB itself and sufficent mechanisms for the > developer > to do things in a safe way. > > If the developer wants to guarantee safety by putting the POAManager > into holding or discarding before making such a change s/he is free > to > do so. If he fails to do so and screws up, it will not hurt the ORB. This not entirely correct, the ORB can be "hurt" depending on how the ORB keeps track of the number of current requests in a particular POA. If the default servant is switched, then the ORB may not realize there are still activations occuring or think there are activations remaining when actually they have completed. Since vendors may choose to implement this in many ways users will not experience consistent behavior across different vendors implementations, and we may as well remove the P from POA. > There are plenty of situations where there are other ways to know the > operation is safe to perform. For instance, when creating a new POA that > shares a POAManager with an existing POA, if no references are held > anywhere that refer to the new POA then the changes are safe even if it > is active. In general one cannot guarantee there are no references to a POA that was created with the Persistent policy. > Also, during server initialization it may be safe to make > changes on active POAs prior to calling ORB::run. This is not the case. Calling run() is not required to start an ORB running, nor is it required to call perform_work(). Those methods behave differently depending on the ORB implementation, some ORBs (including our MT ORBs) do not require their use. George Return-Path: Date: Fri, 05 Jun 1998 19:24:54 -0400 From: Paul H Kyzivat Organization: NobleNet To: "George M. Scott" CC: issues@omg.org, port-rtf@omg.org Subject: Re: Changing default servant, etc. after POA activation References: <35707BA9.E967DD95@inprise.com> <35785E73.DAFDD02F@inprise.com> George M. Scott wrote: > > Paul H Kyzivat wrote: > > > George M. Scott wrote: > > > > > > 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. > > > > > > Proposal: The act of setting the default servant, servant > manager, > > > and > > > adapter activator may only be performed while the POA's manager > is > > > not in the active state (i.e. the POA manager must be holding, > > > discarding, > > > or inactive) and there are no currently executing requests in > the > POA. > > > Attempting to set any of the three values with the POA Manager > in > the > > > active state will throw the OBJ_ADAPTER system exception. > Attempting > > > to set any of the three values while the POA Manager is not in > the > > > active > > > state, but with requests currently executing will result in the > call > > > blocking > > > until all requests have completed and then completing as normal. > > > > > > George > > > > Once again, I see no reason to add extra machinery to every ORB > > implementation to protect server developers from themselves, when > there > > is no risk to the ORB itself and sufficent mechanisms for the > developer > > to do things in a safe way. > > > > If the developer wants to guarantee safety by putting the > POAManager > > into holding or discarding before making such a change s/he is > free > to > > do so. If he fails to do so and screws up, it will not hurt the > ORB. > > This not entirely correct, the ORB can be "hurt" depending on how > the > ORB keeps track of the number of current requests in a particular > POA. > If the default servant is switched, then the ORB may not realize > there > are still activations occuring or think there are activations > remaining when > actually they have completed. Since vendors may choose to implement > this in many ways users will not experience consistent behavior > across > different vendors implementations, and we may as well remove the P > from POA. Well yes, I suppose it is possible to write an ORB so that it would be hurt by this. But it isn't required to write an orb that way. Surely we shouldn't change the spec just because someone can postulate (or even demonstrate) an implemenation that doesn't implement the current spec. I think it is necessary to demonstrate that the current spec cannot be implemented, or that the spec forces implementations to be unacceptably slow, or that it forces implementations that are unreasonably difficult for users to use. So far, I don't see that to be the case here. > > > There are plenty of situations where there are other ways to know > the > > operation is safe to perform. For instance, when creating a new > POA > that > > shares a POAManager with an existing POA, if no references are > held > > anywhere that refer to the new POA then the changes are safe even > if > it > > is active. > > In general one cannot guarantee there are no references to a POA > that > was created with the Persistent policy. True, but one can guarantee it for a transient POA. My point was to show that there exist some meaningful cases where changes could safely be made to an active POA. > > > Also, during server initialization it may be safe to make > > changes on active POAs prior to calling ORB::run. > > This is not the case. Calling run() is not required to start an ORB > running, nor is it required to call perform_work(). Those methods > behave differently depending on the ORB implementation, some > ORBs (including our MT ORBs) do not require their use. I knew somebody would say that. That is why I said "may be safe". I agree that doing so would make the program non-portable. Consider this to have been a test to see if anyone would implement an ORB that way. Now I know the answer. (Since a portable server program *must* call ORB::run (or at least ORB::work_pending and conditionally ORB::perform_work), an ORB might as well depend on it being called even if it is going to do all its work on other threads. In that way it serves as a strong hint that the program is ready to go.) Return-Path: Sender: "George Scott" Date: Wed, 01 Jul 1998 19:01:35 -0700 From: "George M. Scott" Organization: Inprise Corporation To: port-rtf@omg.org Subject: Proposed resolutions for Issues 1407-1410, 1428 The following are the proposals to address issues 1407-1410, and 1428. The proposals are based on our discussions from the previous POA conference call, and should hopefully be acceptable. I'm attempting to follow Dan's format for consistency. George ----------------------------------------------------------- Issue 1410: Changing default servant, etc. after POA activation Nature: Revision Summary: Changing default servants, servant managers, etc. after POA activation can be problematic. After some discussion it was agreed that this is only truly problematic for ServantLocators which need to have matching preinvoke/postinvoke operations. Failing to do so could result in memory leaks (due to the Cookie parameter) or other strange side effects, including inproper transaction management. Resolution: Accepted for Corba 2.3 RTF Revision: There are two current proposed revisions, which are outlined below. Inprise will vote for proposal (a) over proposal (b). (a) Change the second paragraph describing the set_servant_manager operation on page 9-33, Section 9.3.8 to the following: "This operation sets the default servant manager associated with the POA. This operation may only be invoked once after a POA has been created. Attempting to set the servant manager after one has already been set will result in the BAD_INV_ORDER exception being thrown." (b) Add a third paragraph to the description of set_servant_manager on page 9-33, Section 9.3.8: "Changing a ServantLocator will result in newly received requests calling preinvoke and postinvoke on the new ServantLocator. However, currently active requests will call postinvoke on the ServantLocator on which they called preinvoke, which may not be the same as the current ServantLocator." Return-Path: Date: Mon, 06 Jul 1998 13:55:46 -0400 From: Paul H Kyzivat Organization: NobleNet To: "George M. Scott" CC: port-rtf@omg.org Subject: Re: Proposed resolutions for Issues 1407-1410, 1428 References: <359AE9FF.441D15F7@inprise.com> George M. Scott wrote: > > The following are the proposals to address issues 1407-1410, > and 1428. The proposals are based on our discussions from > the previous POA conference call, and should hopefully be > acceptable. > > I'm attempting to follow Dan's format for consistency. > > George > > ----------------------------------------------------------- > Issue 1407: Interaction of find_POA(), AdapterActivators and > create_POA() > Nature: Clarification > > Summary: There is a race condition in the POA when an > AdapterActivator is invoked as a result of a > call to find_POA() or an over-the-wire request, and > simultaneously another thread calls create_POA() > attempting to create the same POA manually. > > Resolution: Accepted for Corba RTF 2.3 > > Revision: Section 9.3.3, Page 9-20. After first paragraph > in page beginning with "if unknown_adapter raises..." > add the following Note: > > Note - It is possible for another thread to create the same > POA the AdapterActivator is being asked to create if > AdapterActivators are used in conjunction with other threads > calling create_POA with the same POA name. To avoid potential > race conditions, it is recommended that AdapterActivators and > manual creation of POAs (via the create_POA call) not be used > in conjunction to create a particular POA. > > ------------------------------------------------------------- > Issue 1408: POA destory() is ill-defined > Issue 1409: Multiple threads calling destroy() once destroy() > has begun > Nature: Revision > > Summary: POA destroy is not defined sufficiently enough to > prevent multiple activations of the same POA name in > the same process. POA::destory semantics are not defined > for multiple threads calling destroy. > > Resolution: Accepted for Corba RTF 2.3 > > Revision: The following text will replace the current describing > the destroy operation in Section 9.3.8, Page 9-31. > > This operation destroys the POA and all descendant POAs. > Descendant POAs are destroyed (recursively) before the destruction > of the containing POA. The POA so destroyed (that is, the POA > with its name) may be re-created later in the same process. > (This differs from the POAManager::deactivate operation that does > not allow a re-creation of its associated POA in the same process. > > When a POA is destroyed, any requests that have started execution > continue to completion. Any requests that have not started > execution are processed as if the POA were in the holding state, > until execution of all active requests has completed. Once > all active requests have completed, all queued requests (if > any) will behave as if they were newly arrived, that is, the POA > will attempt to cause recreation of the POA by invoking one or > more adapter activators. > > If the etherealize_objects parameter is TRUE, the POA has the > RETAIN policy, and a servant manager is registered with the POA, > the etherealize operation on the servant manager will be called > for each active object in the Active Object Map. Etherealization > will not occur until all active requests have completed execution. > The apparent destruction of the POA occurs before any calls > to etherealize are made. Thus, for example, an etherealize > method that attempts to invoke operations on the POA will > receive the OBJECT_NOT_EXIST exception. > > {editorial note - below I have merged text from these two issues > and issue 1428 because they change the same text. If > one of these resolutions fails, we will need to edit the following > text) > > The wait_for_completion parameter is handled as follows: > > - If wait_for_completion is TRUE and the current > thread is not in a POA-dispatched invocation context, the > destroy operation will return only after all active requests > have completed and all invocations of etherealize have > completed. > > - If wait_for_completion is TRUE and the current thread is in a > POA-dispatched invocation context, then the BAD_INV_ORDER > exception is thrown and POA destruction does not occur. > > - If wait_for_completion is FALSE, the destroy operation > destroys all POAs but does not wait for active requests to > complete nor for etherealization to occur. > > If destroy is called multiple times before destruction is > complete (because there are active requests), the > etherealize_objects parameter will only apply to the first > call of destroy, 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). > This seems reasonable. > -------------------------------------------------------------- > Issue 1410: Changing default servant, etc. after POA activation > Nature: Revision > > Summary: Changing default servants, servant managers, etc. > after POA activation can be problematic. After some > discussion it was agreed that this is only truly > problematic for ServantLocators which need to have > matching preinvoke/postinvoke operations. Failing > to do so could result in memory leaks (due to the > Cookie parameter) or other strange side effects, > including inproper transaction management. > > Resolution: Accepted for Corba 2.3 RTF > > Revision: There are two current proposed revisions, which are > outlined below. Inprise will vote for proposal (a) > over proposal (b). > > (a) > Change the second paragraph describing the set_servant_manager > operation on page 9-33, Section 9.3.8 to the following: > > "This operation sets the default servant manager associated > with the POA. This operation may only be invoked once after > a POA has been created. Attempting to set the servant manager > after one has already been set will result in the BAD_INV_ORDER > exception being thrown." I find this overly restrictive. > > (b) > Add a third paragraph to the description of set_servant_manager > on page 9-33, Section 9.3.8: > > "Changing a ServantLocator will result in newly received requests > calling preinvoke and postinvoke on the new ServantLocator. > However, currently active requests will call postinvoke on the > ServantLocator on which they called preinvoke, which may not be > the same as the current ServantLocator." I also find this overly restrictive. It imposes a particular implementation discipline to cover an obscure case that will rarely arise in practice and which a developer can work around if it does arise. I would assert: - in most cases there will be no need to change the locator, - when it is necessary, the developer will probably know that the change is safe, - when the developer doesn't know it is safe, the POAManager state can be set to holding before making the change to guarantee safety. So, I don't think any change is needed, except for some words of warning, replacing the ones above: "If a ServantLocator is replaced while operations are outstanding, then the old ServantLocator may be called for preinvoke and the replacement for postinvoke of the same request. If this is unacceptable, then the POA's POAManager may be placed in the HOLDING state prior to making the change." > > ---------------------------------------------------------------- > Issue 1428: Blocking POA Operations > Nature: Revision > > Summary: Several operations added to CORBA as part of the > Portability submission provide blocking behavior which > can result in deadlock in a large number of cases. > These calls include POA::destroy, ORB::shutdown, > POAManager::deactivate, POAManager::hold_requests, > POAManager::discard_requests. > > Resolution: Accepted for Corba 2.3 RTF > > Revision: The following changes are proposed: > > Replace the second sentence in the paragraph of section 4.9.4, > page 4-20, which begins with "If the wait_for_completion ..." > with the following: > > "If the wait_for_completion parameter is TRUE and the current > thread is not in an ORB-dispatched invocation context, this > operation blocks until all ORB processing (including request > processing and object deactivation or other operations associated > with object adapters) has completed. If the wait_for_completion > parameter is TRUE and the current thread is in an ORB-dispatched > invocation context, then the BAD_INV_ORDER exception is thrown." > > Replace the phrase "If the parameter is TRUE" in the 2nd > paragraph, 2nd sentence of the hold_requests description in > Section 9.3.2, page 9-18, with the phrase "If the parameter > is TRUE and the current thread is not in a POA-dispatched > invocation context". Add the sentenence "If the parameter > is TRUE and the current thread is in a POA-dispatched invocation > context then the BAD_INV_ORDER exception is raised and the > state is not changed." > > Replace the phrase "If the parameter is TRUE" in the 2nd > paragraph, 2nd sentence of the discard_requests description in > Section 9.3.2, page 9-18, with the phrase "If the parameter > is TRUE and the current thread is not in a POA-dispatched > invocation context". Add the sentenence "If the parameter > is TRUE and the current thread is in a POA-dispatched invocation > context then the BAD_INV_ORDER exception is raised and the > state is not changed." to the end of the paragraph. > > Replace the phrase "If the parameter is TRUE" in the 3rd > paragraph, 2nd sentence of the deactivate description in > Section 9.3.2, page 9-18, with the phrase "If the parameter > is TRUE and the current thread is not in a POA-dispatched > invocation context". Add the sentenence "If the parameter > is TRUE and the current thread is in a POA-dispatched invocation > context then the BAD_INV_ORDER exception is raised and the > state is not changed." to the end of the paragraph. > > (editorial note- I changed the text for POA::destory in the > resolution of issues 1408 and 1409 above, so it is not shown > here but a similar change to the above is necessary. > I also felt that 1409 raised an issue which also affects > POAManager::deactivate, so the following change is also > proposed) > > Add the following paragraph to the end of the description of > deactivate in section 9.3.2, page 9-19. > > "If deactivate is called multiple times before destruction is > complete (because there are active requests), the > etherealize_objects parameter will only apply 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)." This seems reasonable Return-Path: Sender: "Jon Goldberg" Date: Wed, 08 Jul 1998 10:56:26 -0700 From: Jon Goldberg To: Jonathan Biggar CC: port-rtf@omg.org Subject: Re: Proposed resolutions for Issues 1407-1410, 1428 References: <359AE9FF.441D15F7@inprise.com> <35A3267A.181DCAD8@inprise.com> <35A38C82.5C41F600@floorboard.com> Jonathan Biggar wrote: > > Jon Goldberg wrote: > > > > Hi Folks- > > > > I've modified and am now resubmitting George's original proposal > for > > issues 1408-9, 1428 to take into account the conference call > feedback > > from July 7 (tuesday). Based on my notes, 1428 actually was not > > changed from the conference call but I've included it in this > message > > since they are all inter-dependent. My assessment of the changes > > is: > > > > 1. description of destroy changed to explicitly talk about setting > > the POA and its descendents as if they have already been destroyed > > prior to etherealization beginning for any active objects of any > > of those POAs. This ensures that all of the POAs pending > destruction > > will reject/queue (see #3 below) requests before any > etherealization > > is started. In the initial proposal, each child POA was > independently > > destroyed before destruction of the parent POA. This allows a > > possibility of infinite looping in the destruction if > etherealization > > for two child POAs cause each other to be re-created on each > > POA destruction. > > > > 2. the current description compares the POA's temporary behavior > as if > > it is in the "holding state". We agreed to change this > terminology to > > describe it as if the POA's POAManager(s) are in a state, since > POAs > > themselves do not have state. > > > > 3. We also concluded that the state in question should be > "inactive", > > not "holding". The implication of this change is that for the > > duration of the destruction (which may include etherealization), > any > > requests for that POA will now result in an exception. Once the > > destruction is complete, any new requests might cause the POA to > be > > recreated. Although this avoids deadlocks where etherealization > > attempts to access another POA which is pending destruction, it > means > > clients will see inconsistent results depending on when > destruction > > occurs for a POA. If the state is "holding", these requests will > be > > queued and the client will always see a consistent result, > although > > the request may take longer to complete depending on when POA > > destruction occurs. In addition, with change #1 above, if the > state is > > "holding" deadlocks can occur if one POA's etherealization depends > on > > another POA being destructed. I'm stating this implication here > to > > make sure that the RTF voters are all aware of the issue. > > I don't like this much because it does cause visibility of the > destroy > process to the clients, particularly if the destroy comes from a > call to > ORB::shutdown(). However, I don't see a good way around this. > Perhaps > it would be a good idea to also state that when ORB::shutdown() is > called that the input side of the protocols (GIOP) are blocked > before > the POAs are destroyed in order to avoid client interaction while > the > shutdown is processing? Then the process would look like this: > > 1. Someone calls ORB::shutdown(). > > 2. All server side protocol connections are blocked from processing > further input. > > 3. All pending requests are drained from the ORB. > > 4. Once the last outstanding reply is sent on a server connection, > the > connection is shutdown (via CloseConnection if GIOP). > > 4. All POAs are destroyed. In the case of ORB::shutdown this may work because all new requests will be rejected and therefore POAs can be destroyed without deadlock or infinite looping. If the ORB isn't being shutdown, however (we are just destroying a POA and its descendants), new requests can still come in and we're back in the same hole as before. > 5. Any other ORB level cleanup is done. > > Of course this could be left as a quality of ORB implementation > issue, > but that is how I would implement this. After further consideration, I no longer think it is tolerable for the POAs to behave as if INACTIVE. The common case is POA destruction without mutual reference to sibling POAs, and this should not be penalized by opening up a window for client requests to be rejected. Furthermore, I no longer think it is possible to solve this deadlock problem. I think the best we can do is as follows: 1. use the scheme outlined in my revised proposal which first marks the POA and its descendants as pending destruction. 2. keep the original meaning of 'pending destruction', which means they behave as if their POAManagers are in the HOLDING state. The POAs will not behave as if their POAManagers are in the INACTIVE state because this surfaces the destruction to clients which is the wrong behavior. 3. declare that POA etherealization which depends on access to other POAs that are pending destruction is dangerous and should be avoided since it can cause deadlocks. I think #1 and #2 are necessary to maintain atomicity (a POA should not be recreated if its parent POA is pending destruction) and to protect clients. any thoughts? -Jon Return-Path: Date: Thu, 09 Jul 1998 12:40:46 -0400 From: Paul H Kyzivat Organization: NobleNet To: Jon Goldberg CC: Jonathan Biggar , port-rtf@omg.org Subject: Re: Proposed resolutions for Issues 1407-1410, 1428 References: <359AE9FF.441D15F7@inprise.com> <35A3267A.181DCAD8@inprise.com> <35A38C82.5C41F600@floorboard.com> <35A3B2CA.694FC370@inprise.com> Jon Goldberg wrote: > After further consideration, I no longer think it is tolerable for > the POAs to behave as if INACTIVE. The common case is POA > destruction > without mutual reference to sibling POAs, and this should not be > penalized by opening up a window for client requests to be rejected. I agree. > > Furthermore, I no longer think it is possible to solve this deadlock > problem. I think the best we can do is as follows: > > 1. use the scheme outlined in my revised proposal which first marks > the POA and its descendants as pending destruction. > > 2. keep the original meaning of 'pending destruction', which means > they > behave as if their POAManagers are in the HOLDING state. The > POAs will not behave as if their POAManagers are in the INACTIVE > state > because this surfaces the destruction to clients which is the > wrong behavior. > > 3. declare that POA etherealization which depends on access to other > POAs that are pending destruction is dangerous and should be avoided > since it can cause deadlocks. I am not sure I fully understand how you want this to work, but I think there is a problem: It should be possible to destroy all the POAs by destroying the root POA, and have something reasonable happen. This is implicitly what happens during shutdown, and it ought to be possible to do the same thing explicitly. But doing something reasonable in this case means that etherealization ought to take place (except perhaps in pathological cases). If destroying a parent POA first marks its entire tree as destroyed, and then starts etherealizing things, the POAs at the bottom of the tree can't use servant managers that are nearer to the root. The best way I can see to make this work reasonably is to have destroy on a POA first work bottom-up, destroying the most derived children first while leaving the higher up POAs free to service calls to any servant managers they may contain. Once a POA has given its children a chance this way, it can finally make itself unusable and etherealize its own children. This process eventually percolates all the way to the the POA that the first destroy request was sent to. There are still failure modes - when a POA has a ServantActivator in a peer or child POA, or an etherealize method that activates new objects in another POA. In the worst cases etherealization of some servants fails. I would just like to get the common cases working reasonably. > > I think #1 and #2 are necessary to maintain atomicity (a POA should > not be recreated if its parent POA is pending destruction) and > to protect clients. > > any thoughts? Yes - above.