Corba transient error

Issue originally opened in stonneau/hpp-rbprm#22 When I try to run hpp-rbprm-server I got this: ORBA: CORBA::Exception TRANSIENT:IDL:omg.org/CORBA/TRANSIENT:1.0 : failed to narrow the root naming c...

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.

Already on GitHub?
Sign in
to your account


Closed

pFernbach opened this issue

Sep 19, 2019

· 19 comments

Comments

@pFernbach

Issue originally opened in stonneau/hpp-rbprm#22


When I try to run hpp-rbprm-server I got this:

ORBA: CORBA::Exception TRANSIENT:IDL:omg.org/CORBA/TRANSIENT:1.0 : failed to narrow the root naming context
CORBA: CORBA::SystemException: failed to narrow the root naming context.
terminate called after throwing an instance of 'hpp::Exception'
  what():  Failed to start corba server.
Aborted (core dumped)

I got the same errors when running the other corbaserver

Originally posted by @teguhSL in stonneau/hpp-rbprm#22 (comment)


Hi @teguhSL

If you run nameclt list, do you have any error ?

Originally posted by @nim65s in stonneau/hpp-rbprm#22 (comment)

@teguhSL

Running nameclt list gives me this:

Cannot resolve the root context.
Have you set up the configuration file properly?

@nim65s

ok, is the omniNames process running ?

Either it is not started (and you can start it with omniNames -start), or its configuration is not clear (and you can fix that with export NameService=corbaname::localhost)

@jmirabel

@teguhSL

Ok, now by following

ok, is the omniNames process running ?

Either it is not started (and you can start it with omniNames -start), or its configuration is not clear (and you can fix that with export NameService=corbaname::localhost)

omniNames is running, and I can run hbb-rbprm-server.

Then I run the following codes from darpa_hyq_path.py,

from hpp.corbaserver.rbprm.hyq_abstract import Robot

and get these errors:

omniORB: (0) 2019-09-19 16:01:07.669351: ERROR! omniORBpy version 4.2 expects stubs version 4.2. Stubs in /opt/openrobots/lib/python2.7/site-packages/hpp_stubs/corbaserver/obstacle_idl.pyc are version 3.0 (rev 0).
---------------------------------------------------------------------------
ImportError                               Traceback (most recent call last)
<ipython-input-1-204577a9b00a> in <module>()
----> 1 from hpp.corbaserver.rbprm.hyq_abstract import Robot

/opt/openrobots/lib/python2.7/site-packages/hpp/corbaserver/__init__.py in <module>()
----> 1 from .client import Client
      2 from .robot import Robot
      3 from .problem_solver import ProblemSolver, newProblem
      4 from .tools import loadServerPlugin, createContext
      5 from .benchmark import Benchmark

/opt/openrobots/lib/python2.7/site-packages/hpp/corbaserver/client.py in <module>()
      6 import CosNaming
      7 
----> 8 import hpp_idl.hpp.corbaserver
      9 
     10 class CorbaError(Exception):

/opt/openrobots/lib/python2.7/site-packages/hpp_idl/hpp/__init__.py in <module>()
      7 
      8 # ** 1. Stub files contributing to this module
----> 9 import hpp_stubs.corbaserver.obstacle_idl
     10 import hpp_stubs.corbaserver.problem_idl
     11 import hpp_stubs.corbaserver.robot_idl

/opt/openrobots/lib/python2.7/site-packages/hpp_stubs/corbaserver/obstacle_idl.py in <module>()
      5 _0_CORBA = CORBA
      6 
----> 7 _omnipy.checkVersion(3,0, __file__)
      8 
      9 # #include "hpp/common.idl"

ImportError: Stubs not compatible with omniORBpy version 4.2.

@nim65s

Thanks, I’m starting to understand. Which OS are you using ?

@teguhSL

@nim65s

I think you have robotpkg-omniorbpy, and that you should remove it, to use the standard python-omniorb package from Ubuntu.

omniORBpy should be on version 3 on 16.04.

@teguhSL

I already uninstall robotpkg-omniorbpy, but I still have the same issue.

Do you mean to remove also robotpkg-omniorb?
Indeed, I did not have robotpkg-omniorb after following the installation procedure, so I install it myself by sudo apt-get install robotpkg-omniorb. Otherwise, calling omniNames results in:

bash: /opt/openrobots/bin/omniNames: No such file or directory

although I have python-omniorb installed (version (3.6-1))

@nim65s

omniNames should be in omniorb-nameserver: /usr/bin/omniNames

@teguhSL

After removing robotpkg-omniorb, apparently I still have two versions of omniNames, in /usr/bin and /usr/local/bin. The problem persists, so I remove the one in /usr/local/bin. However, it seems that I am still running omniorb version 4.

I check /usr/lib and I have the following files:

libomniORB4.a
libomniORB4.so
libomniORB4.so.1
libomniORB4.so.1.6

