With my current OpenWireResponseBuilder, application is stuck at that point:
thread 1: #0 0x0000003709508b9f in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0 #1 0x0000002a957ec5b0 in activemq::concurrent::Mutex::wait () from /home/motl/new/nmf/cpp/nmflib_cpp/sharedlib/target/linux_x64_gcc/debug/libnmf_cpp_shared.so #2 0x0000002a958d3ac6 in activemq::concurrent::CountDownLatch::await () from /home/motl/new/nmf/cpp/nmflib_cpp/sharedlib/target/linux_x64_gcc/debug/libnmf_cpp_shared.so #3 0x0000002a9589c805 in activemq::connector::openwire::OpenWireFormatNegotiator::request () from /home/motl/new/nmf/cpp/nmflib_cpp/sharedlib/target/linux_x64_gcc/debug/libnmf_cpp_shared.so #4 0x0000002a95856450 in activemq::connector::openwire::OpenWireConnector::syncRequest () from /home/motl/new/nmf/cpp/nmflib_cpp/sharedlib/target/linux_x64_gcc/debug/libnmf_cpp_shared.so #5 0x0000002a9584f7bc in activemq::connector::openwire::OpenWireConnector::connect () from /home/motl/new/nmf/cpp/nmflib_cpp/sharedlib/target/linux_x64_gcc/debug/libnmf_cpp_shared.so #6 0x0000002a9584f122 in activemq::connector::openwire::OpenWireConnector::start () from /home/motl/new/nmf/cpp/nmflib_cpp/sharedlib/target/linux_x64_gcc/debug/libnmf_cpp_shared.so #7 0x0000002a957e9bf5 in activemq::core::ActiveMQConnectionFactory::createConnection () thread 2: #0 0x00000037095089aa in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0 #1 0x0000002a957ec5c6 in activemq::concurrent::Mutex::wait () from /home/motl/new/nmf/cpp/nmflib_cpp/sharedlib/target/linux_x64_gcc/debug/libnmf_cpp_shared.so #2 0x0000002a957ec3dd in activemq::concurrent::Mutex::wait () from /home/motl/new/nmf/cpp/nmflib_cpp/sharedlib/target/linux_x64_gcc/debug/libnmf_cpp_shared.so #3 0x0000002a9578bc6a in activemq::transport::DummyTransport::InternalCommandListener::run (this=0x510cc0) May be it helps to tell me what I am doing wrong. Motl wrote: > > I have attached my version of OpenWireResponseBuilder and also modified > version of DummyTransportFactory. > Could you point to the places in the code where I should put > OpenwireFormatNegotiator::oneway() call. > Or may be it should be done in DummyTransport file? Sorry for annoying > questions, but I have no any idea about dataflow within activemq-cpp. > > Thanks > > > tabish121 wrote: >> >> OpenwireFormatNegotiator is a TransprFilter, it wraps whatever transport >> is passed into the OpenWireConnector. The very first call to oneway I >> think it is on this TransportFilter waits for the Broker to send its >> WireFormatInfo and then in the OnCommand it negotiates for >> WireFormatInfo details like the version of Openwire that it supports. >> >> Response doesn't need a setSessionId, look very closely at the >> OpenWireConenctor::createSession method, we set the sessionId on the >> outgoing message. >> >> >> On Fri, 2007-06-15 at 05:06 -0700, Motl wrote: >>> Sorry, I haven't found the place where OpenWireFormatNegotiator::start() >>> is >>> called, so I don't understand why it should be added to >>> OpenWireResponseBuilder. Another question is: >>> openwire::commands::Response >>> doesn't have setSessionId method, how should I set SessionId for the >>> generated response? >>> >>> Thanks, >>> Matvey >>> >>> >>> tabish121 wrote: >>> > >>> > Take a look at OpenWireFormatNegotiator.cpp there is an initial >>> exchange >>> > of wireformat info between broker and client to establish what version >>> > of openwire etc each supports. >>> > >>> > On Thu, 2007-06-14 at 08:42 -0700, Motl wrote: >>> >> Sorry, what do you mean by sending WireFormatInfo at the initial >>> >> connection? >>> >> Isn't it done by createConnection() by specifying >>> ""wireFormat=openwire" >>> >> in >>> >> brokerURL? >>> >> >>> >> Matvey >>> >> >>> >> >>> >> tabish121 wrote: >>> >> > >>> >> > If you look at the code in the OpenwireConnector you can get an >>> idea of >>> >> > what messages require what responses. In the case of Connect, >>> there is >>> >> > a response that is needed i.e Response command. You will also need >>> to >>> >> > send a proper WireFormatInfo when the initial connection is made so >>> >> that >>> >> > the OpenwireWireFormatNegotiator will get the response its >>> expecting. >>> >> > >>> >> > A good way to see the message traffic is to connect to a broker >>> with >>> >> > transport.commandTracingEnabled=true in the URI. This will cause >>> the C >>> >> > ++ client to log the console all the Commands that are exchanged >>> with >>> >> > the Broker, you can use this as a guide when implementing the >>> Response >>> >> > Builder class. >>> >> > >>> >> > Regards >>> >> > Tim >>> >> > >>> >> > On Thu, 2007-06-14 at 07:00 -0700, Motl wrote: >>> >> >> I am writing unit tests for the application that uses activemqcpp >>> >> >> library. >>> >> >> Using DummyTransport is nice for that purpose, but it only >>> supports >>> >> stomp >>> >> >> at >>> >> >> the moment, that misses TemporaryQueue implementation, and it's >>> quite >>> >> >> important functionality for me. >>> >> >> Following your advice, I am started implementing >>> >> OpenWireResponseBuilder. >>> >> >> I >>> >> >> don't know the internals of ativemq-cpp library, so it's quite >>> >> blindfold >>> >> >> way >>> >> >> for me ) >>> >> >> >>> >> >> Finally, the question is: which "openwire class" corresponds to >>> "stomp >>> >> >> class" commands::ConnectedCommand? >>> >> >> >>> >> >> I tried to use openwire::BaseCommand template, but what class >>> should I >>> >> >> instantiate it with? >>> >> >> >>> >> >> Thanx a lot >>> >> > >>> >> > >>> >> >>> > >>> > >>> >> >> > http://www.nabble.com/file/p11140232/OpenWireResponseBuilder.h > OpenWireResponseBuilder.h > http://www.nabble.com/file/p11140232/DummyTransportFactory.h > DummyTransportFactory.h > -- View this message in context: http://www.nabble.com/OpenWireResponseBuilder-implementation-tf3921969s2354.html#a11144056 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
