Bug 386

Summary:	Dynamically linking/unlinking the ORB and sharing resources between ORB and application
Product:	TAO	Reporter:	Irfan Pyarali <irfan>
Component:	ORB	Assignee:	DOC Center Support List (internal) <tao-support>
Status:	NEW ---
Severity:	normal	CC:	Detlef.Becker, Dietrich.Quehl, Karlheinz.Dorn
Priority:	P2
Version:	1.1.10
Hardware:	All
OS:	All
Bug Depends on:	846
Bug Blocks:	662

Description Irfan Pyarali 1999-12-04 16:10:45 CST

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.

Comment 1 Irfan Pyarali 1999-12-04 18:01:59 CST

This problem is related to Bug 225 and both should be solved simultaneously.

Comment 2 Irfan Pyarali 2000-01-20 13:30:59 CST

*** Bug 409 has been marked as a duplicate of this bug. ***

Comment 3 Ossama Othman 2000-08-15 11:07:30 CDT

TAO 1.1.8 has a series of updates that address all of these issues.  Reopening 
this bug report.

Comment 4 Ossama Othman 2000-08-15 11:10:33 CDT

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.

Comment 5 Ossama Othman 2000-08-15 11:21:05 CDT

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.

Comment 6 Ossama Othman 2000-09-07 13:21:21 CDT

Issue "(b)" was not handled by the recent DLL ORB changes.  I'll fix this
problem ASAP.

Comment 7 Ossama Othman 2000-09-11 15:03:21 CDT

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>

Comment 8 Ossama Othman 2000-11-20 12:46:18 CST

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.

Comment 9 Ossama Othman 2000-11-20 12:48:56 CST

Mine again, I guess.

Comment 10 Nanbor Wang 2001-10-21 11:13:22 CDT

Ossama, could you please capture the latest status?

Comment 11 Ossama Othman 2001-10-21 17:12:29 CDT

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.

Comment 12 Carlos O'Ryan 2002-12-08 14:03:12 CST

Looks line bug 846 needs to be fixed if this one is ever going to be solved.

Comment 13 Chris Cleeland 2002-12-08 14:15:07 CST

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.