activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Timothy Bish <tim.b...@sensis.com>
Subject Re: stomp::commands::ConnectedCommand openwire analog
Date Mon, 18 Jun 2007 13:57:07 GMT
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 
> >> >> >> > 
> >> >> >> 
> >> >> > 
> >> >> > 
> >> >> 
> >> > 
> >> > 
> >> 
> > 
> > 
> 

Mime
View raw message