2010/11/15 Philippe Hamelin <philippe [dot] hamelin [..] ...>

>
>
> 2010/11/15 Philippe Hamelin <philippe [dot] hamelin [..] ...>
>
> Hello,
>>
>> I'm having two strange Corba behavior with RTT-2.
>>
>> ---
>> The first one is on handling connection timeout. Here is the test case:
>>
>> - Load component A with the corba deployer
>> - In program B, Create a ControlTaskProxy to component A (no deployer,
>> just plain C++)
>> - Kill the process of component A (so the component still in the naming
>> server list)
>> - In program B, call getOperation(...) and then send().
>>
>> Since no timeout has been configured in InitOrb, I was hoping for one of
>> these two behaviors:
>>
>> 1. My first guess: the send() just normally execute, but the collect()
>> never returns
>> 2. My second guess: the send() just indefinitely blocks (like
>> method/command in RTT-1)
>>
>> However, we are getting this CORBA exception:
>>
>> system exception, ID 'IDL:omg.org/CORBA/TRANSIENT:1.0'OMG<http://omg.org/CORBA/TRANSIENT:1.0%27OMG>minor code (2), described as 'No usable profile in IOR.', completed = NO
>>
>> According to this behavior, it's impossible to trigger CORBA Timeout
>> Exception as in RTT-1. Am I missing something?
>>
>> ---
>> The second strange behavior is with data ports. Here is the test case:
>>
>> - Load component A with the corba deployer
>> - Component A outputs periodicaly (100 Hz) data to output ports
>> - Connect to component A with the ctaskbrowser
>> - Quit the ctaskbrowser
>>
>> Then, in the log of component A we have these errors:
>>
>> 13.807 [ ERROR ][OrbRunner] caught CORBA exception while marshalling:
>> TRANSIENT
>> 13.814 [ ERROR ][OrbRunner] A channel of port MyOutputPort has been
>> invalidated during write(), it will be removed
>>
>> I'm having the same error when connecting the output port of component A
>> to another component. Is this normal?
>>
>>
>> Philippe
>>
>>
> I would also like to add a third strange behavior:
>
> - Load component A with corba deployer
> - Load component B (plain C++)
> - Connection output ports of A with input ports of B
> - In the deployer of A, quit()
>
> Then, we are having this error:
>
> 16.691 [ Info ][ShutdownOrb] Cleaning up TaskContextServers...
> 16.694 [ Info ][~TaskContextServer()] Successfully removed CTaskContext
> 'SpaceNav' from CORBA Naming Service.
> 16.697 [ Info ][~TaskContextServer()] Successfully removed CTaskContext
> 'Deployer' from CORBA Naming Service.
> 16.698 [ Info ][ShutdownOrb] Cleanup done.
> 16.698 [ Info ][ShutdownOrb] Orb Shutdown...waiting...
> 16.698 [ Info ][ShutdownOrb] Breaking out of orb->run().
> 16.698 [ Info ][Logger] done.
> 16.698 [ Info ][OrbRunner] Safely stopped.
> 16.698 [ Info ][DestroyOrb] Orb destroyed.
> 16.698 [ Info ][DeploymentComponent::stopComponents] Stopped SpaceNav
> 16.698 [ Info ][DeploymentComponent::cleanupComponents] Cleaned up
> SpaceNav
> 16.699 [ ERROR ][OrbRunner] deployer-corba-gnulinux ORO_main : CORBA
> exception raised!
> 16.699 [ ERROR ][OrbRunner] system exception, ID 'IDL:
> omg.org/CORBA/BAD_INV_ORDER:1.0'
> TAO exception, minor code = 0 (POA has been destroyed or is currently being
> destroyed; unspecified errno), completed = NO
>
> I can't figure this out, but it seems that we are trying to send something
> over CORBA while the POA is being destroyed.
>
>
I'm now getting a fourth strange behavior (similar to the previous one):

- Load component A with corba deployer
- Component A periodicaly output data to output ports
- Connect to component A with a ctaskbrowser
- quit() from the ctasbrowser

Then, I'm getting this error (as in the first post):

8.585 [ ERROR ][Logger] caught CORBA exception while marshalling:
COMM_FAILURE
8.587 [ ERROR ][Logger] caught CORBA exception while marshalling: TRANSIENT
8.592 [ ERROR ][Logger] A channel of port currentPoseOutput has been
invalidated during write(), it will be removed
8.592 [ ERROR ][Logger] A channel of port currentVelocityOutput has been
invalidated during write(), it will be removed

- quit() from the deployer of component A

Then, I'm getting a segmentation fault:

