Created attachment 762475 [details] simple test service that prints out details of AMQP 1.0 encoded messages it receives Description of problem: AMQP 1.0 defines several standard properties for a message. These are not all available directly through get/set methods on qpid::messaging::Message. However they should be available via special property names: x-amqp-first-acquirer, x-amqp-delivery-count, x-amqp-to, x-amqp-absolute-expiry-time, x-amqp-creation-time, x-amqp-group-id, x-amqp-qroup-sequence, x-amqp-reply-to-group-id. Version-Release number of selected component (if applicable): 0.22 had the ability to read these properties but not to set them How reproducible: 100% Steps to Reproduce: 1. compile and start attached java messenger application (requires proton-j) (or indeed create alternative test service) 2. qpid-send --connection-options {protocol:amqp1.0} --address blah -Px-amqp-group-id=blah Actual results: Before the change this would simply have been sent in the application-properties section as a custom property. This should be possible to see in the attached test service. Expected results: It should be sent as the group-id field in the properties section. Additional info:
Hi Gordon, I see three issues here: Command: qpid-send --connection-options {protocol:amqp1.0} \ \ --durable yes \ --priority 1 \ --ttl 3600 \ -P "x-amqp-first-acquirer=True" \ -P "x-amqp-delivery-count=10" \ \ --id abc \ --user-id guest \ -P "x-amqp-to=amq.direct" \ \ --reply-to amq.topic \ --correlation-id abc \ -P "x-amqp-group-id=theGroup" \ -P "x-amqp-group-sequence=10" \ -P "x-amqp-reply-to-group-id=theGroup" \ --content-string "test" \ --address amq.direct/subject # ./run_example.sh org.apache.qpid.proton.messenger.examples.Recv HEADER durable : true priority : 1 ttl : 3600 first acquirer : true delivery count : 10 PROPERTIES message id : abc user id : [B@3e72d5c0 to : amq.direct subject : subject reply to : amq.topic correlation id : abc content type : null content encoding: null expiry time : 0 creation time : 0 group id : theGroup group sequence : 10 reply-to group : theGroup APPLICATION PROPERTIES ts: 1387298554119178669 sn: 1 APPLICATION DATA [B@652f5047 ^^ 1.) user-id and content is wrongly displayed (see above), am I passing the values bad way? note: setting the content type to text/plain do not solve the issue 2.) if you look at the command (qpid-send) above, you'll see that I need to use two different ways for setting all the properties (setters and "pseudo properties "/x-amqp-<properties>/) which I found quite unhandy. I believe that there shall be one way for setting the message headers/properties, ie: either to add setters/getters for the new amqp1.0 headers/properties or support the "pseudo properties" (the "x-amqp-<property> form) for all the amqp1.0 defined properties. Do you think it is worth raising a Bugzilla for that? 3.) when I try to set x-amqp-absolute-expiry-time and x-amqp-creation-time on the produced message, I am getting conversion exception (long -> date) on the java messenger application side, am I passing the values bad way? (qpid::messaging receiver displays the timestamps well) # qpid-send --connection-options {protocol:amqp1.0} -P "x-amqp-absolute-expiry-time=1399999999" -P "x-amqp-creation-time=1387459699" -a amq.direct qpid-send: Disconnected (reconnect disabled) # ./run_example.sh org.apache.qpid.proton.messenger.examples.Recv Exception in thread "main" org.apache.qpid.proton.codec.DecodeException: Incorrect type used at org.apache.qpid.proton.codec.DynamicTypeConstructor.readValue(DynamicTypeConstructor.java:47) at org.apache.qpid.proton.codec.DecoderImpl.readObject(DecoderImpl.java:885) at org.apache.qpid.proton.message.impl.MessageImpl.decode(MessageImpl.java:587) at org.apache.qpid.proton.messenger.impl.MessengerImpl.get(MessengerImpl.java:423) at org.apache.qpid.proton.messenger.examples.Recv.main(Recv.java:42) Caused by: java.lang.ClassCastException: java.lang.Long cannot be cast to java.util.Date at org.apache.qpid.proton.codec.messaging.PropertiesType.newInstance(PropertiesType.java:163) at org.apache.qpid.proton.codec.messaging.PropertiesType.newInstance(PropertiesType.java:40) at org.apache.qpid.proton.codec.DynamicTypeConstructor.readValue(DynamicTypeConstructor.java:39) ... 4 more Thanks in advance for your feedback.
(In reply to Petr Matousek from comment #1) > 1.) user-id and content is wrongly displayed (see above), am I passing the > values bad way? > note: setting the content type to text/plain do not solve the issue The userid field is defined to be of type binary, hence in java it is returned as a byte array. The actual bytes do appear to be correct. The example should be modified (i'll attach a patch) to e.g. create a String for printing. The content is being sent as binary data. This is really an issue with the qpid-send test utility. I changed it to use ContentObject for maps, but not for other modes of setting the content. > 2.) if you look at the command (qpid-send) above, you'll see that I need to > use two different ways for setting all the properties (setters and "pseudo > properties "/x-amqp-<properties>/) which I found quite unhandy. > > I believe that there shall be one way for setting the message > headers/properties, ie: either to add setters/getters for the new amqp1.0 > headers/properties or support the "pseudo properties" (the > "x-amqp-<property> form) for all the amqp1.0 defined properties. Do you > think it is worth raising a Bugzilla for that? I guess it would be reasonable to allow setting all the fields using the x-amqp- type syntax (e.f. x-amqp-subject etc) in addition to the existing explicit accessors. > 3.) when I try to set x-amqp-absolute-expiry-time and x-amqp-creation-time > on the produced message, I am getting conversion exception (long -> date) on > the java messenger application side, am I passing the values bad way? This is a bug in the library. It is sending these values with the wrong typecode. I think a new BZ for that might be clearer, but if you prefer moving this back to assigned that is also fine.
(In reply to Gordon Sim from comment #2) > (In reply to Petr Matousek from comment #1) > > 3.) when I try to set x-amqp-absolute-expiry-time and x-amqp-creation-time > > on the produced message, I am getting conversion exception (long -> date) on > > the java messenger application side, am I passing the values bad way? > > This is a bug in the library. It is sending these values with the wrong > typecode. I think a new BZ for that might be clearer, but if you prefer > moving this back to assigned that is also fine. Actually, the fix for this is the same as that required for https://bugzilla.redhat.com/show_bug.cgi?id=1045091, so if you like we can just use that one to cover this issue also(?).
Created attachment 839151 [details] diff to fix Recv.java example to print ou the userid
Created attachment 839152 [details] modified example (i.e. with previous patch applied)
(In reply to Gordon Sim from comment #2) > (In reply to Petr Matousek from comment #1) > > 1.) user-id and content is wrongly displayed (see above), am I passing the > > values bad way? > > note: setting the content type to text/plain do not solve the issue > > The userid field is defined to be of type binary, hence in java it is > returned as a byte array. The actual bytes do appear to be correct. The > example should be modified (i'll attach a patch) to e.g. create a String for > printing. > > The content is being sent as binary data. This is really an issue with the > qpid-send test utility. I changed it to use ContentObject for maps, but not > for other modes of setting the content. I've altered qpid-send upstream to send string data as utf8, see https://issues.apache.org/jira/browse/QPID-5435. If we want a BZ for that I think its probably better to create a new one as its distinct from the original issue here.
1.) created bug 1045407 to get the qpid-send fix downstream 2.) create rfe bug 1045411 3.) > Actually, the fix for this is the same as that required for > https://bugzilla.redhat.com/show_bug.cgi?id=1045091, so if you like we can just > use that one to cover this issue also(?). I would prefer track this issue in this bz, because it's reproducible with the use of proton-j messenger client, bug 1045091 is related to qpid::messaging api. bug 1045091 is already in POST so changing the state accordingly: MODIFIED -> ASSIGNED -> POST Thanks for the effort Gordon.
Well, adding the the dependency on bug 1045091 is probably enough to track the issue 3.) in this bz, moving back to MODIFIED, sorry for the unnecessary state changes.
There is an mistyped character in EncodedMessage.cpp, which leads to that the 'x-amqp-group-sequence' property is displayed as 'x-amqp-qroup-sequence' using qpid::messaging consumer. # ./spout --connection-options "{protocol: 'amqp1.0'}" -P x-amqp-group-sequence=1 "q;{create:sender}" # ./drain --connection-options "{protocol: 'amqp1.0'}" q Message(properties={spout-id:510f4e70-c97a-4b06-9a17-a00b0061bab7:0, x-amqp-qroup-sequence:1}, content='') suggested fix for EncodedMessage.cpp: - map["x-amqp-qroup-sequence"] = groupSequence.get(); + map["x-amqp-group-sequence"] = groupSequence.get(); -> ASSIGNED
Fix made upstream: https://svn.apache.org/viewvc?view=revision&revision=r1554785
Added r1554785 to 0.22-mrg.
The support of the rest amqp1.0 specific properties was implemented. Verified on rhel6.5 (x86_64, i386). All the new x-amqp-* 1.0 defined properties (except the headers: x-amqp-delivery-count, x-amqp-first-acquirer) are settable and transmitted to the receiver unaltered. The 'x-amqp-delivery-count' works as expected (see Bug 975422). The 'x-amqp-first-acquirer' is currently not supported by the broker (see Bug 1059786) notes: The 'x-amqp-to' field is filled with the amqp0-10 destination when converting from 0-10 message format. All the specially named amqp1.0 standard properties (x-amqp-*) are currently not transmitted to the 0-10 receiver (see Bug 1070861) packages under test: qpid-cpp-*-0.22-35 -> VERIFIED