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:17:37 GMT
I've submitted a partially functional version of OpenWireResponseBuilder
to trunk, it doesn't deliver outgoing messages like text and bytes back
to the transport asynchronously yet, but at least it can connect and
process all the basic request messages.

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