omniORB instrumentation (solution ideas)

[Giovanni Rimassa]

> 
> The nice thing about having the complete source is that you can
> modify the IDL compiler to generate the code that you want. It is not hard
> to do, I can give you pointers on where to start if you have some concrete
> ideas on what to put in.
> 

OK, so we've discussed about it and we agreed with you that exploiting IDL
custom code generation is a nice alternative to DII and DSI, but has the 
obvious shortcoming of being ORB-specific.

We designed an overall scheme for our task and realized what information we
needed about omniORB internals; now I'm outlining our solution and asking you
about those information (thank you in advance).

Our debugger will have a central console which manages and presents data 
gathered by various spy objects, each of which is connected with an object
implementation. The user will be able to select individual objects and methods
to spy, receiving notifications on the screen accordingly. 

In our idea there is an Observer design pattern with the object
implementation as the subject and some spy objects as the observers (or, if
you prefer, a push event model with object implementation as PushSupplier and
some spy objects as PushConsumer); so each object implementation will need a
couple of additional operations attach(in Spy aSpy) and detach(in Spy aSpy) to
allow spy registration.
We think that the IDL compiler could generate these two operations when a
suitable command line option is given; so we have:

interface spyable {

  void attach(in Spy aSpy);
  void detach(in Spy aSpy);
  void notify();

}

and the above interface is added to server stubs whenever a --spy-enable option
is given to the IDL compiler.

When a request is made for an object implementation, spy objects are notified
and can gather some data about object reference, operation arguments, besides 
performing some kind of timestamping.

To do the above we would like to have hints about these questions:

 - The concurrency architecture of omniORB: how many threads are running,
   which parts of the ORB core are in different threads of control (BOA,
   client stubs, server stubs and object implementation).

 - How requests are organized (i.e. data formats of arguments and result
   descriptors); I know you use IIOP for remote calls, so I think you deal
   with CDR packets, but I've also heard that omniORB behaves differently
   when both client and server are on the same machine. 
   Generally speaking, request data must travel the following layers:

   Client -> Client stubs -> ORB communication -> BOA -> Server stubs -> Server

   Since we want to put a spy after the BOA, we face two possibilities: we
   could modify the BOA to check whether the object implementation is in
   "spyable mode", or we could let the BOA behave the usual way, with the
   object implementation completely responsible of spy notification.
   In order to choose between the two approaches we need to know how the BOA
   performs method name resolution, i.e. when and how client requests are 
   demultiplexed according to the operation invoked. Could you give us some
   pointers into the code ?

 - Finally, since we want to write spy objects once and for all, we need a
   certain amount of metadata (operation name, formal parameters types and
   names, etc.). Of course, without Typecodes, Interface Repositories and 
   the like, all of those metadata aren't available at runtime, but they
   can be stored during compile time (perhaps generating ## preprocessing
   macros). Again, could you help us to better understand how much of this
   information is already in IDL compiler symbol table (or somewhere else)
   and how much is not present at all so that we will have to create it
   with manual modifications to the parsing code ? (We need metadata to
   realize filters, so that the user can watch for a specific operation or
   even for a specific actual parameter value). 

Thank you for your help (BTW I'm not sure if this kind of message is 
appreciated on this mailing list; I mean, if it's too detailed and not of
general interest I apologize: just tell me and I will resort to private mail
for detailed discussions like this).

Regards,

	Giovanni Rimassa  (rimassa@ce.unipr.it)