Hi All,
I was playing around looking at the symptoms Jiri described and I
decided to check out some nagging concerns I've had with the headers
exchange.
I'm surprised I've not noticed this before, but I've mainly been looking
at java and haven't focused on interoperability issues as much as I
perhaps should have.
So I've tried setting up producers and consumers in c++, java and perl
with roughly equivalent behaviour. I use an address on each as follows:
C++:
string address = "test; {create: receiver, node: {x-declare: {arguments:
{'qpid.policy_type': ring, 'qpid.max_size': 500000000}}, x-bindings:
[{exchange: 'amq.match', queue: 'test', key: 'data1', arguments:
{x-match: all, data-service: amqp-delivery, item-owner: fadams}}]}}";
Java (via a JNDI file):
destination.subscribedAddress1 = test; {create: receiver, node:
{x-declare: {arguments: {'qpid.policy_type': ring, 'qpid.max_size':
500000000}}, x-bindings: [{exchange: 'amq.match', queue: 'test', key:
'data1', arguments: {x-match: all, data-service: amqp-delivery,
item-owner: fadams}}]}}
Perl:
my $address = "test; {create: receiver, node: {x-declare: {arguments:
{'qpid.policy_type': ring, 'qpid.max_size': 500000000}}, x-bindings:
[{exchange: 'amq.match', queue: 'test', key: 'data1', arguments:
{x-match: all, data-service: amqp-delivery, item-owner: fadams}}]}}";
I had producers writing to amq.match and I found:
perl producer -> perl consumer OK
perl producer -> c++ consumer OK
perl producer -> java consumer FAILED
c++ producer -> perl consumer OK
c++ producer -> c++ consumer OK
c++ producer -> java consumer FAILED
java producer -> perl consumer FAILED
java producer -> c++ consumer FAILED
java producer -> java consumer OK
I know the perl one is a bit of a red herring as it's essentially a
wrapper round qpid::messaging but I included for completeness. My tests
were carried out using the 0.10 C++ broker using the qpid::messaging API.
So the thread preceding this has discussed the UTF-8 issues with respect
to variant types but this is perhaps more insidious. I couldn't quite
figure it out until I looked using a qpid-config I'd patched so I could
see headers bindings.
For C++ and perl I get:
bind [data1] => amq.match {u'item-owner': 'fadams', u'data-service':
'amqp-delivery', u'x-match': 'all'}
For java I get:
bind [data1] => amq.match {u'item-owner': u'fadams', u'data-service':
u'amqp-delivery', u'x-match': u'all'}
So basically for Java the address string pushes Unicode values onto the
binding, but for C++/perl the address string pushes (I guess) ASCII
values onto the binding.
This is a pretty big concern for me. But one thing is even weirder; in
my organisation we've got a mixture of c++ and java producers and
consumers using the headers exchange ,but so far (touch wood) things
*seem* to be working. However as it happens the C++ producers and
consumers are using the qpid::client API, so are likely to be binding at
a lower level rather than using address strings.
I'm trying to persuade the developers to switch to qpid::messaging but
now I'm worried this could cause interoperability issues.
I have to confess that this is really pretty frustrating. I seem to keep
getting bitten by string incompatibilities, which I can mostly mitigate
at the client code level, but problems at the exchange are more painful.
I keep on arguing that property strings should default to Unicode to
ensure interoperability and this convinces me more. Nobody seems to be
biting on that though - is it just me who's been driven nuts by this??
Is there any way that I can force the address string in C++/perl to be
treated as Unicode in
Receiver receiver = session.createReceiver(address);
Interoperability is really important to me.
Cheers
Frase
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