How can I downgrade the running omniorbpy from 4.2 to 3.6? I already install 3.6 by sudo apt-get install python-omniorb and get:

python-omniorb is already the newest version (3.6-1).

But when I run the rb-prm program I still have the same error saying that my omniorbpy is version 4.2.

@nim65s

Having omniorb-nameserver v4.1 & python-omniorb v3.6 is normal.

But if I start a clean 16.04, with robotpkg-hpp-rbprm-corba, python-omniorb, omniorb-nameserver, I can get the following:

In [1]: import _omnipy

In [2]: _omnipy.checkVersion(3,0, "/opt/openrobots/lib/python2.7/site-packages/hpp_stubs/corbaserver/obstacle_idl.py")

without error.

Can you try to see what gives python -c 'import _omnipy; print _omnipy.__file__' ?

For me, that’s /usr/lib/python2.7/dist-packages/_omnipymodule.so, which is a correct path for python-omniorb

@jmirabel

You have to reinstall corba packages (hpp-corbaserver, hpp-rbprm-corba…) because the servers and clients must be regenerated.

@teguhSL

Running python -c 'import _omnipy; print _omnipy.__file__' gives me:
/usr/lib/python2.7/dist-packages/_omnipymodule.so
so I remove this file, and then running the above command now gives me the correct location:
/usr/lib/python2.7/dist-packages/_omnipymodule.so

After this I uninstall and reinstall hpp packages through robotpkg. Running

In [1]: import _omnipy

In [2]: _omnipy.checkVersion(3,0, "/opt/openrobots/lib/python2.7/site-packages/hpp_stubs/corbaserver/obstacle_idl.py")

returns without error, so it seems I have the correct version now.

However, running the codes

from hpp.corbaserver.rbprm.hyq_abstract import Robot

now gives me new error:

omniORB: Assertion failed.  This indicates a bug in the application
using omniORB, or maybe in omniORB itself.
 file: ../../modules/omnipy.cc
 line: 459
 info: omniPy::pyomniORBpoaCache
terminate called after throwing an instance of 'omniORB::fatalException'
Aborted (core dumped)

@nim65s

Ok, at this point it might be useful to clean your install and start again…
You can try with sudo apt purge *omni* and then sudo apt install omniorb omniorb-nameserver python-omniorb python-omniorb-omg

@teguhSL

I did what you suggested: purging *omni* and *hpp*, and then reinstall. But the problem still appears:

omniORB: Assertion failed.  This indicates a bug in the application
using omniORB, or maybe in omniORB itself.
 file: ../../modules/omnipy.cc
 line: 459
 info: omniPy::pyomniORBpoaCache
terminate called after throwing an instance of 'omniORB::fatalException'
Aborted (core dumped)


@nim65s

If I start a clean 16.04 with robotpkg apt repositories

sudo apt install omniorb omniorb-nameserver python-omniorb python-omniorb-omg robotpkg-hpp-rbprm-corba robotpkg-py27-qt4-hpp-gepetto-viewer

I can execute from hpp.corbaserver.rbprm.hyq_abstract import Robot without errors.

Without being able to reproduce your issue, it’s hard to find a fix…

Then maybe you can try to reinstall ubuntu.

@teguhSL

Hi, I have just tried on a freshly installed ubuntu and the first line works, thank you!

Now the problem is with gepetto_gui, when I launch it I got this:
»’
«omniorbserver.so» : «The shared library was not found.»
Plugin «omniorbserver.so» not loaded: «The shared library was not found.»
»’
I have tried restarting the omniNames but the problem remains

@jmirabel

The file omniorbserver.so should be in /opt/openrobots/lib/gepetto-gui-plugins.

  • If it is, then your LD_LIBRARY_PATH likely does not contain /opt/openrobots/lib
  • If it is not, then you may not have installed it. It should have been installed by the command above. It is part of package robotpkg-py27-qt4-gepetto-viewer-corba

@teguhSL

Thank you @jmirabel , now the example is working!

INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

Contact US

Thanks. We have received your request and will respond promptly.

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!

  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It’s Free!

*Tek-Tips’s functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

CORBA::TRANSIENT exception in corba client?

CORBA::TRANSIENT exception in corba client?

(OP)

27 Oct 08 22:50

i developed a corba client application which sucessfully compiled and started up normally, but the corba connection would be interrupted rulelessly with a CORBA exception described as CORBA::TRANSIENT.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Join Tek-Tips® Today!

Join your peers on the Internet’s largest technical computer professional community.
It’s easy to join and it’s free.

Here’s Why Members Love Tek-Tips Forums:

  • Tek-Tips ForumsTalk To Other Members
  • Notification Of Responses To Questions
  • Favorite Forums One Click Access
  • Keyword Search Of All Posts, And More…

Register now while it’s still free!

Already a member? Close this window and log in.

Join Us             Close

Operations Automation

Operations Automation:5.5

Operations Automation:5.x

Operations Automation:6.0

Operations Automation:6.x

Symptoms

