Bug 1004474

Summary:	[AMQP 1.0] Make handling of properties more robust to type errors
Product:	Red Hat Enterprise MRG	Reporter:	Gordon Sim <gsim>
Component:	qpid-cpp	Assignee:	Gordon Sim <gsim>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Ernie <eallen>
Severity:	unspecified	Docs Contact:
Priority:	medium
Version:	Development	CC:	eallen, esammons, freznice, iboverma, jross
Target Milestone:	3.0	Keywords:	OtherQA
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	qpid-cpp-0.22-14	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-01-21 12:55:02 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1010399

Description Gordon Sim 2013-09-04 17:24:51 UTC

Description of problem:

If a message property is encoded by a peer as the wrong type, the qpid::messaging client gets confused about all subsequent properties also.

Version-Release number of selected component (if applicable):

qpid-0.24

How reproducible:

100% but involved

Steps to Reproduce:
1. E.g. use hornetq beta with AMQP enabled, send message from proton to a queue and receive it using qpid::messaging

Actual results:

The message is sent out by hornetq with the message-id property being a long rather than a ulong[1] as required by the spec. However this causes qpid::messaging to muddle up the remaining properties e.g. confusing subject and replyto etc.

Expected results:

Its acceptable to not recognise properties of a wrong type (e.g. in this case to ignore the message-id), but the others should be handled correctly.

Additional info:

[1] https://issues.jboss.org/browse/HORNETQ-1253

Comment 1 Gordon Sim 2013-09-04 17:25:49 UTC

Fixed upstream: https://svn.apache.org/r1520066

Comment 2 Ernie 2014-04-01 16:06:47 UTC

Verified on RHEL 6.4 32 and 64
package used: 0.22-36

I was unable to get a version of HornetQ that sends a message with an long instead of a ulong. My assumption is that the latest released version (with AMQP support) does not do this.

Instead, I attached a program that sends various message properties with unexpected data types and attached it to the test case.