Hi Gordon, You're correct. The "enable v2" flag to the broker allows the broker to *send* V2-style unsolicited messages - heartbeats + events + data updates. As you noted, even if the v2 flag is turned off, the broker will support queries/method calls from v2 (and v1) clients.
The current behaviour - sending just v1-style - was merely the "safe" option when we first implemented dual-version qmf support in the broker. Enabling both by default should be safe - the only visible impact will be doubling the amount of generated unsolicited data. -K ----- Original Message ----- > On 02/11/2011 01:10 PM, Gordon Sim wrote: > > I have a related question: by default the broker does not support > > QMFv2 > > events it seems. There is a qpidd option to turn qmfv2 on which > > addresses that. However even without that option on other aspects of > > QMFv2 are supported (e.g. method invocation and querying). Is there > > a > > reason for having the v2 events disabled by default? > > Enabling the qmfv2 option causes one test failure: > cluster_tests.ShortTests.test_route_update, however that actually > appears to be due to the fact that enabling qmfv2 disables qmfv1. With > both enabled make check passes. > > Any objections to applying the attached patch to enable events for > qmfv2? Only question I guess is what turning this option off actually > means as it doesn't seem to prevent QMFv2 being used in general (just > events as far as I have seen). > > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