#0 0x00284803 in RTT::base::ChannelElementBase::disconnect (this=0x8094178,
forward=false) at
/home/hamelinp/orocos-toolchain-2.1.0/rtt/rtt/base/ChannelInterface.cpp:83
#1 0x0153e944 in RTT::internal::ConnOutputEndpoint<std::vector std::allocator /usr/local/lib/orocos/types/librtt-typekit-gnulinux.so
#2 0x002937e3 in RTT::internal::ConnectionManager::eraseConnection
(this=0xb6e15448, descriptor=...) at
/home/hamelinp/orocos-toolchain-2.1.0/rtt/rtt/internal/ConnectionManager.cpp:143
#3 0x002942b5 in boost::_mfi::mf1<bool, RTT::internal::ConnectionManager,
boost::tuples::tuple boost::intrusive_ptr<RTT::base::ChannelElementBase>,
boost::tuples::null_type, boost::tuples::null_type,
boost::tuples::null_type, boost::tuples::null_type,
boost::tuples::null_type, boost::tuples::null_type,
boost::tuples::null_type, boost::tuples::null_type>&>::operator()
(this=0xb6e15448)
at /usr/include/boost/bind/mem_fn_template.hpp:162
#4 operator()<bool, boost::_mfi::mf1 RTT::internal::ConnectionManager,
boost::tuples::tuple boost::intrusive_ptr<RTT::base::ChannelElementBase>,
boost::tuples::null_type, boost::tuples::null_type,
boost::tuples::null_type, boost::tuples::null_type,
boost::tuples::null_type, boost::tuples::null_type,
boost::tuples::null_type, boost::tuples::null_type>&>,
boost::_bi::list1<boost::tuples::tuple boost::intrusive_ptr<RTT::base::ChannelElementBase>,
boost::tuples::null_type, boost::tuples::null_type,
boost::tuples::null_type, boost::tuples::null_type,
boost::tuples::null_type, boost::tuples::null_type,
boost::tuples::null_type, boost::tuples::null_type>&> > (this=0xb6e15448) at
/usr/include/boost/bind/bind.hpp:296
#5
operator()<boost::tuples::tuple boost::intrusive_ptr<RTT::base::ChannelElementBase>,
boost::tuples::null_type, boost::tuples::null_type,
boost::tuples::null_type, boost::tuples::null_type,
boost::tuples::null_type, boost::tuples::null_type,
boost::tuples::null_type, boost::tuples::null_type> > (this=0xb6e15448) at
/usr/include/boost/bind/bind_template.hpp:32
#6 delete_if<boost::_bi::bind_t RTT::internal::ConnectionManager,
boost::tuples::tuple boost::intrusive_ptr<RTT::base::ChannelElementBase>,
boost::tuples::null_type, boost::tuples::null_type,
boost::tuples::null_type, boost::tuples::null_type,
boost::tuples::null_type, boost::tuples::null_type,
boost::tuples::null_type, boost::tuples::null_type>&>,
boost::_bi::list2<boost::_bi::value boost::arg<1> > > > (this=0xb6e15448) at
/home/hamelinp/orocos-toolchain-2.1.0/rtt/rtt/internal/ListLockFree.hpp:498
#7 RTT::internal::ConnectionManager::disconnect (this=0xb6e15448) at
/home/hamelinp/orocos-toolchain-2.1.0/rtt/rtt/internal/ConnectionManager.cpp:152
#8 0x00285350 in RTT::base::InputPortInterface::disconnect
(this=0xb6e15438) at
/home/hamelinp/orocos-toolchain-2.1.0/rtt/rtt/base/InputPortInterface.cpp:131
#9 0x0022a94a in RTT::TaskContext::disconnect (this=0xb6e15310) at
/home/hamelinp/orocos-toolchain-2.1.0/rtt/rtt/TaskContext.cpp:277
#10 0x0099b7b9 in OCL::DeploymentComponent::unloadComponentImpl
(this=0xbffff218, cit=...) at
/home/hamelinp/orocos-toolchain-2.1.0/ocl/deployment/DeploymentComponent.cpp:1264
#11 0x0099bb72 in OCL::DeploymentComponent::unloadComponents
(this=0xbffff218) at
/home/hamelinp/orocos-toolchain-2.1.0/ocl/deployment/DeploymentComponent.cpp:1167
#12 0x0099bbca in OCL::DeploymentComponent::kickOutAll (this=0xbffff218) at
/home/hamelinp/orocos-toolchain-2.1.0/ocl/deployment/DeploymentComponent.cpp:403
#13 0x0099c928 in ~DeploymentComponent (this=0xbffff218, __in_chrg=<value
optimized out>) at
/home/hamelinp/orocos-toolchain-2.1.0/ocl/deployment/DeploymentComponent.cpp:223
#14 0x00142565 in ~CorbaDeploymentComponent (this=0xbffff218,
__in_chrg=<value optimized out>) at
/home/hamelinp/orocos-toolchain-2.1.0/ocl/deployment/CorbaDeploymentComponent.cpp:94
#15 0x0804df5d in main (argc=<value optimized out>, argv=0xbffff434) at
/home/hamelinp/orocos-toolchain-2.1.0/ocl/bin/deployer-corba.cpp:180

