Gordon Sim wrote:
Currently in a clustered broker, the object ids used for management
objects are not uniform across all nodes. This means that execution of
management methods does not reliably occur on all nodes (if the id on
which the method is invoked is for another object than intended on
other nodes).
The root cause of this is the fact that the state dump process creates
some management objects and as the traffic for that connection is not
replicated these only exist on the joining node. The id allocation
uses a sequential id, so these extra objects that only consume ids on
a joining member skews the allocation.
Attached is a patch that fixes this. Its a bit of a hack, just to show
the concept. I now plan to try and clean it up a little (essentially
avoiding the special 'qpid-dump' strings everywhere). However I
thought it would be worth sharing in case there are other issues or
better ideas. (Alan, Ted I'm particularly keen on your viewpoints).
Gordon,
It looks from the patch that you have added special logic to suppress
the creation of the management objects related to "qpid-dump". I think
there's a cleaner way to do this without removing management visibility
into the qpid-dump objects.
If you grep for uses of "addObject" in the cpp/src/qpid/broker
directory, you will see that there is an optional second argument to
this method. It is used for persistent objects. Persistent IDs include
those held in the store and also IDs of default objects (i.e. the amq.*
exchanges).
You can use a "persistent" number space (like 0x400000000000XXXXLL) for
the qpid-dump objects. This will allow them to be managed but will
prevent them from skewing the allocation of non-persistent IDs.
-Ted
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
