qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From fadams <fraser.ad...@blueyonder.co.uk>
Subject Re: c++ 0.10 client, java 0.10 broker, headers exchange not routing
Date Mon, 25 Jul 2011 18:52:26 GMT

Gordon Sim wrote:
>>> Try adding a line after that something like the following:
>>>     msg.getProperties()["xyz_header"].setEncoding("utf8");
>> Is there a reason that this isn't the default behaviour
> Mainly because, unlike java, in c++ std::string does not have an 
> encoding it is just a sequence of chars and is at present used for both 
> binary and textual data.

I get that std::string is just a sequence of chars, I was really meaning
could the c++ client runtime default the encoding of properties to utf8?

Gordon Sim wrote:
> Now, in the case of a message property, we could perhaps take the line 
> that it is unusual to send binary data as a header. (However we still 
> don't know that the string is valid utf8, and I wouldn't want to be 
> forced into explicitly checking that for every message).

Sending arbitrary binary data is likely to cause interoperability issues :-)
from my understanding of the JMS Spec there's a comment "Property values can
be boolean, byte, short, int, long, float, double, and String. " so
receiving a byte[] from a c++ producer is "technically" invalid behaviour I
believe. All of these Java types map to AMQP types according to
https://www.amqp.org/svn/amqp/trunk/specification/types.xml interestingly it
looks like a c++ byte array string would map to Binary not String which is "
a sequence of unicode characters" but Binary seems wrong in this context.

Re "I wouldn't want to be forced into explicitly checking that for every
message". It's a fair point. Perhaps one option is to provide a "validate"
switch/env variable. It's kind of analogous to XML validation people rarely
use it on live systems to improve throughput but it's darned irritating if
people don't enable it during testing which then results in one getting fed
with invalid XML.

Gordon Sim wrote:
>> - it would seem to
>> make sense from a Java/C++ interoperability perspective and it's not
>> ideal
>> to have to rely on a client doing something that might perhaps be seen as
>> a
>> bit esoteric.
> Yes, I agree. I would certainly like to see the situation improved in 
> some way. Any other thoughts/opinions/suggestions?

Well only insofar as above, perhaps the default behaviour should be to map
to interoperable AMQP types, possibly providing optimisation flags where say
C++ qpid clients know they don't want/need to interoperate, though I'd be
surprised if interoperability encodings were a significant bottleneck.

Talking of interoperability I'm starting to find some of the JMS/QMF2 issues
to be a bit of a pain. We've discussed in the past some issues decoding
amqp/list types for QMF2 Events. I've just discovered that Agent Locate
messages need amqp/list bodies so I've had to go the other way. Writing the
following code (which I'm not too keen on - especially the cast in order to
set Content Type - yuk)

	 * Encodes a java.util.List as an amqp/list.
	 * This is somewhat of a dirty hack that needs to be monitored as qpid
versions change.
	 * Unfortunately there's no clean way to encode or decode amqp/list
messages via the JMS API.
	 * This method uses the org.apache.qpid.transport.codec.BBEncoder
writeList() method to encode
	 * a List into a ByteBuffer then writes the bytes from the buffer into a
JMS BytesMessage.
	 * Unfortunately even more hackery has to take place so set the
content-type as no pure JMS API
	 * property currently gets mapped to content-type, so we have to cast to
	 * @param list to encode into JMS Message
	 * @return amqp/list encoded JMS Message
	private Message buildMessageFromList(List list) throws JMSException {
		BytesMessage message = syncSession.createBytesMessage();

		BBEncoder encoder = new BBEncoder(1024);
		ByteBuffer buf = encoder.segment();
		byte[] data = new byte[buf.limit()];

		return message;

You mentioned in the past the possibility of using StreamMessage for
amqp/list, but I'm not so sure about that as the JMS Spec says "A
StreamMessage object is used to send a stream of *primitive* types in the
Java programming language. " List certainly isn't a primitive.

The more I think about it the more I prefer the idea of sending/receiving
amqp/list and amqp/map as JMS ObjectMessages - with an appropriate way of
setting content-type (such as an x-amqp.content-type property). Although JMS
MapMessages work OK for amqp/map I've been finding them rather irritating as
MapMessage doesn't follow the java.util.Map interface and I've found myself
writing utility methods to erm map MapMessages to java.util.Map so I can
create my QMF objects in a homogonous manner (using the List decode you
provided gives a List of java.util.Maps)

Gordon Sim wrote:
>> In other words relying on client code rather than client
>> runtime for interoperability is an unsafe principle.
> (Not so sure about that.)

Are you serious with the "Not so sure about that" comment - you've clearly
not met the same people I need to interoperate with :-)

Joking apart I stand by that comment. If one wishes to design an
interoperable system it's generally unsafe to rely on producer/consumer
systems having to *do* something - I've probably contradicted myself a bit
with my ObjectMessage comment above, though I think the producer JMS runtime
could use the java.util.List/java.util.Map type information to automatically
set the content-type so only the consumer would would need to check the
content-type to do the correct cast of the ObjectMessage Object. Also as
we've previously discussed I'd far prefer to receive the content-type in
this way than do instanceof which is currently necessary to distinguish
between MapMessage and BytesMessage


View this message in context: http://apache-qpid-users.2158936.n2.nabble.com/c-0-10-client-java-0-10-broker-headers-exchange-not-routing-tp6597256p6619517.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.

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

View raw message