[omniORB] ILU to omniORB (lengthy)

[Geoff Gerrietts]

I'm in process of moving a services-based architecture off ILU and
onto CORBA, specifically with omniORBpy. Most of the transition is
going ... reasonably smoothly, better than a person should expect when
changing out a core component. I have some questions resulting from
the shift. Some of these questions may be naive; I'm new to CORBA, so
be gentle.

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?


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?

    2b. Am I making trouble for myself down the road?
        I've settled on a solution where I subclass the
        _objref_Interface and override client-side calls where the
        dictionaries might be used in the parameters or might be
        returned, and perform the marshalling there. This seemed
        superior to trying to do the marshalling/unmarshalling at
        every place the methods were employed. But am I making trouble
        for myself? Is the _objref_Interface name likely to change? Is
        there a "better" way to do it?

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. The
    __init__.py in each package import module_idl, which only works if
    "the current directory" is the current directory at runtime, or
    "the current directory" is on PYTHONPATH. Neither of these options
    is particularly good for my client application.
    
    Presently I'm doing some hijinx where I os.chdir to the "current
    directory" prior to importing the Module package, then os.chdir
    back to the working directory after the import takes. This appears
    to work just fine, but I find it a little concerning. Does anyone
    have a better solution?


4.  We have lots of monitoring knowledge now....
    One of the painful things about leaving ILU for us is our history
    with it. We've built a suite of tools that monitor an ILU server
    through ps and ilusbls and careful monitoring of logfiles,
    etcetera. While it would be best if our servers never died
    unexpectedly, it's almost as good if we can resurrect them when
    they die.

    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?

Thanks,
--G.

-- 
Geoff Gerrietts <geoff at gerrietts dot net>
-rw-rw-rw-:         permissions of the beast