On 15/02/14 21:11, Robbie Gemmell wrote:
On 14 February 2014 09:20, Fraser Adams <[email protected]>wrote:
The message reported by drain says:
Message(properties={spout-id:88fc4a67-d71e-4b86-b967-f897306400e7:0},
subject='tim', content='Hello World')
So *something* thinks that there's a subject property set, but the
selector doesn't seem to see it.
I expect that means the 'subject' field of the 'properties' section of the
AMQP message is set, and not a 'property' called 'subject' in the
'application-properties' section (which is where the spout-id property is
presumably being set).
Thanks Robbie, yeah this had started to dawn on me yesterday. I was
looking through the C++ broker code and noticed in
<qpid>/cpp/src/qpid/broker/amqp/Message.cpp
std::string Message::getRoutingKey() const
{
std::string v;
v.assign(subject.data, subject.size);
return v;
}
which seems to be the only place where subject gets exposed - so it's in
a specific accessor not a general property one, then I remembered that
AMQP 1.0 has immutable properties in section 3.2.4 and application
properties in 3.2.5 and remembered that subject is one of the 3.2.4
properties.
in <qpid>/qpid-trunk/qpid/specs/apache-filters.xml it explains about
mapping the JMS headers and most of the JMS headers relate to 3.2.4
properties.
What I think is happening is that in AMQP 1.0 qpid::messaging used by
spout actually populates the AMQP 1.0 subject field correctly with the
subject, but when specifying subject in the Selector that's looking for
an *application property* called "subject". That'll be why the AMQP 0.10
thing works because the legacy "qpid.subject" actually *is* an
application property.
In <qpid>/cpp/src/qpid/broker/Selector.cpp there's a method:
const Value MessageSelectorEnv::specialValue(const string& id) const
That does the mappings mentioned in the apache-filters.xml
the method
const Value& MessageSelectorEnv::value(const string& identifier) const
Checks for the prefix "amqp." and if set calls specialValue() otherwise
it looks up the application properties.
Of the AMQP 1.0 section 3.2.4 properties it looks like
user-id
to
subject
reply-to
content-type
content-encoding
group-id
group-sequence
reply-to-group-id
Don't have any accessor in the Selector (though to and reply-to have a
comment "Hard to get this correct for both 1.0 and 0-10" though it might
be worth exposing them as a LIKE operator might help abstract the
differences) the group-id, group-sequence and reply-to-group-id don't
even appear to be extracted in Message.cpp from what I can see.
Anyway I'd *imagine* that it wouldn't be terribly hard to expand the
pattern used for the JMS Headers to allow access to some of these e.g.
Selector keys of
amqp.user_id
amqp.subject
amqp.content_type
amqp.content_encoding
Would make them visible to specialValue() where they could be added to
the if/else block and their specific accessors could then be called.
I don't know if there is any specific reason for not doing this other
than the original goal being to map JMS Message Selectors.
From my responses to Clive it would seem to suggest that subject at
least would be really useful to be exposed to a Selector especially as
it's a core routing attribute for other filter types.
I'd be interested to know what others think - it looks a fairly simple
addition.
Does anybody know how to specify the message subject as a property for a
Message Selector in AMQP 1.0???
As the filter in question is specifically only covering functionality
required for JMS (specifically mapping the JMS Headers to the relevant
fields in the AMQP headers and properties sections, and JMS properties to
the AMQP application-properties section) its not clear to me that it allows
for selection of the 'subject' field in the 'properties' section, because
that isn't used to map any of the JMS headers or property values and so
effectively isn't discussed.
[snip]
Yeah as mentioned above that looks about right. I've not looked in the
Java Broker Selector code, but I imagine that it does something similar
to the C++ code and looks for the "amqp." prefix but only covers the
3.2.4 properties mentioned in apache-filters.xml.
To my mind it doesn't seem unreasonable to extend this to subject (at
least) given that it's a key filtering property for other filters, but
it's probably worth a discussion.
Cheers,
Frase
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
