You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by Motl <mo...@orcsoftware.com> on 2007/06/14 16:00:32 UTC
stomp::commands::ConnectedCommand openwire analog
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
--
View this message in context: http://www.nabble.com/stomp%3A%3Acommands%3A%3AConnectedCommand-openwire-analog-tf3921969s2354.html#a11120834
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
Re: stomp::commands::ConnectedCommand openwire analog
Posted by Motl <mo...@orcsoftware.com>.
May be OpenwireFormatNegotiator::oneway() should be called from:
DummyTransport::oneway( Command* command )
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#a11140561
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
Re: stomp::commands::ConnectedCommand openwire analog
Posted by Timothy Bish <ti...@sensis.com>.
Actually the OpenWireFormatNegotiator wraps around the other Transports,
so you don't need to call that at all.
You really need to dissect the OpenWireConnector to understand the
messages, that class handles all the messaging for Openwire save for the
WireFormat negotiation, which is doe in OpenWireFormatNegotiator
If you look at the code for OpenWireFormatNegotiator you see that in its
start method it sends a WireFormat command to the broker.
////////////////////////////////////////////////////////////////////////////////
void OpenWireFormatNegotiator::start() throw( cms::CMSException ){
/**
* We're already started.
*/
if( !closed ){
return;
}
if( commandlistener == NULL ){
throw exceptions::ActiveMQException(
__FILE__, __LINE__,
"OpenWireFormatNegotiator::start - "
"commandListener is invalid" );
}
if( exceptionListener == NULL ){
throw exceptions::ActiveMQException(
__FILE__, __LINE__,
"OpenWireFormatNegotiator::start - "
"exceptionListener is invalid" );
}
if( next == NULL ){
throw exceptions::ActiveMQException(
__FILE__, __LINE__,
"OpenWireFormatNegotiator::start - "
"next transport is NULL" );
}
if( openWireFormat == NULL ){
throw exceptions::ActiveMQException(
__FILE__, __LINE__,
"OpenWireFormatNegotiator::start - "
"openWireFormat is NULL" );
}
// Start the delegate transport object.
next->start();
if( firstTime == true ) {
try {
// The First Time is now over with
firstTime = false;
// We first send the WireFormat that we'd prefer.
next->oneway( openWireFormat->getPreferedWireFormatInfo() );
// Mark the latch
wireInfoSentDownLatch.countDown();
} catch( ActiveMQException& ex ) {
// Mark the latch
wireInfoSentDownLatch.countDown();
ex.setMark( __FILE__, __LINE__ );
throw ex;
}
}
// Mark it as open.
closed = false;
}
Now in the OpenWireFormatNegotiator's oneway method it won't let any
messages out until the broker has responded with its WireFormat
////////////////////////////////////////////////////////////////////////////////
void OpenWireFormatNegotiator::oneway( Command* command )
throw( CommandIOException,
exceptions::UnsupportedOperationException ) {
try{
if( closed || next == NULL ){
throw CommandIOException(
__FILE__, __LINE__,
"OpenWireFormatNegotiator::oneway - transport already
closed" );
}
if( !readyCountDownLatch.await( negotiationTimeout ) ) {
throw CommandIOException(
__FILE__,
__LINE__,
"OpenWireFormatNegotiator::oneway"
"Wire format negociation timeout: peer did not "
"send his wire format." );
}
next->oneway( command );
}
AMQ_CATCH_RETHROW( exceptions::UnsupportedOperationException )
AMQ_CATCH_RETHROW( CommandIOException )
AMQ_CATCH_EXCEPTION_CONVERT( exceptions::ActiveMQException,
CommandIOException )
AMQ_CATCHALL_THROW( CommandIOException )
}
If you look at the OpenWireFormatNegotiator's onCommand method you see
its response to receiving a WireFormat command.
////////////////////////////////////////////////////////////////////////////////
void OpenWireFormatNegotiator::onCommand( Command* command ) {
DataStructure* dataStructure =
dynamic_cast<DataStructure*>( command );
if( dataStructure != NULL &&
dataStructure->getDataStructureType() ==
WireFormatInfo::ID_WIREFORMATINFO ) {
WireFormatInfo* info =
dynamic_cast<WireFormatInfo*>( dataStructure );
try {
if( !info->isValid() ) {
throw CommandIOException(
__FILE__,
__LINE__,
"OpenWireFormatNegotiator::onCommand"
"Remote wire format magic is invalid" );
}
wireInfoSentDownLatch.await( negotiationTimeout );
openWireFormat->renegotiateWireFormat( info );
readyCountDownLatch.countDown();
} catch( exceptions::ActiveMQException& ex ) {
readyCountDownLatch.countDown();
fire( ex );
}
}
// Send along to the next interested party.
fire( command );
}
So in your response builder you should send only once a WireFormat
command back to the client in response to the initial send of a
WireFormat command. This could just be a cloned copy of the callers,
which would just allow it to assume its preferred wireformat is
acceptable to the broker.
The idea of the response builder is that its emulating all the commands
to come in from the broker, either synchronously in the case of
responses to requests, or asynchronously as in the case of the
WireFormat negotiation.
On Fri, 2007-06-15 at 07:07 -0700, 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/DummyTransport.h DummyTransport.h
> http://www.nabble.com/file/p11140232/OpenWireResponseBuilder.h
> OpenWireResponseBuilder.h
Re: stomp::commands::ConnectedCommand openwire analog
Posted by Timothy Bish <ti...@sensis.com>.
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
> >> >> >> >> >
> >> >> >> >>
> >> >> >> >
> >> >> >> >
> >> >> >>
> >> >> >
> >> >> >
> >> >>
> >> >
> >> >
> >>
> >
> >
>
Re: stomp::commands::ConnectedCommand openwire analog
Posted by Motl <mo...@orcsoftware.com>.
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
>> >> >> >> >
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >>
>> >> >
>> >> >
>> >>
>> >
>> >
>>
>
>
--
View this message in context: http://www.nabble.com/OpenWireResponseBuilder-implementation-tf3921969s2354.html#a11176573
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
Re: stomp::commands::ConnectedCommand openwire analog
Posted by Timothy Bish <ti...@sensis.com>.
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
> >> >> >> >
> >> >> >>
> >> >> >
> >> >> >
> >> >>
> >> >
> >> >
> >>
> >
> >
>
Re: stomp::commands::ConnectedCommand openwire analog
Posted by Timothy Bish <ti...@sensis.com>.
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
> >> >> >> >
> >> >> >>
> >> >> >
> >> >> >
> >> >>
> >> >
> >> >
> >>
> >
> >
>
Re: stomp::commands::ConnectedCommand openwire analog
Posted by Motl <mo...@orcsoftware.com>.
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.
Re: stomp::commands::ConnectedCommand openwire analog
Posted by Timothy Bish <ti...@sensis.com>.
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
> >> >> >
> >> >>
> >> >
> >> >
> >>
> >
> >
>
Re: stomp::commands::ConnectedCommand openwire analog
Posted by Motl <mo...@orcsoftware.com>.
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.
Re: stomp::commands::ConnectedCommand openwire analog
Posted by Timothy Bish <ti...@sensis.com>.
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
> >> >
> >>
> >
> >
>
Re: stomp::commands::ConnectedCommand openwire analog
Posted by Motl <mo...@orcsoftware.com>.
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#a11144247
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
Re: stomp::commands::ConnectedCommand openwire analog
Posted by Timothy Bish <ti...@sensis.com>.
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
> >
>
Re: stomp::commands::ConnectedCommand openwire analog
Posted by Motl <mo...@orcsoftware.com>.
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#a11144056
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
Re: stomp::commands::ConnectedCommand openwire analog
Posted by Motl <mo...@orcsoftware.com>.
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/DummyTransport.h DummyTransport.h
http://www.nabble.com/file/p11140232/OpenWireResponseBuilder.h
OpenWireResponseBuilder.h
--
View this message in context: http://www.nabble.com/OpenWireResponseBuilder-implementation-tf3921969s2354.html#a11140232
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
Re: stomp::commands::ConnectedCommand openwire analog
Posted by Timothy Bish <ti...@sensis.com>.
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
> >> >
> >> >
> >>
> >
> >
>
Re: stomp::commands::ConnectedCommand openwire analog
Posted by Motl <mo...@orcsoftware.com>.
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
>> >
>> >
>>
>
>
--
View this message in context: http://www.nabble.com/StompResponseBuilder-implementation-tf3921969s2354.html#a11138045
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
Re: stomp::commands::ConnectedCommand openwire analog
Posted by Timothy Bish <ti...@sensis.com>.
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
> >
> >
>
Re: stomp::commands::ConnectedCommand openwire analog
Posted by Motl <mo...@orcsoftware.com>.
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
>
>
--
View this message in context: http://www.nabble.com/stomp%3A%3Acommands%3A%3AConnectedCommand-openwire-analog-tf3921969s2354.html#a11122869
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
Re: stomp::commands::ConnectedCommand openwire analog
Posted by Timothy Bish <ti...@sensis.com>.
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