activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Motl <m...@orcsoftware.com>
Subject Re: stomp::commands::ConnectedCommand openwire analog
Date Mon, 18 Jun 2007 13:51:46 GMT

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#a11176044
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.


Mime
View raw message