I suggest to revisit the implementation of org.apache.activemq.command.Message.getSize().

The current implementation reads
https://github.com/apache/activemq/blob/activemq-5.11.1/activemq-client/src/main/java/org/apache/activemq/command/Message.java#L687-L700

This implementation suffers the following problems:

• When getSize() is called the first time, marshalledProperties are still null, hence the implementation does not calculate marshalledProperties, missing them completely when calculating the size. Message sent over stomp always have marshalledProperties that will be missed in the calculation.

• Later calls to getSize() of the same message already have the size computed and won't re-compute the size anymore, despite marshalledProperty finally being set and available.

• Even with marshalledProperties being set, it calls
  size += marshalledProperties.getLength();
  but that will only return the size of the marshalled properties while these properties are stored in a byte[] array, which is initialized with 1024 initial capacity.
  It should rather return the capacity of the marshalledProperties array if it wants to calculate the actual heap memory it really uses.

• The very same applies to the call content.getLength(), which again returns the size of the data inside a 1024 byte array. For computing the broker's memoryUsage, we should rather use the full capacity of the byte array for this calculation

• Part of the problem is that the ByteSequence marshalledProperties and content both get initialized with the default 1024 size for the byte array.
  However this could be needed as we may not know the proper size of the buffer that will be needed at the stage of initializing the buffer.
  On the other hand this buffer seems to be capable of growing if needed, so perhaps we could initialize with half the size and grow later if needed.
  Most use case may not use message properties (i.e. non standard JMS headers).

What effect does it have? The difference between reported message size and actual heap size is small for each message but it adds up over many messages. In the end the broker may use a considerably higher heap for storing messages that it is configured for in memoryUsage limit. This may result an improper broker tuning where too much of the JVM heap is used for storing messages and the broker would run out of memory as the memoryUsage limit was not yet hit at the time all the JVM heap memory was taken.