What version are you using? There have been various bug fixes and
improvements with this in later releases, especially 5.12.0 which
introduced OpenWire v11. Since you are using OpenWire v10 I'm assuming you
have an older release so you should try upgrading.
On Fri, Aug 5, 2016 at 11:56 AM, jsuen wrote:
> 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 |3
> MaxInactivityDurationInitalDelay|1
>
>
>
> 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.
>
