[
https://issues.apache.org/jira/browse/QPID-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475637
]
Tomas Restrepo commented on QPID-336:
-------------------------------------
After looking around the code a bit, I'm noticing three issues that might be
related:
The first one is that the patch I submitted was applied as it was.
Unfortunately, after submitting it a patch was commited to the java trunk that
inverted the field type codes for the unsigned integer and signed integer
types, so they need to be swapped in the code (AMQUInt32Type and AMQInt32Type
types).
The second one, is that indeed the .NET code implements a couple of types that
are not currently implemented in the Java code. When I did the patch, I left
supported and implemented all signed and unsigned integer types, some of which
are not supported in the Java code right now. The only exception here is the
signed short type, which is "disabled" because the proposed type code for it is
currently used by the LONG STRING type ('s').
Finally, and this might not be related to Rupert's test, but is pretty
significant: I think the message header support in the .NET client is
completely broken. In particular, currently message headers are NOT implemented
on top of a FieldTable, and instead seem to have their own property
serialization/deserialization which is totally out of date. In fact, in a few
tests I've ran it appears that once you add a custom header to a message from a
.net client routing doesn't even happen at the broker level (or at least I
couldn't get it to work with .net client at both ends, so something is
definitely up).
I think we need to rewrite the QpidHeaders class and rewrite it to handle
headers as a FieldTable, just like the JMSHeadersAdapter class in the Java
client does.
> .NET client support for field table types requires extension (interop issue)
> ----------------------------------------------------------------------------
>
> Key: QPID-336
> URL: https://issues.apache.org/jira/browse/QPID-336
> Project: Qpid
> Issue Type: Bug
> Components: Dot Net Client
> Affects Versions: M1
> Reporter: Marnie McCormack
> Assigned To: Marnie McCormack
> Attachments: QPID-336.diff
>
>
> If you send a message from a Java client and then consume from a .NET client
> there's an error:
> A first chance exception of type 'Qpid.Framing.AMQFrameDecodingException'
> occurred in qpid.common.dll
> Additional information: Unsupported field table type: 'x' charcode120
> In the .NET case, this kills the connection to the broker as well, which
> would seem to be a little extreme.
> .NET client needs to support the same set of field table types as Java client.
> See Field Table extension proposal for AMQP from 108 wiki:
> Field Table Change Proposal
> Field tables are binary structures that contain packed name-value pairs. Each
> name-value pair is a structure that provides a field name, a field type
> (referred to as the discriminator), and a field value.
> Currently the following values can be stored in the field table.
> 4.2.5.5 Field Tables
> Field tables are long strings that contain packed name-value pairs.
> Each name-value pair is a structure that provides a field name, a field type,
> and a field value.
> A field can hold:
> a tiny text string ('S')
> a long string ('S')
> a long signed integer ('I')
> a decimal ('D'), a date and/or time ('T')
> or another field table ('F').
> It is proposed that this section be changed to:
> 4.2.5.5 Field Tables
> Field tables are long binary values that contain packed name-type-value
> triples.
> Each name-type-value triple is a structure that provides a field name, a
> field type, and a field value.
> A field can hold:
> A boolean that can take one of the values True or False. The value is
> encoded as a single byte where the value 0 represents false and the
> value 1 represents true. The discriminator is the character 't'.
> A range of different sized signed values. In each case they are
> encoded using two's complement. The list below shows the sizes and the
> discriminators:
> 8: b
> 16: s
> 32: i
> 64: l
> A range of different sized unsigned values. In each case they are
> encoded as an unsigned binary number. The list below shows the sizes and
> the discriminators:
> 8: B
> 16: S
> 32: I
> 64: L
> Floating point types. Floating point types are encoded using the IEEE
> 754 standard. For full details of that encoding please see the "IEEE
> Standard for Binary Floating-Point Arithmetic, ANSI/IEEE Standard
> 754-1985". The different precisions supported are:
> - single precision, with discriminator f
> - double precision, with discriminator d
> - double-extended, which has an exponent of at least 15 bits in length
> and
> a signed fraction of at least 64 bits, with discriminator D
> An ASCII character. Encoded as a single character with an ASCII encoding.
> Discriminator 'k'.
> An ASCII string type, containing ASCII characters. Encoded as a 2 byte
> unsigned integer as the size followed by the characters, using one byte
> per character with an ASCII encoding. Discriminator 'c'.
> A wide string type, containing characters encoded using the broker's
> configured encoding for wide characters. Encoded as a 4 byte unsigned
> integer as the size in bytes followed by the bytes of data. Examples of
> encodings are UTF-8 and UTF-16. Discriminator 'C'.
> A NULL string, No Encoded value. Discriminator 'n'.
> A date time type, containing a 64 bit unsigned integer that represents
> the time to a granularity of seconds encoded in POSIX time_t format. A
> value of 536457599 corresponds to Wednesday December 31 23:35:59 GMT
> 1986. This has a descriminator 't'.
> A binary data type, to allow encoding of arbitrary data. This is
> encoded as a four byte unsigned integer representing the size followed
> by that number of bytes. Discriminator 'x'.
> Another field table 'F'.
> Guidelines for implementers:
> Field names MUST start with a letter, '$' or '#' and may continue with
> letters, '$' or '#', digits, or underlines, to a maximum length of 128
> characters.
> The server SHOULD validate field names and upon receiving an invalid
> field name, it SHOULD signal a connection exception with reply code
> 503 (syntax error). Conformance test: amq_wlp_table_01.
> A peer MUST handle duplicate fields by using only the first instance.
> The above implies that there is a configured wstring encoding at the broker
> level. I propose that the Connection.Tune method gets an additional field
> indicating the encoding (e.g. UTF-16 or whatever) that is used by the broker.
> It is the client's responsibility to do any translation required.
> It is not feasible for the encoding to be negotiated on a per-client basis
> since that would imply that the broker could do the translation which would
> mean that the broker needs examines every content header's field table.
> Adapted from original email by Robert Greig
> (https://amqp.108.redhat.com/servlets/ReadMsg?list=dev&msgNo=169)
> Retrieved from
> "https://wiki.108.redhat.com/wiki/index.php/FieldTableChangeProposal";
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
