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.

(1) String "hello world"

(2) "ABCD" repeated 65535/4 times

Protocol 0-8..0-10

Protocol 1.0

(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

1. 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:

1. 1. A list that comprises shorts is indistinguishable from a list of ints
   2. Some strings are indistinguishable from byte arrays encoded as Base64.
2. 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)
3. 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.
4. There is no preview for AMQP 1.0 message at all.

Content Download

1. 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

1. 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

1. 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)
2. 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

1. UI no longer considers mimeType
2. UI changes to always render a preview of the first n payload bytes 
   1. 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/
   2. 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. 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.

https://tools.ietf.org/rfc/rfc7233.txt