I am trying to drop any large messages by setting maxFrameSize=262144 and it
seems that it negotiated the setting.
2016-07-25T12:52:10.040-0700 CEF:1 | good |
wrap_mvn_com.good.activemq_osgi.activemq-gems_5.11.1 | 0.0.0 | DEBUG |
unknown | 3 | ID=147 THR=.137:61616@39196 CAT=WireFormatNegotiator
MSG=tcp://JSUEN-W520.rim.net/10.100.153.137:61616@39196 after negotiation:
OpenWireFormat{version=10, cacheEnabled=true, stackTraceEnabled=true,
tightEncodingEnabled=true, sizePrefixDisabled=false, maxFrameSize=262144}
However, I am still seeing 64MB messages go through...
at
org.apache.activemq.openwire.v10.BaseDataStreamMarshaller.tightUnmarshalByteSequence
at org.apache.activemq.openwire.v10.WireFormatInfoMarshaller.tightUnmarshal
at org.apache.activemq.openwire.OpenWireFormat.doUnmarshal
at org.apache.activemq.openwire.OpenWireFormat.unmarshal
The activemq code that does decide the size of the byte[] does use the
readInt() call to simply do this:
386 public final int readInt() throws IOException {
387 int ch1 = in.read();
388 int ch2 = in.read();
389 int ch3 = in.read();
390 int ch4 = in.read();
391 if ((ch1 | ch2 | ch3 | ch4) < 0)
392 throw new EOFException();
393 return ((ch1 << 24) + (ch2 << 16) + (ch3 << 8) + (ch4 << 0));
Each instance in every dump the data in positions 104 to 107 end up giving
us the invalid byte[] size in tightUnmarshalByteSequence.
So going back to that internalBuffer byte array, if we grab the values from
POS 104 to 107:
Type|Name |Value
----------------
byte|[104]|4
byte|[105]|0
byte|[106]|0
byte|[107]|17
byte|[108]|83
byte|[109]|116
byte|[110]|97
byte|[111]|99
byte|[112]|107
byte|[113]|84
byte|[114]|114
----------------
And do the left bit shift operations we get:
4 << 24 = 67108864
0 << 16 = 0
0 << 16 = 0
17 << 0 = 17
Gives us a sum of 67,108,881 that match’s the array size: byte[67108881].
Debugger is showing the maxFrameSize on OpenWireFormat set to 262144, and
this is one of the threads using 64mb mem. But if we dive down into its
command.WireFormatInfo propreties hash, we see the max frame size is wrong.
If we dump out all the properties of the OpenWireFormat for this one thread
they read as:
KEY |Value
----------------------------------------------------
CacheSize |1024
SizePrefixDisabled |false
TcpNoDelayEnabled |true
StackTraceEnabled |true
CacheEnabled |true
MaxFrameSize |9223372036854775807
TightEncodingEnabled |true
MaxInactivityDuration |30000
MaxInactivityDurationInitalDelay|10000
----------------------------------------------------
Note, this occurs only when one of the node become the new broker.
How can we make sure all the openwire settings are correctly negotiated
between client and broker?
--
View this message in context:
http://activemq.2283324.n4.nabble.com/MaxFrameSize-not-honored-and-allowing-64MB-messages-to-go-through-tp4715094.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
