qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Ross <tr...@redhat.com>
Subject Re: [qmf]: type change and backward compatibility (was Re: Problem with Session.addBroker(), Exchange names beginning with "amq." or "qpid." are reserved.)
Date Mon, 22 Mar 2010 18:52:24 GMT
On 03/22/2010 02:06 PM, Robert Godfrey wrote:
> On 22 March 2010 14:36, Ted Ross<tross@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<gsim@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.


Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org

View raw message