On 03/22/2010 02:06 PM, Robert Godfrey wrote:
On 22 March 2010 14:36, Ted Ross<[email protected]> wrote:
On 03/17/2010 01:39 PM, Gordon Sim wrote:
On 03/17/2010 04:43 PM, Robert Godfrey wrote:
On 16 March 2010 18:50, Gordon Sim<[email protected]> wrote:
On 03/15/2010 10:33 PM, Joan Bellver Faus wrote:
Exception in thread "Thread-3"
org.apache.qpid.console.ConsoleException:
org.apache.qpid.transport.SessionException: ch=0 id=0
ExecutionException(errorCode=NOT_ALLOWED, commandId=10, classCode=7,
commandCode=1, fieldIndex=0, description=not-allowed: Exchange declared
to be of type management-topic, requested management
(qpid/broker/SessionAdapter.cpp:121), errorInfo={})
at org.apache.qpid.console.Broker.tryToConnect(Broker.java:421)
at org.apache.qpid.console.Broker.<init>(Broker.java:87)
at org.apache.qpid.console.Session.addBroker(Session.java:70)
at MMS_Example.MMS.execute(MMS.java:39)
at es.upv.dsic.gti_ia.core.BaseAgent.run(BaseAgent.java:290)
at java.lang.Thread.run(Thread.java:619)
[snip]
any idea that happens?
The type of the management exchange has been changed[1] and the java
based
QMF support needs to be updated.
Why has the type been changed? Have I missed the discussion that must
have
occurred before such a change was made... this change would seem to have
implications both for clients (as demonstrated here) and for others
implementing management exchanges (for instance the Java Broker).
From the commit it looks like a QMFv2 related change. I haven't been
following all the design docs around that.
However it does seem like this would break backwards compatibility for
QMFv1. Must we change the type? If this is for QMFv2 and we want to keep
QMFv1 support, it may be better to keep the old name and pick some new ones
for v2?
This is my fault. I assumed (because it's true in C++, Python, and Ruby)
that the exchange type-name was not significant from the API perspective.
Since the JMS API requires you to declare every exchange you use, the
change broke the Java console.
The change I made was to create a pair of management exchange types (one
with direct routing and one with topic routing) for use as entry hooks for
the broker's QMFv2 agent. Previously there was only one exchange (the topic
exchange).
My preference would be to make the change on the Java console side but I
could also revert the type-name from "management-topic" back to
"management".
I apologize for breaking the Java QMF console.
The above doesn't make a great deal of sense to me to be honest. Why add a
new type? Why change the type of the existing management exchange (which is
only used by the management exchange)? And what is the point of having a
direct type when the only difference between direct and topic is that topic
allows for wildcards (or, put the other way, the only functionality that the
direct exchange has that the topic doesn't is the ability to have "direct"
mapping on routing keys containing the strings ".*." and ".#.")
What exactly is the requirement here... and why does the type(-name) of the
existing management exchange have to be changed?
-- Rob
[We should probably move this to dev]
The reasons for adding new exchange types are driven primarily by the
way the C++ broker code is built. There is no good reason from an AMQP
standpoint to introduce new exchange types. All we really want is a
standard topic exchange that can route messages to an internal
process/thread in the broker. Ideally, the broker would be able to
subscribe to one of its own queues and receive management messages.
This would allow standard exchanges to be used for management. In
discussions with members of the C++ broker team, it was decided that
this would be too difficult/disruptive to implement.
The alternate approach chosen was to extend the topic exchange to
intercept management messages before they are routed. Unfortunately
this requires that the extension exchange have a distinct name, thus the
introduction of the "management" exchange.
With regard to using the topic exchange for both "direct" and wildcarded
keys, this would be a valid design alternative. The use of a direct
exchange for reply messages comes from what I perceive as the
recommended pattern for direct replies and also the fact that direct
exchanges have a more efficient routing algorithm than do topic exchanges.
The name of the existing management exchange did not have to be changed
and I will happily change it back.
-Ted
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
