qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fraser Adams <fraser.ad...@blueyonder.co.uk>
Subject Re: JMS client skips string message properties
Date Fri, 16 Sep 2011 08:29:23 GMT
Hi Jiri
You say "In our case we don't receive the string property in Java at all"

I think that this could possibly be a separate issue. In the scenario 
I'm referring to to try and emulate your problem I have some test C++ 
code like:

        for (int i = 0; i < NUMBER_OF_ITERATIONS; i++) {
            char* buffer = new char[50000];
            Message message(buffer, 50000);
            if ((i % 3) == 0) message.setProperty("item-owner", "jdadams");
            else message.setProperty("item-owner", "fadams");

            message.setProperty("data-service", "amqp-delivery");


In my Java ItemConsumer MessageListener I have.

    public void onMessage(Message message) {
        try {
            BytesMessage msg = (BytesMessage)message;

            byte[] buffer = new byte[(int)msg.getBodyLength()];


I get ClassCast Exceptions "failed as value of type class [B is an 
array", which is consistent with what I've seen in the past and why I 
ended up resorting to the defensive getString() method I posted the 
other day.

Have you tried a System.out.println(message) to see what 
Message.toString() tells you? You might get some more pointers by doing 

Using my test C++ above it looks like the "key" part of it actually does 
get set to UTF-8 by the C++ client runtime, but the default for the 
"value" part doesn't seem to do this. It's *just possible" that 
something you've done might have caused the property key to be non-UTF-8 
too - clearly if the key ends up as a byte array on the Java side then 
you won't see the property. I'm not at all sure that this is what's 
happening in your case, but it's worth a look and Message.toString() 
might give you a pointer.

Sorry I can't be more help at this stage.

Jiri Krutil wrote:
> Hi Gordon
> Thanks for the interesting info. Will try to set encoding as UTF-8 in the
> C++ sender.
> Btw what are the possible valid values for Variant::setEncoding()? I assume
> UTF-8 is "UTF-8".
> In our case we don't receive the string property in Java at all - it is not
> listed among the property names at all.
> Cheers
> Jiri
> On Sep 15, 2011 8:34 PM, "Fraser Adams" <fraser.adams@blueyonder.co.uk>
> wrote:
>> Hi Jiri
>> Out of curiosity have you looked at the type of the property. In other
>> words if you get the property and do a
>> myProperty.getClass().getCanonicalName().
>> I'll bet that it'll come back as a byte array rather than a String. I
>> believe that if you have control of the C++ client you might be able to
>> set the encoding to UTF-8 but if not...
>> I've seen this loads as I've been implementing a Java implementation of
>> the QMF2 API. Frankly it's a pain in the backside. I've resorted to
>> defensive programming in my class that extracts String properties from
>> headers and Map messages as I've had some Agents send Strings and some
>> byte[].
>> /**
>> * There seem to be some inconsistencies where string properties are
>> sometimes returned as byte[] and
>> * sometimes as Strings. It seems to vary depending on the Agent and
>> getting it wrong results in
>> * ClassCastExceptions which is clearly unfortunate.
>> *
>> * This is basically a helper method to check the type of a property
>> and return the most "appropriate"
>> * String representation for it.
>> *
>> * @param p a property in Object form
>> * @return the most appropriate String representation of the property
>> */
>> public static String getString(Object p) {
>> if (p == null) {
>> return "";
>> }
>> if (p instanceof String) {
>> return (String)p;
>> }
>> if (p instanceof byte[]) {
>> return new String((byte[])p);
>> }
>> return p.toString();
>> }
>> My personal view is that the C++ client runtime should default to
>> sending string properties as UTF-8 encoded as this makes the default
>> behaviour interoperable. There might be a small performance gain from
>> not doing that, but in an end to end system of systems I suspect the
>> difference is very small and worth paying for interoperability. One
>> could always have a flag to switch off this behaviour, but I'd prefer
>> Strings to be UTF-8 encoded as a default (all IMHO of course).
>> Hope this helps you out
>> Frase
>> Jiri Krutil wrote:
>>> Hi
>>> When sending messages from a C++ client and receiving them in a Java
> client,
>>> we are having problems with custom message properties in the message
> header.
>>> String message properties set on the C++ sender side are not visible in
> the
>>> receiving Java app. Other property types seem to be processed fine.
>>> The C++ client is messaging v0.7, the Java client is 0.10.
>>> Any ideas?
>>> Cheers
>>> Jiri
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project: http://qpid.apache.org
>> Use/Interact: mailto:users-subscribe@qpid.apache.org

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

View raw message