Current Behaviour
The page documents the current (trunk 2016-11-04, r1767914) behaviour of the WMC's message preview feature under the following test cases.
Test Case | Message |
---|---|
small text message | JMS TextMessage "hello world" |
large text message | JMS TextMessage "ABCD" repeated 16383 times (65532 length) |
small map message | JMS MapMessage one key/value pair of each supported type. String pair value is (1) |
large map message | JMS Map Message one key/value pair of each supported type. String pair value is (2) |
small stream message | JMS Stream Message containing pair of each support type. String value is (1) |
large stream message | JMS Stream Message containing pair of each support type. String value is (2) |
small object message | JMS Object Message containing List comprising string value (1) and an integer |
large object message | MS Object Message containing List comprising string value (2) and an integer |
large pdf file | JMS Bytes Message containing a PDF (2102551 bytes) |
(1) String "hello world"
(2) "ABCD" repeated 1024^2 times
Protocol 0-8..0-10
Test Case | Protocol 0-9/0-10 | ||
---|---|---|---|
Content Type | On screen preview | Content Download | |
small text message | text/plain | complete string value | ditto preview |
large text message | text/plain | truncated string value | complete string value |
small map message (default) | amqp/map | Table containing name/value pairs Map entry with bytes array value is base64 encoded | The map's contents encoded as a AMQP 0-10 map
|
large map message (default) | amqp/map | Table containing name/value pairs Map entry with bytes array value is array of ints | |
small map message (legacy) | jms/map-message | Table containing name/value pairs Map entry with bytes array value is base64 encoded | Each written value is encoded by the TypedBytesContentWriter (2) |
large map message (legacy) | jms/map-message | Table containing name/value pairs Map entry with bytes array value is array of ints | |
small stream message | amqp/list | Table containing list values | The list's contents encoded as a AMQP 0-10 list |
large stream message | amqp/list | Table containing list values | |
small stream message (default - legacy) | jms/stream-message | No preview | Each written value is encoded by the TypedBytesContentWrite |
large stream message (default - legacy) | jms/stream-message | No preview | |
small object message | application/java-object-stream | No preview | Serialised object bytes |
large object message | application/java-object-stream | No preview | |
large pdf file | application/octet-stream | No preview | the pdf file. |
Protocol 1.0
Test Case | Protocol 1.0 | ||
---|---|---|---|
Content Type | On screen preview | Content Download | |
small text message | Not present in AMQP 1.0 | No preview present on screen but getContent but returnJson true returns the bytes of the application payload itself. Note Content size reported is the size of the immutable sections, not the size of the application payload. | All the sections that comprise the immutable bare message, encoded in AMQP 1.0
|
large text message | |||
small map message | |||
large map message | |||
small stream message | |||
large stream message | |||
small object message | |||
large object message | |||
large pdf file |
(2) TypedBytesContentWriter is distinct from AMQP value system)
(3) http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#section-message-format
Current Problems
Preview feature
- As the preview feature uses JSON, which carries no type information, there is ambiguity in the presented information. However, as the user of this feature is likely to have some familiarity with the application domain (perhaps as a programmer or operator), this is not necessarily a blocker. Examples:
- A list that comprises shorts is indistinguishable from a list of ints
- Some strings are indistinguishable from byte arrays encoded as Base64.
- The representation of byte-arrays is inconsistent between previews of truncated and untruncated previews (Base64 for untruncated vs JSON array of integers for truncated ones)
- A preview is offered for amqp/lists but not jms/stream-message, which is the JMS client's default for StreamMessage. There seems to be no good reason for this.
- There is no preview for AMQP 1.0 message at all.
Content Download
- In AMQP 0-8..0-10, the getContent operation usefully provides the bytes/text/object of messages. For users of AMQP 1.0, the getContent returns the concatenation of the immutable 'bare message' which is useless to the end user (unless they are prepared to decode the AMQP).
API
- The limit argument allows the user to get the first n bytes. There is no way for the caller to get the next n bytes in order to download chunk by chunk.
Suggested Changes
Preview feature
Server Side
- For structured payloads that include a byte array the JSON representation will always return an array of integers (rather than the Base64 encoded default of Json)
- Change the getContent operation so when
returnJson
is true, JSON is return regardless of the message's MIME type.
This will mean:
- This will enable the preview of for AMQP 1.0 message payloads and AMQP 0-8-0-10 jms/stream-messages
- This will mean that the caller won't be able to distinguish between an message containing a list of (small) integers from a message containing a binary octlet-stream.
WMC
- UI no longer considers mimeType
- UI changes to always render a preview of the first n payload bytes
- If the returned JSON object is a list containing only integers 0-255, UI guesses that the message is probably a binary octlet-steam. Display the preview as http://mephux.github.io/hexdump.js/
- If the returned JSON object is another type or a list containing larger integers, display preview as today.
Content Download
I don't see a reasonable way to enable the application payload for AMQP 1.0 messages. The underlying problem is the inability to get the application payload separately from the store. If we wanted a AbstractQueue hack we could do something like the below, but I am not suggesting we do this.
private Content createMessageContent(final MessageReference<?> messageReference, final boolean returnJson, final long limit, final boolean decompressBeforeLimiting) ... if (serverMessage.getClass().endsWith("1_0")) { // Convert to internal message return new MessageContent { // Stream the InternalMessage's content payload to the OutputStream } } else { return new MessageContent(messageReference, limit, decompressBeforeLimiting); }
API
I don't much like the getMessageContent's limit argument nor the ability to trim a structured message to provide a shortened by syntactically legal JSON response. As a user I think I would find the behaviour surprising.
I think I would have preferred that the REST API implemented RFC 7233 Ranges, and the REST API have the responsibility to chunk the response from getMessageContent. Chunks would not necessarily be syntactically valid JSON. If the client would need to intercept the "206 Partial Content" response and know that the response is incomplete. In this case, the client would fallback back on showing a hex dump style preview of the raw content bytes itself.
The getMessageContent API would have no knowledge of chunking.