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 14:21:23 GMT
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 
> >> >> >> >> > 
> >> >> >> >> 
> >> >> >> > 
> >> >> >> > 
> >> >> >> 
> >> >> > 
> >> >> > 
> >> >> 
> >> > 
> >> > 
> >> 
> > 
> > 
> 

Mime
View raw message