So, as far as I understand, OpenWireResponseBuilder will be implemented within activemq-cpp-2.1 release?
tabish121 wrote: > > AMQCPP-130 > > http://issues.apache.org/activemq/browse/AMQCPP-130 > > > On Mon, 2007-06-18 at 06:51 -0700, Motl wrote: >> I am glad to hear that - because previously I was doing a special trick >> in my >> code to make it work: >> >> if (connectionFactoryClass == "dummy") // needed for Unit Testing >> { >> static TransportFactoryMapRegistrar registrar("dummy", new >> DummyTransportFactory() ); >> string dummyUrl = "dummy://127.0.0.1:23232&wireFormat=stomp"; >> return new ActiveMQConnectionFactory(dummyUrl); >> } >> return new ActiveMQConnectionFactory(brokerUrl); >> >> >> As I understand, OpenWireResponseBuilder isn't a skeleton class in fact - >> it >> only misses buildIncomingCommand() implementation to get everything >> ready. >> Could you please, specify the issue number? >> >> >> >> tabish121 wrote: >> > >> > Sorry, its hard to keep track of who's using which version. I created >> a >> > Jira issue to enhance the formerly DummyTransport and moved everything >> > into head as MockTransport this weekend. The MockTransport of now >> > registered always in the Transports registry so you don't need to do >> > anything special to use it just replace tcp with mock in the connection >> > uri. The OpenWireResponseBuilder is in the openwire connector folder, >> > its just a skeleton class at the moment. >> > >> > >> > >> > On Mon, 2007-06-18 at 04:20 -0700, Motl wrote: >> >> Thanks a lot. >> >> Now I see that DummyTransport differs seriously in HEAD, while I am >> using >> >> 2.0.1 version (at least, it is called MockTransport and is located >> under >> >> 'main' directory instead of 'test'). >> >> 2.0.1 version doesn't have buildIncomingCommand(), that could be the >> >> reason >> >> for blocking. >> >> Will give a shot with HEAD one. >> >> >> >> >> >> >> >> tabish121 wrote: >> >> > >> >> > You shouldn't need to change DummyTransport at all, or a least I >> don't >> >> > think so, I haven't really thought about this enough yet to be sure. >> >> > >> >> > You should have implemented a class called OpenWireResponseBuilder >> that >> >> > implements the ResponseBuilder interface defined in DummyTransport. >> >> > >> >> > class ResponseBuilder{ >> >> > public: >> >> > virtual ~ResponseBuilder(){} >> >> > >> >> > virtual Response* buildResponse( const Command* cmd ) = 0; >> >> > virtual Command* buildIncomingCommand( const Command* cmd ) = 0; >> >> > }; >> >> > >> >> > For commands that are sent via the request call, DummyTransport >> calls >> >> > buildResponse on the passed in ResponseBuilder. This is where you >> >> > implement the commands in openwire that come in as responses. >> >> > >> >> > For commands that are sent via a oneway call, the DummyTransport >> calls >> >> > buildIncomingCommand on the passed in ResponseBuilder and this is >> were >> >> > you implement anything that comes in asynchronously sometime after >> some >> >> > Command is sent. This is where you would implement the logic for >> >> > sending in a WireFormat info after the first time the >> >> > OpenWireFormatNegotiator sends its WireFormat. >> >> > >> >> > This code wasn't ever really intended to be used by anyone other >> than >> >> us >> >> > in our unit tests, so its not really documented all that well and >> may >> >> > not really fit the bill when brought into service by a larger >> audience, >> >> > so I can't say for sure if there won't be other changes needed in >> this >> >> > area. >> >> > >> >> > Regards >> >> > Tim >> >> > >> >> > On Fri, 2007-06-15 at 10:26 -0700, Motl wrote: >> >> >> So, should I make changes in DummyTransport to send WireFormat >> info? >> >> >> Should I do that only in methods that call responseBuilder or >> >> somewhere >> >> >> else? >> >> >> >> >> >> >> >> >> tabish121 wrote: >> >> >> > >> >> >> > Right, looks like the response builder isn't sending in a >> WireFormat >> >> >> and >> >> >> > the timeout in oneway is failing. >> >> >> > >> >> >> > On Fri, 2007-06-15 at 10:14 -0700, Motl wrote: >> >> >> >> 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#a11176573 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
