...

(1) String "hello world"

(2) "ABCD" repeated 1024^2 65535/4 times

Protocol 0-8..0-10

ff

...

Protocol 1.0

(1) 

2016-11-04 11:01:43,128 DEBUG [HttpManagement-HTTP-218] (o.a.q.s.m.p.s.r.RestServlet) - IllegalArgumentException processing request
java.lang.IllegalArgumentException: unknown code: 67
at org.apache.qpid.transport.codec.AbstractDecoder.getType(AbstractDecoder.java:354) ~[classes/:na]
at org.apache.qpid.transport.codec.AbstractDecoder.readMap(AbstractDecoder.java:287) ~[classes/:na]
at org.apache.qpid.server.protocol.v0_8.MessageConverter_v0_8_to_Internal.convertMessageBody(MessageConverter_v0_8_to_Internal.java:340) ~[classes/:na]
at org.apache.qpid.server.protocol.v0_8.MessageConverter_v0_8_to_Internal.convert(MessageConverter_v0_8_to_Internal.java:86) ~[classes/:na]
at org.apache.qpid.server.protocol.v0_8.MessageConverter_v0_8_to_Internal.convert(MessageConverter_v0_8_to_Internal.java:48) ~[classes/:na]
at org.apache.qpid.server.queue.AbstractQueue.createMessageContent(AbstractQueue.java:3731) ~[classes/:na]
at org.apache.qpid.server.queue.AbstractQueue.getMessageContent(AbstractQueue.java:3701) ~[classes/:na]
at org.apache.qpid.server.queue.StandardQueueImplWithAccessChecking.getMessageContent(StandardQueueImplWithAccessChecking.java:80) ~[classes/:na]

(2) TypedBytesContentWriter is distinct from AMQP value system)

...

Current Problems

Preview feature

1. As the preview feature uses JSON, which carries no type information, there is type-information loss (e.g. a 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
in
2. 1. is indistinguishable from a list of ints
)
3. 2. Some strings are indistinguishable from byte arrays encoded as Base64.
4. The representation of byte-arrays is inconsistent between  truncated previews of truncated and untruncated previews (Base64 for untruncated vs JSON array of integers for truncated ones),
5. A byte array serialised as Base64 may be misinterpreted as a String. As we already offer a preview of the amqp/lists is seems odd that the same is not offered for the 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.
6. There is no preview for AMQP 1.0 doesn't offer any previews (because the server currently only obeys returnJson if the message carries a known AMQP 0-8..0-10 mime type)message at all.

Content Download

1. In AMQP 0-8..0-10, getContent is useful for 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 way limit applies to Json (truncating, but retaining a syntactically valid response if possible), seems surprising (at least to me)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

...

1. Standardise on returning byte arrays as array of integers
2. For operation getContent if JSON is requested,  it produces it only for Strings, Maps, Collections.  For any other object payload, the operation must fail (say 422)
3. For AMQP 1.0
   1. for messages with payloads that are representable as JSON, the above changes will be sufficient give us the preview.
   2. for byte messages, with payloads that hold things like PDFs, there is currently no good place to adapt the content and extract the message payload.  The underlying problem here is the store API.  I suggest we don't fix this at the moment.

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

...

1. UI always requests content JSON content with limit.  If the request fails with 422, add message "preview no available" to the UI.
2. UI no longer considers mime type