Hiram,
BTW, did you run the activemq-cpp cpp-unit tests against the broker with the
new stomp transport? I took a look at your code and it looks like you still
have the request-id/response-id headers in there, so it should work fine.
Looks a lot simpler - easier to find your way around.
Nate
On 7/4/06, James Strachan [EMAIL PROTECTED] wrote:
It all looks good to me. Given we've already hit AMQ-793 recently...
http://issues.apache.org/activemq/browse/AMQ-793
due to the flow control issues in the stomp implementation under load,
I'd say lets get rid of the old version and go with the new.
On 7/2/06, Hiram Chirino [EMAIL PROTECTED] wrote:
Howdy STOMP developers,
Just wantted to let you know that I spent the day doing some major
refactoring to the STOMP server side protocol implementation in
ActiveMQ.
The previous implementation did all the work inside a WireFormat
layer. The
poll model that it imposed made some things difficult to do and made the
code just ugly.
I refactored it so that StompWireFormat takes the STOMP frames and
produces
StompCommand objects which are like a 1:1 mapping (Perhaps I should
rename
that to StompFrame). Then the stomp transport factory sets up the
TcpTransport to be filtered by a StompTransportFilter which converts the
StompCommand/Protocol into the ActiveMQ commands and Protocol. Since
the
Transport is more event based and is also aware of the transport
lifecycle,
it should let us continue to extend and add more features to the STOMP
protocol easier.
I implemented this in a new package so that we can easily switch back to
the
old implementation if needed. Out of the box we are now using the new
implementation. But I'd like to get some feed back to see if it
introduced
any new bugs or if it fixed any old bugs. If all goes well, I'll get
rid of
the old version soon.
--
Regards,
Hiram
Blog: http://hiramchirino.com
--
James
---
http://radio.weblogs.com/0112098/
