[omniORB] ILU to omniORB (lengthy)

[Duncan Grisby]

On Friday 26 September, Geoff Gerrietts wrote:

> 1.  ILU had an alarm() function....
>     We have a service that manages user sessions. It keeps them all in
>     a great big dictionary. Every few minutes, during an idle cycle,
>     ILU would invoke a callback function that scanned the dictionary
>     for expired user sessions, similar to the way you'd register a
>     signal handler with alarm().
> 
>     I have seen no API in omniORB that replicates this feature. I
>     presume the suggested approach would be to spawn a worker thread
>     that periodically cleaned out sessions. Am I correct?

CORBA doesn't have a feature like that. There are various ways to
implement it yourself, including having clients ping the server, the
server ping the clients, or keeping a record of when clients last made
contact. It all depends on what your application requirements are.

> 2.  ILU's integrated dictionary support was handy....
>     ILU had a feature that allowed you to map a sequence of key/value
>     pairs to python dictionaries. This proved handy on a couple
>     occassions early in the development of our application and it's
>     become ubiquitous. That gives rise to two sub-questions:
> 
>     2a. Am I mapping this right?
>         I reviewed a couple different options, including mapping to an
>         Any, and mapping to a sequence of string/Any pairs. I settled
>         on preserving the original string/string encoding to avoid the
>         overhead of packing/unpacking the Any objects. Was that folly?

I assume you mean using the omniORB.any.to_any and from_any
functions. That isn't what they are intended for, so I wouldn't
recommend using them. Just write a wrapper class around the object
references you use that translates arguments to and from a sequence of
structs of key value pairs.

It is a very bad idea to touch or directly use the _objref_ classes.
They are internal to omniORB and might change.

> 3.  omniidl's python backend makes some assumptions....
>     The omniidl stubber drops a file Module_idl.py and creates Module
>     and Module_POA packages, all in the current directory.

To be precise, for IDL file foo.idl, containing module Bar, it outputs
foo_idl.py and packages Bar and Bar__POA. All of these can be put in
different packages using combinations of -Wbpackage, -Wbmodules and
-Wbstubs.

Out of interest, what does ILU do?  How do you find the modules it
outputs if they aren't on PYTHONPATH?

If you have lots of different bits of IDL to deal with, and you don't
want to have to decide where to put them, maybe you'd be better off
compiling it on the fly using omniORB.importIDL().

[... monitoring...]
>     Does anyone have this sort of information codified anywhere? Any
>     suites of monitoring tools or interfaces that are publicly
>     available? I've read some good advice about making all your
>     interfaces derive from a common monitoring interface, and mixing
>     in a common monitoring superclass. I like the idea and was
>     planning to implement something like that -- but the more ideas
>     and examples I have to draw from, the less pain I'm likely to
>     suffer. Anyone got some help for me?

What kinds of things do you want to monitor?  For most purposes,
logging from omniORB plus logging from your application (use the
logging module) are sufficient.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan at grisby.org     --
   -- http://www.grisby.org --