Gordon,
Re "However, I am not sure whether the selector can select on the
subject/routing-key"
The spout and drain examples I posted earlier actually do work (using
qpidd, I've not tried it with the Java Broker to be fair), but those
were examples using AMQP 0.10
e.g.
./drain -b localhost -f \
"queue1; {create: receiver, link: {name: test-link, selector:
\"qpid.subject='tim'\"}}"
as you can see this is specifying a selector testing the qpid.subject
property equals tim, which in AMQP 0.10 gets set automagically when I do
./spout -b localhost --content "Hello World" "queue1/tim"
Because the subject (in AMQP 0.10) actually gets automagically mapped to
qpid.subject (essentially an application property) this all does
actually hang together with AMQP 0.10 using qpidd and qpid::messaging
without "any handling of that as a special value"
With AMQP 1.0 subject is an "immutable property" not an "application
property" so uses its own accessor (you of course know this better than
most :-)) so would need some code in the selector implementation to
explicitly expose it for matching.
You might well be right that the JavaBroker would reject this as invalid
as a selector, I've been bitten by my use of hyphens in property names
being rejected, but the qpid.subject definitely worked for me the last
time I tried it on qpidd.
Although not part of the JMS selector specification I do actually think
that being able to use the subject as a pseudo-property for message
selectors is pretty useful and something that I suspect most people
might "intuitively" expect to be able to do. I definitely think it'd be
good to have a consistent mechanism to enable this, as I say I was
intending to look at it 'cause it ought not to be too hard, but I've
been distracted on my JavaScript Proton port (though I can *finally* see
the light at the end of the tunnel on that :-)).
Frase
On 06/06/14 13:24, Gordon Sim wrote:
Clarification:
Over AMQP 1.0, the c++ qpid::messaging client will set a subject
filter on link from the queue. The c++ broker will then treat that
much like a message selector, except that it is a match against
subject rather than anything more complex. On 0-10 the c++ client is
like the python one, and the subject is ignored for a receiver.
On 06/06/2014 11:48 AM, Fraser Adams wrote:
On the subject (pun!!) of "If on the other hand you use an address where
the 'node' is a queue, i.e. <queue>/<key>" if that's the behaviour that
is actually required (though I'd personally use the exchange/queue
approach) I *wonder* if it could be achieved via message selectors.
You can certainly control the arguments sent in the subscription, and
thus specify a selector to use.
The c++ broker does now support selectors also, however the syntax is
as defined for the registered AMQP 1.0 selector-filter (you can use it
over 0-10 as well however) which is like the JMS syntax, but with a
different convention for naming the special fields. The java broker
supports the JMS selector syntax unmodified. The key used in the
argument also varies. (This is something that would not be difficult
to make more uniform and simpler).
However, I am not sure whether the selector can select on the
subject/routing-key. Looking at the c++ brokers code, I can't see any
handling of that as a special value nor can I find anything in the JMS
spec.
Now, the qpid.messaging (and qpid::messaging) clients will set a
qpid.subject header on messages they send, with the value being the
subject on the message (which will be the subject specified in the
sender address by default). So providing the messages were sent by
those APIs, you could select on qpid.subject.
However as Fraser has previously pointed out that is not a valid JMS
name, so it may be rejected by the java broker(?) as invalid within a
selector.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
