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).
A couple of specific points on the code:
General point: String literal "qpid-dump" should be a global std::string
constant for two reasons
- conversion of const char* to std::string is expensive, it causes a heap
allocation & copy on every call.
- repeating a "magic" literal value is error prone (e.g. typo "qpid_dump") and
makes it hard to change the value.
Also I'd suggest using a value that is illegal under AMQP rules to ensure
there's no possibility of clash with a user identifier. E.g.
// Illegal exchange/queue name for catch-up, avoid clashes with user
queues/exchanges.
static const char DUMP_CHARS[] = "\000qpid-dump";
const std::string DumpClient::DUMP(DUMP_CHARS, sizeof(DUMP_CHARS));
Now a more general design point: it's ugly to have reference to cluster
implementation details in the main broker code. What you're really doing is
marking certain connections and queues as "unmanaged". So why not introduce that
concept in the broker code, with a "managed" constructor parameter and then have
the cluster code create unmanged objects for use in dumps. THat avoids
mentioning cluster details in the broker code.
Finally: the existing DumpClient code already marks catch-up connections with a
special protocol version. I don't think you need to mark them again in the
vhost. In cluster::Connection you can isCatchup as the "unmanaged" flag to the
broker::Connection.
I'd prefer that plain broker code not refer to things that are implementation
artifacts of the cluster. Rather than exposing the use of "qpid-dump"
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
