You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In AMQP 0.9 the message format was simple, and the message body was always an opaque byte array. In AMQP 1.0, the message body can be 1 of 3 types: data (opaque byte array), AMQP sequence (list of polymorphic data), or AMQP value (a single instance of polymorphic data). In the current implementation, the message is always sent as an opaque byte array. If the use case is to process JSON messages (UTF-8 String), then it is better to use AMQP as it was intended and send the data as AMQP value of type string. This increases compatibility and simplifies the usage of such a message.
My suggestion is to introduce an advanced configuration option called content_type. The allowed values are:
opaque_binary: Same behavior as today. This is the default to keep compatibility and prevent a breaking change.
string: New option which sends the message as string content.
The amqp_1 input module implementation already supports the string message type, so there is no change needed.
I will provide a pull request for this enhancement.
The text was updated successfully, but these errors were encountered:
In AMQP 0.9 the message format was simple, and the message body was always an opaque byte array. In AMQP 1.0, the message body can be 1 of 3 types: data (opaque byte array), AMQP sequence (list of polymorphic data), or AMQP value (a single instance of polymorphic data). In the current implementation, the message is always sent as an opaque byte array. If the use case is to process JSON messages (UTF-8 String), then it is better to use AMQP as it was intended and send the data as AMQP value of type string. This increases compatibility and simplifies the usage of such a message.
My suggestion is to introduce an advanced configuration option called
content_type
. The allowed values are:opaque_binary
: Same behavior as today. This is the default to keep compatibility and prevent a breaking change.string
: New option which sends the message as string content.The
amqp_1
input module implementation already supports the string message type, so there is no change needed.I will provide a pull request for this enhancement.
The text was updated successfully, but these errors were encountered: