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/
