That's the plan.
On Mon, 2007-06-18 at 07:18 -0700, Motl wrote: > 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 > >> >> >> >> > > >> >> >> >> > >> >> >> > > >> >> >> > > >> >> >> > >> >> > > >> >> > > >> >> > >> > > >> > > >> > > > > >