Pleks Automation tasks fail with CORBA errors:

  • CORBA/TIMEOUT

  • CORBA/TRANSIENT

  • CORBA/COMM_FAILURE

Examples of errors:

  1. Destination host 'server1.example.com' (#32), IP '192.0.2.2' :
    The remote server is temporarily down. Please, make sure that destination host is accessible from POA management node and POA agent is running there.
    
    Details: system exception, ID 'IDL:omg.org/CORBA/TRANSIENT:1.0'
    OMG minor code (2), described as 'No usable profile in IOR.', completed = NO
    
  2. Destination host 'server1.example.com' (#32), IP '192.0.2.2' :
    Communication failure with remote server. Please, make sure that destination host is accessible from POA management node and POA agent is running there.
    
    Details: system exception, ID 'IDL:omg.org/CORBA/COMM_FAILURE:1.0'
    TAO exception, minor code = 1 (failed to recv request response; ETIMEOUT), completed = MAYBE
    
  3. Request has been timed out, details:
    
    system exception, ID 'IDL:omg.org/CORBA/TIMEOUT:1.0'
    TAO exception, minor code = 79 (timeout during recv; low 7 bits of errno: 121 No error), completed = MAYBE
    
  4. Operation execution is aborted by timeout. Please increase timeout for this operation and try again.
    Details: system exception, ID 'IDL:omg.org/CORBA/TIMEOUT:1.0' TAO exception, minor code = 3e (timeout during recv; low 7 bits of errno:  62 Timer expired), completed = MAYBE
    

Cause

The tasks fail as the result of various communication problems between the PA Management Node and managed hosts.

PA uses CORBA (Common Object Request Broker Architecture) technology to communicate with managed hosts through the PA Agent.

NOTICE: /etc/init.d/pem — This service starts a lots of instances of the process pleskd. This process is responsible for all PA functionality. Also several instances of pleskd process are responsible for PA agent which performs communication with PA agents on Service Nodes.

The PA Management Node sends requests to managed hosts to perform required provisioning operations using CORBA requests to the PA Agent, which must be installed on any host registered in and managed by PA.

In the event of problems sending requests to or receiving responses from the PA Agent, whatever the cause, background tasks may fail in PA with CORBA errors.

The most likely causes of communication problems between the PA Management Node and the PA Agent working on managed hosts are.

  • The managed host is down

  • The PA Agent has stopped on the managed host or is stuck

  • The PA Management Node cannot establish a connection to the PA Agent on the managed host due to problems with routing or a firewall

Resolution

Make sure the PA Management Node can establish a connection to the PA Agent working on the managed host, send a request to the PA Agent, and receive a response from it.

Follow the troubleshooting steps:

  1. Restart the failed task. If the problem with connectivity between the PA Management Node and the PA Agent was temporary, the task will be processed. If the task fails with a CORBA error after restarting, follow the next steps.

  2. Find the hostname and/or IP address of the problem host. This is mentioned in the failed task in the PA Task Manager as the destination host.

  3. Make sure the problem host is online:

    • Make sure the host does not experience any performance issues (if the PA task is one that takes a long time to run, its execution time may go beyond the timeout limit on a slow server)

    • Check if the host is connected to network

    • Try to log in to the host’s local console

    • Make sure there is enough diskspace on the affected host

If the managed server is down, powered off, or stuck, reboot it. Then, once the managed server is online, restart the failed task in PA.

  1. Make sure the pem service is up and running on the problem host:

    Linux:

    # /etc/init.d/pem status
    pleskd is running
    

    Windows:

    C:UsersAdministrator>net start pem
    The requested service has already been started.
    
  2. Restart the pem service on the managed host:

    Linux:

    # /etc/init.d/pem start
    Starting pleskd:                                           [  OK  ]
    

    Windows:

    C:UsersAdministrator>net start pem
    The PEM service is starting.
    The PEM service was started successfully.
    

Restart the failed task in PA.

Important: The managed host will be unavailable for provisioning tasks during a PA Agent restart. This means the host will be unavailable for new service provisioning and for tasks to modify/reconfigure/remove existing customers’ services. Customer services such as websites or mailboxes will not be affected by a PA Agent restart.

Step 6. Make sure that communication ports are open for connections between the PA Management Node and all managed hosts in the PA-managed environment.

Use the telnet utility on the PA Management Node to check that the necessary ports are open (i.e. to check if the PA Management Node can connect to the PA Agent):

telnet 192.0.2.2 8352

Restart the failed task in PA.

Use the tcpdump utility on Linux and the Network Monitor or WireShark utilities on the Windows PA Management Node and/or managed host to find out which port(s) the PA Management Node is trying to connect to when a PA task is running, then open the necessary ports.

Internal content

Понравилась статья? Поделить с друзьями:
  • Copied error please send this helpers on our discord server trx
  • Cooling fan 902 как исправить
  • Cooler fan error
  • Coolant low stop engine ошибка вольво
  • Cool reader как изменить размер шрифта