Hi,
trying to connect a PullConsumer to a PullSupplier of an EventChannel
fails due to bad dispatching of connect_pull_consumer() at the server
site. The following stack trace will illustrate the problem:
#0 0x010265c0 in POA_CosEventComm::PullSupplier::dispatch at
CosEventComm.cc:1393
#1 0x01026600 in POA_CosEventComm::PullSupplier::invoke at
CosEventComm.cc:1398
#2 0x00004974 in PullSupplier_skel2::invoke at CosEvent_impl.cc:181
#3 0x000049cc in ProxyPullSupplier_impl::invoke at CosEvent_impl.cc:
235
#4 0x03a632e4 in PortableServer::StaticImplementation::doinvoke at
poa_base.cc:415
#5 0x03a7b140 in MICOPOA::POA_impl::perform_invoke at poa_impl.cc:4005
#6 0x03a7bcbc in MICOPOA::POA_impl::local_invoke at poa_impl.cc:3564
#7 0x03a7c388 in MICOPOA::POA_impl::invoke at poa_impl.cc:3419
#8 0x039a98dc in CORBA::ORB::invoke_async at orb.cc:2580
#9 0x039c8dbc in MICO::IIOPServer::exec_invoke_request at iop.cc:5611
#10 0x039d2308 in MICO::IIOPServer::handle_invoke_request at iop.cc:
5675
#11 0x039d2724 in MICO::IIOPServer::handle_input at iop.cc:5528
#12 0x039d2de0 in MICO::IIOPServer::input_callback at iop.cc:6153
#13 0x03d0d99c in MICO::GIOPConn::input_ready_callback at iop.h:574
#14 0x039b92d0 in MICO::InputHandler::process at iop.cc:2267
#15 0x03c0ab04 in MICO::PassiveOperation::_run at operation.cc:236
#16 0x03c0ec9c in MICO::WorkerThread::_run at mt_manager.cc:346
#17 0x03c08ddc in MICOMT::Thread::_thr_startup at pthreads.cc:169
#18 0x03c08fa8 in MICOMT::Thread::ThreadWrapper at pthreads.cc:149
#19 0x9002b908 in _pthread_body
At line #3 the ProxyPullSupplier_impl is asked for invokation of the
addressed method. It forwards it to PullSupplier_skel2::invoke() in
line #2 which at last results in calling PullSupplier::dispatch()
which doesn't understand a connect_pull_consumer() message. As a
result you will get "IDL:omg.org/CORBA/BAD_OPERATION:1.0 (0, not-
completed)" at your clients site.
Because there are some other "hacks" I don't really understand (not
even at 4 o'clock in the morning) related to this PullSupplier_skel2
stuff I will at first ask the community how to fix the bug.
The other "hacks" are those around the pull() stuff here.
ProxyPullSupplier_impl implements two different pull methods. But the
invoke/dispatch mechanism maps it to only one of them by not
distinguishing between there different signatures. If this is
intended it seems to be really a hack.
Finally I don't understand the "empty" implementation of
ProxyPullSupplier_impl::pull(). Should the caller be notified about
some ordered data in the 'notify(any)' call in 'void
ProxyPullSupplier_impl::pull (CORBA::StaticServerRequest_ptr req)'?
Thanks for help.
PS: I really learned debugging when looking for this bug: Debugging 2
processes, one with 8 running threads simultaneously and lot of code
I've never seen before... But the symbols well nomenclature was very
helpful.
--
Thomas Schmidt
Schneiderstr. 16
D-29575 Altenmedingen
Phone: +49-5807-209976
Cellular: +49-172-3011505
Skype: ThCSchmidt
Email: 01723011...@vodafone.de
PGP: Key-ID: 0x810B6206
_______________________________________________
Mico-devel mailing list
Mico-devel@mico.org
http://www.mico.org/mailman/listinfo/mico-devel
