Mailing-List: contact users-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@activemq.apache.org
MIME-Version: 1.0
In-Reply-To: <1472057913407-4715794.post@n4.nabble.com>
References: <1472057913407-4715794.post@n4.nabble.com>
From: Christopher Shannon <christopher.l.shannon@gmail.com>
Date: Thu, 25 Aug 2016 12:08:27 -0400
Message-ID: <CACHnxzyKQwpc83tmSqW+Sbrm-fuvPTOCPncm-2b=Vuh4Hovf_Q@mail.gmail.com>
Subject: Re: [ActiveMQ 5.11.1] Question around WireFormat byte array size
To: users@activemq.apache.org
Content-Type: multipart/alternative; boundary=001a1143f52c80fa74053ae79d91
archived-at: Thu, 25 Aug 2016 16:09:12 -0000

--001a1143f52c80fa74053ae79d91
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

What happens if you turn off caching for the wireFormat by setting
wireFormat.cacheEnabled=3Dfalse ?

On Wed, Aug 24, 2016 at 12:58 PM, mmacpherson <mmacpherson@blackberry.com>
wrote:

> Hello,
>
> This was posted as a sub question to a thread in the Dev forum, but as I =
am
> really struggling to understand where this setting is coming from I thoug=
ht
> I would ask on the more general User group. Maybe someone has run into th=
is
> =3D)
>
> Other form thread subject (MaxFrameSize not honored and allowing 64MB
> messages to go through)
>
> Basic info, ActiveMQ 5.11 .1 (we have plans to test with 5.14), and we ar=
e
> getting some odd results while a node becomes the active broker.
>
> 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 core issue for us appears to be the byte stream is getting parsed wit=
h
> tightEncodingEnabled set to TRUE, but the stream itself is not actually
> formatted in this manner. This takes things on a unexpected path.
>
> My concern is that if we address this, simply but setting
> tightEncodingEnabled to false, I still see some issues with the Byte
> stream.
>
> The Size value being provided before the ActiveMQ Magic bytes and the
> Datatype parameter appears to be a negative value.
>
> byte|[21] |0
> byte|[22] |0
> byte|[23] |0
> byte|[24] |-16
>
> byte|[25] |1
> byte|[26] |65 ->A
> byte|[27] |99 ->c
> byte|[28] |116 ->t
> byte|[29] |105 ->i
> byte|[30] |118 ->v
> byte|[31] |101 ->e
> byte|[32] |77 ->M
> byte|[33] |81 ->Q
>
> And then after this, if its parsed correctly, after the Magic bytes and
> then
> the Version bytes, the next section is used to control the size of a Byte=
[]
> that=E2=80=99s created. When you do the shifting that size should turn ou=
t to be
> 16777216:
>
> ActiveMQ magic:
> byte|[26] |65 ->A
> byte|[27] |99 ->c
> byte|[28] |116 ->t
> byte|[29] |105 ->i
> byte|[30] |118 ->v
> byte|[31] |101 ->e
> byte|[32] |77 ->M
> byte|[33] |81 ->Q
> Version (10)
> byte|[34] |0
> byte|[35] |0
> byte|[36] |0
> byte|[37] |10
> Byte array size (16777216)
> byte|[38] |1
> byte|[39] |0
> byte|[40] |0
> byte|[41] |0
>
> Is anyone aware of a setting we are missing? We use the
> ActiveMQSslConnectionFactory and pass the following params in currently:
>
> initialReconnectDelay=3D10
> maxReconnectDelay=3D30000
> maxReconnectAttempts=3D10
> startupMaxReconnectAttempts=3D1
> timeout=3D60000
> randomize=3Dfalse
> useExponentialBackOff=3Dtrue
> priorityBackup=3Dtrue
> jms.useAsyncSend=3Dtrue
> nested.soTimeout=3D60000
> nested.soWriteTimeout=3D60000
> nested.wireFormat.maxFrameSize=3D262144
>
> Matt
>
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.
> nabble.com/ActiveMQ-5-11-1-Question-around-WireFormat-
> byte-array-size-tp4715794.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>

--001a1143f52c80fa74053ae79d91--