Please report new issues athttps://github.com/DOCGroup
This discussion revolves around the problems encountered when (a) dynamically linking/unlinking the ORB and (b) the application sharing resources such as the reactor and the object manager with the ORB: (a) ORB handlers are registered with the reactor. The ORB depends on the reactor destructor to remove and delete the ORB handlers from the reactor. A closer look reveals two particular problems: 1. The server-side ORB handlers cache some memory that is returned to the ORB when they are destroyed. If the reactor was to survive the ORB and the handlers are deleted after the ORB dies, the ORB handlers would end up using invalid memory in their destructors! 2. The ORB handlers cannot be just left around registered in the reactor after the ORB dies in case they receive a CORBA request message; they would end up trying to dispatch the request to a destructed ORB! (b) The ORB explicitly deletes the reactor making reactor sharing with the application impossible when the reactor must outlive the ORB. (c) The ORB registers singletons with the Object Manager. If the ORB library is unlinked before the Object Manager is destroyed, the singleton cleanup will cause problems. Long term solutions: (a) Keep a collection of ORB handlers. This will help in removing the handlers that belong to the ORB when the ORB is destroyed. A side-effect will be a connection cache for bi-directional connections. (b) [Actually this can be implemented quickly] Hand the reactor back to the factory when the ORB is done with the reactor. The default factory would simply delete the reactor. (c) Use a mini-Object Manager for TAO. The ORB singletons are removed when the last ORB goes away rather than waiting for the process to end. Short-term solutions: (a) Do not unlink the ORB library and do not destroy the ORB. When the reactor finally dies, it will cleanup up the ORB handlers. (b) Covered above. (c) Covered by solution in (a). Note that the above discussion does not cover TAO configurations with multiple reactors.
This problem is related to Bug 225 and both should be solved simultaneously.
*** Bug 409 has been marked as a duplicate of this bug. ***
TAO 1.1.8 has a series of updates that address all of these issues. Reopening this bug report.
Since I implemented the updates, I'll accept responsibility for this bug report. All of the issues discussed in this bug report have been addressed. However, I'd like to make sure that issue "(b)" above has been dealt with properly. Specifically, I need to ensure that the default resource factories are behaving as described above with respect to the reactor life cycle.
Note that the reactor issues should have been addressed back in TAO 1.1.7. Specifically, TAO now keeps track of all open connections when the "reactive" ORB concurrency model is used. Upon ORB destruction, all event handlers associated with those open connections are removed from whatever reactor is in use, and explicitly closed during this process. This allows application-level reactors (as opposed to ORB-level) to be shared safely with the ORB and other entities. The "thread-per-connection" ORB concurrency model shouldn't be a problem since connections are ORB threads are shutdown when the ORB is destroyed.
Issue "(b)" was not handled by the recent DLL ORB changes. I'll fix this problem ASAP.
This bug is fixed for TAO 1.1.10. Relevant details are in the following ChangeLog entry: ChangeLogTag:Mon Sep 11 12:53:03 2000 Ossama Othman <ossama@uci.edu>
I just discovered a potential problem. TSS types used in TAO (i.e. ACE_TSS types) register TSS keys and destructors with the ACE_Cleanup_TSS class which is invoked by the ACE_Object_Manager when the Object Manager goes out of scope. This is a problem since the pointers, for example, used in the TSS destructor may be dangling pointers by the time the destructor is invoked. I ran into this problem while testing the new "set_tss_resource()" method in the ORB Core. The set_tss_resource() method sets the ORB Core pointer in current thread's TAO_ORB_Core_TSS_Resources instance. This is a problem since the ORB Core may have already been destroyed by the time the ACE_TSS_Cleanup class destroys the TSS resource instance. This means that the ORB core pointer in TAO_ORB_Core_TSS_Resources may no longer be valid by the time the ~TAO_ORB_Core_TSS_Resources destructor is invoked! We need to examine all other uses of the ACE_TSS class in TAO, including the TAO_TSS_Singleton.
Mine again, I guess.
Ossama, could you please capture the latest status?
Nothing has changed, which is why I haven't added anything further to this bug report. When I have more comments, I'll add them.
Looks line bug 846 needs to be fixed if this one is ever going to be solved.
Notice that 846 contains the beginning of a solution to the problem--although it was made to a 1.1.x beta. However, perhaps it could serve as a starting point.