Hi Philippe,

We already discuss about CORBA connection lost. On the mailling list the
subject was "CORBA connection lost"

Killing a server process or quit a server process close the socket
connection in a way that a client can see it. If you try to use the socket
connection after that , CORBA send a TRANSIENT exception.

The timeout connection can only be used if your client initOrb with timeout
arguments, and only if you disconnect the network cables so the socket will
not be closed but the client would not be able to get an answer.

>From what I remember, the behavor is the same in rtt 1.8 , 1.10 and 1.12.

Simon

On Mon, Nov 15, 2010 at 4:45 PM, Philippe Hamelin <
philippe [dot] hamelin [..] ...> wrote:

>
>
> 2010/11/15 Philippe Hamelin <philippe [dot] hamelin [..] ...>
>
> Hello,
>>
>> I'm having two strange Corba behavior with RTT-2.
>>
>> ---
>> The first one is on handling connection timeout. Here is the test case:
>>
>> - Load component A with the corba deployer
>> - In program B, Create a ControlTaskProxy to component A (no deployer,
>> just plain C++)
>> - Kill the process of component A (so the component still in the naming
>> server list)
>> - In program B, call getOperation(...) and then send().
>>
>> Since no timeout has been configured in InitOrb, I was hoping for one of
>> these two behaviors:
>>
>> 1. My first guess: the send() just normally execute, but the collect()
>> never returns
>> 2. My second guess: the send() just indefinitely blocks (like
>> method/command in RTT-1)
>>
>> However, we are getting this CORBA exception:
>>
>> system exception, ID 'IDL:omg.org/CORBA/TRANSIENT:1.0'OMG minor code (2),
>> described as 'No usable profile in IOR.', completed = NO
>>
>> According to this behavior, it's impossible to trigger CORBA Timeout
>> Exception as in RTT-1. Am I missing something?
>>
>> ---
>> The second strange behavior is with data ports. Here is the test case:
>>
>> - Load component A with the corba deployer
>> - Component A outputs periodicaly (100 Hz) data to output ports
>> - Connect to component A with the ctaskbrowser
>> - Quit the ctaskbrowser
>>
>> Then, in the log of component A we have these errors:
>>
>> 13.807 [ ERROR ][OrbRunner] caught CORBA exception while marshalling:
>> TRANSIENT
>> 13.814 [ ERROR ][OrbRunner] A channel of port MyOutputPort has been
>> invalidated during write(), it will be removed
>>
>> I'm having the same error when connecting the output port of component A
>> to another component. Is this normal?
>>
>>
>> Philippe
>>
>>
> I would also like to add a third strange behavior:
>
> - Load component A with corba deployer
> - Load component B (plain C++)
> - Connection output ports of A with input ports of B
> - In the deployer of A, quit()
>
> Then, we are having this error:
>
> 16.691 [ Info ][ShutdownOrb] Cleaning up TaskContextServers...
> 16.694 [ Info ][~TaskContextServer()] Successfully removed CTaskContext
> 'SpaceNav' from CORBA Naming Service.
> 16.697 [ Info ][~TaskContextServer()] Successfully removed CTaskContext
> 'Deployer' from CORBA Naming Service.
> 16.698 [ Info ][ShutdownOrb] Cleanup done.
> 16.698 [ Info ][ShutdownOrb] Orb Shutdown...waiting...
> 16.698 [ Info ][ShutdownOrb] Breaking out of orb->run().
> 16.698 [ Info ][Logger] done.
> 16.698 [ Info ][OrbRunner] Safely stopped.
> 16.698 [ Info ][DestroyOrb] Orb destroyed.
> 16.698 [ Info ][DeploymentComponent::stopComponents] Stopped SpaceNav
> 16.698 [ Info ][DeploymentComponent::cleanupComponents] Cleaned up
> SpaceNav
> 16.699 [ ERROR ][OrbRunner] deployer-corba-gnulinux ORO_main : CORBA
> exception raised!
> 16.699 [ ERROR ][OrbRunner] system exception, ID 'IDL:
> omg.org/CORBA/BAD_INV_ORDER:1.0'
> TAO exception, minor code = 0 (POA has been destroyed or is currently being
> destroyed; unspecified errno), completed = NO
>
> I can't figure this out, but it seems that we are trying to send something
> over CORBA while the POA is being destroyed.
>
>
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
>