Although the user guide and various README files have documented all the ORB features and usage, it can be hard to dig all the useful bits out. What has been written may not directly address the question you have at hand. If someone has gone through the pain to dig out all the information, may be she is interested in sharing the information by adding their experience to the wiki.

Why not add your tips to this page? Just click the Edit button at the bottom.

Here is a tip

I'm trying to do <this>. It is not clear from the documentation how this can be done. I've gone through a lot of trouble to figure this out. To save another person from the agony, here is what I have found.


Quality Assurance

TestCoverageAnalysis: how to test omniORBpy servers for coverage


Unit Test

OmniArchive: a utility to archive and replay corba events from the interfaces of a running system.


Automatic server activation

You may easily hack sourceforge's "Action Factory" automatic activation daemon, initially designed to work with Orbacus, to make it work with omniORB. Look at http://actionfactory.sourceforge.net in AAD section.


omniORBpy Interceptors API

An interceptors API was recently added to omniORBpy. PythonInterceptors describes a trivial use of the API to pass authentication information between layers.


Building a Windows DLL from the omniidl generated stub/skeleton code

There are complications in getting the proper symbols exported from a DLL. BuildingaStubDll shows the steps in some detail.


SSH tunnels with omniORB

I recently had to use ssh tunnels to get omniORB working through a firewall. While it now works fine, it was a struggle to put the pieces together. This note is a summary of what worked; I hope it makes life easier for others.

The servant machine, which I'll call jeeves, is behind a firewall. The only IP port open to it is port 22, used by SSH. A client, called wooster, needs to access jeeves, and to do this it needs to get the correct reference (IOR) from a name server, which for generality I'll say is on a third machine, auntagatha.

The problem is two-fold. First, a tunnel has to be set up into jeeves from a machine that is not behind a firewall. I'll call this machine madeline. In reality, madeline could be the same as wooster or auntagatha, but to be general I'll assume it is a separate machine. Second, the name server needs to point to the entrance of the tunnel instead of the port on jeeves, which is the exit from the tunnel. The sequence of operations is as follows.

Without tunneling:

1. The servant application is started on jeeves, which registers itself with the name server running on auntagatha.

2. The client application on wooster contacts the name server on auntagatha to get the reference (IOR) for jeeves.

3. The name server on auntagatha returns the IOR for the servant on jeeves to the client on wooster.

4. The client on wooster uses the IOR to contact the servant on jeeves to run the application.

With tunneling:

1. The user fixes the IP port for the servant on jeeves either by setting the 'endPoint' parameter in the omniORB configuration file or by setting the ORBendPoint environment variable. For example (using bash),'export ORBendPoint=giop:tcp::32891'.

2. The user sets up an SSH tunnel to that port from madeline. For a one-time connection the command is something like 'ssh -g -L 32891:madeline.domain1.edu:32891 username@madeline.domain1.edu'. The port numbers do not necessarily need to be the same, but the -g option is important.

3. The servant application is started on jeeves, which registers itself with the name server running on auntagatha. But this registered IOR points to the end of the tunnel on jeeves, not to the publicly-available port on madeline.

4. The user needs to change the entry in the name server on auntagatha to point to the entrance to the tunnel on madeline. This is done as follows (but see below for a shell script that makes life easier)

  1. 'nameclt resolve <context.key/object.key>' (replace braketed item with the full context and object names used in the servant program). b. 'convertior <copy and paste IOR returned from step a here> madeline.domain1.edu 32891' c. 'nameclt -advanced rebind <context.key/object.key> <copy and paste the new IOR returned in step b here>'

The client on wooster should now be able to connect to the servant on jeeves.

Tom Meyer, Iowa State University (meyer@iastate.edu) Version 1.0 7 Jun 06


Here is a quick and dirty shell script that changes the name server entry for you:

#
# Name: tunnelior
#
# This script converts the entry in an omniORB name server to point to a
# different port and computer. This is useful if a servant is behind a firewall
# so clients must access it through an ssh tunnel. In this case, the name server
# must be changed to point to the entrance of the tunnel.
#
# usage: 'tunnelior context.key/object.key tunnelmachine.domain.edu IPPort'
#
# You must set the pivileges correctly to execute this on unix/Linux.
#
OLDIOR=`nameclt resolve $1`
NEWIOR=`convertior $OLDIOR $2 $3`
nameclt -advanced rebind $1 $NEWIOR
echo OLDIOR: $OLDIOR
echo NEWIOR: $NEWIOR
exit 0


Cross compiling omniORB

See CrossCompiling.


Smart Proxies

There is quite a bit of information in the e-mail list on smart proxies, for instance: http://www.omniorb-support.com/pipermail/omniorb-list/2006-October/028074.html


Avoiding deadlocks with omniORBpy in a C/C++ extension module

If using omniORB from within a C/C++ extension module, and the python process uses omniORBpy, it is important to be aware of the locking used by omniORBpy in order to avoid deadlocks.

OmniORB and Python both have their own global lock. The omniORB global lock is called omni::internalLock. The Python global lock is referred to as the [http://docs.python.org/api/threads.html global interpreter lock ("GIL")].

In order to avoid the possibility of a deadlock, these locks must always be acquired in the same sequence. OmniORBpy always acquires the omni::internalLock before the Python GIL. Thus we must adhere to this sequence also.

This means that the Python GIL must be released before calling any omniORB function which might try to acquire omni::internalLock. This includes CORBA::release(CORBA::Object_ptr) and CORBA::Object_var::~Object_var(). Naturally we'd want to release the Python GIL anyway before calling a function which might block on a remote invocation.


UsefulTips (last edited 2007-03-04 18:54:37 by adsl-69-105-124-109)