On 04/27/2010 08:57 AM, Cajus Pollmeier wrote:
Hi. Yes. I'm using trunk for testing now.
While the documentation refers to "-a address", the code in trunk uses just
"address".
Yes, there are some differences between the c++ and python arguments at
present and that is one of them. (Hopefully I'll fix that one shortly).
The address-file option is a nice one also,
I've added "-a addressfile" to the local drain version to not waste the time
with shell escapes.
Seems like the todo file is right: xquery does not work right now. If you think
it should:
xml; {
node: {
x-bindings: [
{
exchange: xml,
queue: message_queue,
key: weather,
arguments: {
xquery: "let $w := ./weather; return $w/station =
'somewhere'"
}
}
]
}
}
The x-bindings in the node properties will only be enacted if you turn
the create policy on (e.g. create: always). There is an issue there as
well however in the receiver case.
Creating a receiver for an address that resolves to an exchange results
in the client creating a subscription queue and binding it to that
exchange. There is some detail in the docs around how this is handled
for the different exchange types. In the case of the xml exchange you
either have to include a subject or you have to have an x-bindings
element defined for the *link* (not the node). Without that, the client
can't create a valid binding for the subscription queue.
The xml exchange doesn't like the xquery you use above. However the
following will work using the c++ version of drain (this will work with
the xml_producer in the old xml example):
drain -a "xml; {link:{x-bindings: [{exchange: xml, key:"content_feed",
arguments:{xquery:\"declare variable \$control external; ./message/id
mod 2 = 1 or \$control = 'end'\"}}]}}" -f
I don't have an address file option just yet, but this is equivalent to:
xml; {
link: {
x-bindings: [
{
exchange: xml,
key: content_feed,
arguments: {
xquery:"declare variable $control external;
./message/id mod 2 = 1 or $control = 'end'"
}
}
]
}
}
If you then run the xml_producer then you will see the odd numbered
messages as expected.
There is an issue with the python client at present. If fed the above
address it will still result in the error below. This is because it
sends to bind requests and the first has no arguments specified for it.
I've created a Jira to track that:
https://issues.apache.org/jira/browse/QPID-2551
I hope this makes sense. I appreciate its not as obvious as would be
ideal. Thoughts on how we could better document this are appreciated.
Is the address string correct, or am I missing something? Here's the drain
output:
Traceback (most recent call last):
File "./drain", line 93, in<module>
rcv = ssn.receiver(addr)
File "<string>", line 6, in receiver
File "/usr/lib/python2.5/site-packages/qpid/messaging/endpoints.py", line
571, in receiver
receiver._ewait(lambda: receiver.linked)
File "/usr/lib/python2.5/site-packages/qpid/messaging/endpoints.py", line
881, in _ewait
result = self.session._ewait(lambda: self.error or predicate(), timeout)
File "/usr/lib/python2.5/site-packages/qpid/messaging/endpoints.py", line
528, in _ewait
self.check_error()
File "/usr/lib/python2.5/site-packages/qpid/messaging/endpoints.py", line
517, in check_error
raise self.error
qpid.messaging.exceptions.ServerError: internal-error: Could not parse xquery:
(qpid/xml/XmlExchange.cpp:118)(541)
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
