That all sounds great - particularly the bit about contributing changes back to the project :)
The best place to start is probably to write your own TransportFilter to do the stuff you need (allowing pause/resume/monitor throughput etc etc). If you need closer integration with the TCP layer you might even wanna inherit from the TcpTransport* stuff. (e.g. you might wanna add hooks to the TcpInputStream/TcpOuputStream to count the bytes moved etc). To simplify the integration; it might be easiest for each of your custom TransportFilter implementations to lookup in JMX some controller MBean that can be used as a single point to hold the policy information and act as a global start/stop guage etc. (Or worst case, a static variable :) Please do let us know how you get on & please do submit any patches that helps you implement this feature... http://activemq.apache.org/contributing.html On 3/2/07, jkurtz <[EMAIL PROTECTED]> wrote:
James Again, thanks for taking the time to help. We got some feedback from the customer, they want to be able to do the Quality of Service measurements and control from outside of Active MQ. We still want to control the transport, turning it on and off, but we want to empower the Broker object to do this. However, if you can think of a better way to control transmission externally, please let me know. We would like to add the methods "stopTransport" and "startTransport" to the broker object, then modify the TcpTransportServer or other class to implement this. We would this to work across all connections. The QoS engine would then utilize an Embedded Broker application to control the message flow. Placing control outside of ActiveMQ allows for the measurement and Qos algoritms to be changed without having to modify the Active MQ source code. Any changes we make and the documentation will be released for evaluation and hopefully integration back into the main Active MQ branch. Adding the QoS capability increases the usefulness of this, as Active MQ can be used as a means of controlling network traffic. thanks much John ======================== James.Strachan wrote: > > On 2/6/07, jkurtz <[EMAIL PROTECTED]> wrote: >> >> The reason that the dispatch needs to be paused on the Server side is for >> a >> Quality of Service Broker to control the message dispatch if the network >> traffic gets to be too much. This is similar to the client Pre-Fetch >> Limit, >> except the messages are measured and controlled on servicer hosting the >> Active MQ instance, and not the client. >> >> We want to create a server-side implementation of the prefetch limit. >> Instead of using the client acknowledgements to control messaging, we >> want >> to use QoS service parameters on the Server to pause the dispatch. >> >> I can provide more details if you wish. > > OK I get it now, thanks. It sounds like the best thing to do is to > write your own derivation of TcpTransportFactory and > TcpTransportServer overloading the createTransport() method as its > only the broker side you need to change - so that each Transport that > gets created for each connection to the broker gets wrapped in your > own TransportFilter wrapper object which does the flow control (only > allowing so many bytes per second or whatever). Whether you want to do > the flow control across all connections, or on a per connection basis > is your call. > > By all means ask for more help as you try to implement this (maybe > chatting further on dev@activemq.apache.org is better) - if you would > like to donate a patch we could make this a standard feature of > ActiveMQ. e.g. we could use a property on the TcpTransportServer to > indicate the throttling rate to use, which if its set we wrap the > TcpTransport in a throttler TransportFilter. > > -- > > James > ------- > http://radio.weblogs.com/0112098/ > > -- View this message in context: http://www.nabble.com/Pausing-Transmission-tf3167927s2354.html#a9270539 Sent from the ActiveMQ - User mailing list archive at Nabble.com.
-- James ------- http://radio.weblogs.com/0112098/
