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 11:20:33 GMT

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


Mime
View raw message