Tango misses ORB parameters in some cases

[tango-controls-bot]

Hello,

In a DS I have the following code in main: int main(int argc, char* argv[]) { Tango::Database db;

// Some code to ask something to the Database

Tango::Util* tg = Tango::Util::init(argc,argv);

//... }

If on the command line I type:

$ <DS name> <DS instance> -ORBendPoint giop:tcp::50000

The DS doesn't recognize my ORBendPoint command line parameter and seems to start at a random port.

If I delete the Database access before creating Util everything works fine.

A workaround I found was to export an environment variable before: $ export ORBendPoint= giop:tcp::50000 $ <DS name> <DS instance>

Could this be fixed so that ORB parameters work in this scenario?

Thanks

Reported by: tiagocoutinho

Original Ticket: tango-cs/bugs/495

[tango-controls-bot]

Hi Tiago,

Why do you create a Database object before calling Tango::Util::init()? Once constructed, the Util singleton has a Database object that you can retrieve with the method Util::get_database().

This does not cover your needs?

Cheers

Manu

Original comment by: taurel

[tango-controls-bot]

Hi manu,

Sorry but it doesn't. What I have is an "interactive" device server: The idea is that if you start the device server without instance name or with an unknown instance name it asks if you want to register the given instance name in the database. To be able to do this I have to access the Database and ask if the given name exists and if not create one before the creation of the Util object.

Example:

$ Sardana manu -ORBendPoint giop:tcp::50000 manu does not exist. Do you wish create a new one (Y/n) ? y DServer/Sardana/manu has no event channel defined in the database - creating it Ready to accept request

(for documentation please check: http://www.tango-controls.org/static/sardana/latest/doc/html/users/getting\_started.html)

The workaround Ifound was to intercept all command line arguments that start with -ORB and export an environment variable with the same name to the process. This workaround works well so if it is very dificult to solve this you can postpone to a later version.

Thanks

Original comment by: tiagocoutinho

[tango-controls-bot]

Hi Tiago,

I have looked more deeply in this problem. It all comes because omniORB manages the ORB object as a singleton. When you create the Database object, because it's a client of the Database server, one ORB object is created for you. Tango::Util::init() creates one ORB as well but because one is already created, it gets the already created one.

Note that when we create one ORB object in a DS framework, we use some options specific to servers (like max thread number before switching to thread pool,...). In your case, these options are lost. This is the reason why I would use the workaround you found with lot of care.

One way to solve this issue, is that Util::init() destroys the client ORB if it finds one. This works fine. The drawback is that it invalidates the CORBA object created before the Util::init() call (your Database object). You get one exception if you try to use them after the call to Util::init().

It's not a 100 % perfect solution but it covers your needs (I guess)

What do you think?

Manu

Original comment by: taurel

[tango-controls-bot]

• status: open --> closed-fixed

Original comment by: taurel