You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Gordon Sim <gs...@redhat.com> on 2010/03/17 18:39:13 UTC
[qmf]: type change and backward compatibility (was Re: Problem with
Session.addBroker(), Exchange names beginning with "amq." or "qpid." are
reserved.)
On 03/17/2010 04:43 PM, Robert Godfrey wrote:
> On 16 March 2010 18:50, Gordon Sim<gs...@redhat.com> 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?
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: [qmf]: type change and backward compatibility (was Re: Problem
with Session.addBroker(), Exchange names beginning with "amq." or "qpid."
are reserved.)
Posted by Ted Ross <tr...@redhat.com>.
On 03/22/2010 02:06 PM, Robert Godfrey wrote:
> On 22 March 2010 14:36, Ted Ross<tr...@redhat.com> 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<gs...@redhat.com> 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:users-subscribe@qpid.apache.org
Re: [qmf]: type change and backward compatibility (was Re: Problem
with Session.addBroker(), Exchange names beginning with "amq." or "qpid." are
reserved.)
Posted by Robert Godfrey <ro...@gmail.com>.
On 22 March 2010 14:36, Ted Ross <tr...@redhat.com> 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<gs...@redhat.com> 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
-Ted
>
>
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:users-subscribe@qpid.apache.org
>
>
Re: [qmf]: type change and backward compatibility (was Re: Problem
with Session.addBroker(), Exchange names beginning with "amq." or "qpid."
are reserved.)
Posted by Ted Ross <tr...@redhat.com>.
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<gs...@redhat.com> 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.
-Ted
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org