You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Marnie McCormack (JIRA)" <qp...@incubator.apache.org> on 2007/02/01 13:33:05 UTC
[jira] Created: (QPID-336) .NET client support for field table
types requires extension (interop issue)
.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
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 set set of field table types as Java client.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (QPID-336) .NET client support for field table
types requires extension (interop issue)
Posted by "Tomas Restrepo (JIRA)" <qp...@incubator.apache.org>.
[ 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.
[jira] Updated: (QPID-336) .NET client support for field table
types requires extension (interop issue)
Posted by "Tomas Restrepo (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tomas Restrepo updated QPID-336:
--------------------------------
Attachment: QPID-336-2.diff
This is a simple patch that addresses some of the CLS Compliance issues that Rupert Smith reported with the previous patch:
- Adds an IExtendedHeaders interface to Qpid.Messaging. This is a non-CLS Compliant interface that extends IHeaders. That way, we can put any non-CLS compliant header accessors in there without affecting the core IHeaders interface. For now, only GetSByte()/SetSByte() are moved to this new interface.
- Makes QpidHeaders implement IExtendedHeaders. This allows current clients that support unsigned types (like C#) to simply cast the Headers property of the message object to IExtendedHeaders to access the new members.
- Fixes a few FxCop warnings in the new Qpid.Buffers implementation and ensures non-CLS compliant members are marked as such.
> .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-2.diff, 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.
[jira] Commented: (QPID-336) .NET client support for field table
types requires extension (interop issue)
Posted by "Tomas Restrepo (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472100 ]
Tomas Restrepo commented on QPID-336:
-------------------------------------
To keep compatibility with the java broker trunk, after applying the patch the type codes for AMQUInt32Type and AMQInt32Type should be reversed (i.e. i and I).
That said, keeping track of what has been changed to ensure compatibility with the current spec vs. the proposed type system is becoming somewhat inconvenient.
> .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
> 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.
[jira] Closed: (QPID-336) .NET client support for field table types
requires extension (interop issue)
Posted by "Rob Godfrey (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rob Godfrey closed QPID-336.
----------------------------
> .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
> Assignee: Rob Godfrey
> Fix For: M2
>
> Attachments: QPID-336-2.diff, 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.
[jira] Updated: (QPID-336) .NET client support for field table
types requires extension (interop issue)
Posted by "Marnie McCormack (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marnie McCormack updated QPID-336:
----------------------------------
Description:
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"
was:
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.
> .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
>
> 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.
[jira] Commented: (QPID-336) .NET client support for field table
types requires extension (interop issue)
Posted by "Rupert Smith (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476623 ]
Rupert Smith commented on QPID-336:
-----------------------------------
Patches applied.
Succesfull interop test send/receving to/from java and .net performed. Messages with every kind of field table entry were sent and correctly encoded and decoded by both clients.
> .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-2.diff, 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.
[jira] Resolved: (QPID-336) .NET client support for field table
types requires extension (interop issue)
Posted by "Rob Godfrey (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rob Godfrey resolved QPID-336.
------------------------------
Resolution: Fixed
Fix Version/s: M2
> .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
> Assignee: Rob Godfrey
> Fix For: M2
>
> Attachments: QPID-336-2.diff, 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.
[jira] Updated: (QPID-336) .NET client support for field table
types requires extension (interop issue)
Posted by "Tomas Restrepo (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tomas Restrepo updated QPID-336:
--------------------------------
Attachment: QPID-336.diff
Attached is a proposed patch to improve this issue. It ports the basic AMQType enumeration from the Java code and related classes (AMQTypedValue, AMQTypeMap) and backported the existing FieldTable class from the Java client to the .NET client to use the new classes and remove all serialization code from the class. It also completes some of the putXXX() and getXXX() methods in the Buffer classes and removes some duplicated and cleans up code the EncodingUtils class.
It currently implements most types outlined in the proposed field table types except:
- Types unimplemented in the Java client are left like that in the .NET code
- Some types are disabled to avoid conflicting type codes
- The code still uses the older types where necessary to keep compatibility to the Java broker, as it hasn't fully adopted the proposed type system yet (particularly the use of the LONG_STRING type.
> .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
> 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.
[jira] Commented: (QPID-336) .NET client support for field table
types requires extension (interop issue)
Posted by "Tomas Restrepo (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475662 ]
Tomas Restrepo commented on QPID-336:
-------------------------------------
Looking a bit more closely on this issue, it appears I was wrong and QpidHeaders is indeed implemented on top of a FieldTable, but adds its own naming scheme/encoding for property names. This should probably be rewritten to simplify it.
The biggest problem with the fieldtable stuff now seems to be that you can't read a field table from a bytebuffer (mea culpa, didn't catch this before in my tests) because FixedByteBuffer.slice() isn't implemented. Implementing it would probably mean creating yet another ByteBuffer-like class, so at this point, my humble opinion would be that a complete rewrite of Qpid.Buffers would be in order.
As part of that, here are some suggestions to simplify this:
- let's start with the simplest implementation that satisfies our needs. We don't need the entire set of functionality supported by MINA in this respect (at least right *now*). For example, all the put(position, value) and getXXX(position) members could go as they are not used anywhere and are not implemented in any of the ByteBufferClasses.
- Implement the simplest byte buffer allocator at first. For example, the SimpleByteBufferAllocator class has its own ref-counted ByteBuffer-derived class, which is not really useful at this point (since we don't release anything after the refcount drops to zero anyway).
- Loose all the byte buffer implementations and stick with only two at first: A core ByteBuffer implementation and a SlicedByteBuffer to support the slicing functionality needed by the FieldTable class, implemented as a simple view on top of the other. Move as much functionality unto the abstract ByteBuffer class (including all base type encodings) so that subclasses only need to override as few methods as absolutely needed (which I think don't need to be more than 6-10 methods).
> .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.
[jira] Assigned: (QPID-336) .NET client support for field table
types requires extension (interop issue)
Posted by "Marnie McCormack (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marnie McCormack reassigned QPID-336:
-------------------------------------
Assignee: Rob Godfrey (was: Marnie McCormack)
Assigning on to Rob (in lieu of Rupert) - believe this may be resolved, confirm with Rupert ?
> .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: Rob Godfrey
> Attachments: QPID-336-2.diff, 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.
[jira] Commented: (QPID-336) .NET client support for field table
types requires extension (interop issue)
Posted by "Rupert Smith (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472759 ]
Rupert Smith commented on QPID-336:
-----------------------------------
This looks good to me. I haven't been able to test it thoroughly due to a lack of compatable interop tests with C++/Java clients.
I think it should be applied anyway, as its the right sort of structure for a solution, even if there are a few minor bugs to fix.
Keep this issue open until interop tests pass.
> .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
> 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.
[jira] Updated: (QPID-336) .NET client support for field table
types requires extension (interop issue)
Posted by "Marnie McCormack (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marnie McCormack updated QPID-336:
----------------------------------
Description:
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.
was:
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 set set of field table types as Java client.
> .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
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (QPID-336) .NET client support for field table
types requires extension (interop issue)
Posted by "Marnie McCormack (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marnie McCormack reassigned QPID-336:
-------------------------------------
Assignee: Marnie McCormack
Assigning to Marnie for testing prior to resolution. Actual testing to be carried out by Rupert Smith.
> .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.
[jira] Commented: (QPID-336) .NET client support for field table
types requires extension (interop issue)
Posted by "Rupert Smith (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472762 ]
Rupert Smith commented on QPID-336:
-----------------------------------
Applied as revision 507096.
> .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
> 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.
[jira] Commented: (QPID-336) .NET client support for field table
types requires extension (interop issue)
Posted by "Rupert Smith (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475327 ]
Rupert Smith commented on QPID-336:
-----------------------------------
Now that I have a simple interop test between the .Net and Java to try this out it looks like it isn't complete yet.
Problems so far: The .Net code is prepending the type codes onto the property names. The Java code is picking up the property names with these type codes on the beginning instead of just the plain property names.
The .Net code can send types not recognized by the Java code resulting in an exception:
java.lang.IllegalArgumentException: no such type code: 42
at org.apache.qpid.framing.AMQTypeMap.getType(AMQTypeMap.java:42)
at org.apache.qpid.framing.AMQTypedValue.readFromBuffer(AMQTypedValue.java:51)
at org.apache.qpid.framing.FieldTable.setFromBuffer(FieldTable.java:902)
...
I'm working on this now to bring the .Net inline with the proposed changes and existing Java code.
> .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.