Note: I was going to send this as a reply to Lahiru on qpid-users,
but better judgement prevailed, as I think it would probably not have
the desired effect. Can anyone knowledgeable in the Java broker
confirm this is the way things really work?
Ok,
That 'IoTransport' class is *never* used, unless the system property
'UseTransportIo' has a value other than 'false' and that code path is
not tested (See AMQConnectionDelegate_8_0 lines 91-99). I would *not*
recommend modifying that property, or even trying this, as it is not
included in our test suite and is experimental code. Also, it will be
disappearing in a future release anyway .
In fact, the code will use a 'SocketTransportConnection' object,
which sets up TCP socket receive and send buffer sizes based on
either the system properties 'amqj.sendBufferSize' and
'amqj.receiveBufferSize' or the default, which is 32 kB for both. If
you want to change these, the system properties are the things to use
(on the client side, of course) instead.
Confusingly, on the broker side of things, this is handled by the
'MinaNetworkDriver' class, which uses a default of 262144 bytes for
the send and receive transport buffers. The send buffer size is
changed by setting the '//connector/protectio/writeBufferLimitSize'
element in config.xml, and the receive buffer likewise by changing
the '//connector/protectio/readBufferLimitSize' element.
I am quite surprised that changing constants in IoTransport had any
effect whatsoever, to be honest. Also, note that this has nothing to
do with *Frame* size, which is an AMQP thing. In fact, the broker
itself informs each connection of its maximum framse size. This
changes, depending on whether any SASL authentication mechanisms are
defined, obviously. If there are none, it is hard coded as 65535
bytes, as can be seen in this snippet from ServerDelegate, around
line 70 or so (Note that 'ConnectionBinding' serves only to provide
this constant, no other code is used from this class):
conn.connectionTune(Integer.MAX_VALUE,
org.apache.qpid.transport.network.ConnectionBinding.MAX_FRAME_SIZE,
0, Integer.MAX_VALUE);
If, on the other hand, the connection is secured using SASL, the
*default* maximum frame size is 65536 bytes (note the one byte
difference...) however this can, again, be changed using a config.xml
element, namely the '//advanced/framesize' element.
I am not sure if the above has made things any clearer, sadly, but
that is what the code appears to do... If you feel that there is a
bug somewhere here, please raise a JIRA so that we can track it
properly and fix the behavior.
Andrew.
--
-- andrew d kennedy ? do not fold, bend, spindle, or mutilate ;
-- http://grkvlt.blogspot.com/ ? edinburgh : +44 7582 293 255 ;
On 29 Nov 2010, at 02:54, Lahiru Gunathilake wrote:
Hi Marnie,
In IoSender and IoReceiver classes we are using a ByteBuffer to
read the
write messages, to increase the size of this buffer, I simply
changed a
constant defined in IoTransport.java file, if you look in to those
three
classes, you will get it.
In IoTransport.java I changed the following line of code,
private static int DEFAULT_READ_WRITE_BUFFER_SIZE = 64 * 1024;
but I saw there are some other constants defined with the name of
MAX_FRAME_SIZE but after going through the code i saw they are not
affecting.
I feel there's an issue when we send a large message in to a Queue and
something get currupted, when do framing and send. because when I
keep the
same small frame size for read buffer and increase the size for write
buffer, it worked for 500K messages, but couldn't get it work for
more than
1MB large messages.
Lahiru
Lahiru
On Mon, Nov 29, 2010 at 2:09 AM, Marnie McCormack <
[email protected]> wrote:
Hi Lahiru,
What exactly have you done/set for the frame size change ?
Thanks,
Marnie
On Sun, Nov 28, 2010 at 9:07 AM, Lahiru Gunathilake
<[email protected]
wrote:
Hi all,
I did a mistake when increase the framesize without increasing to
required
size, when I increase the size I was able to read some of the
messages
which
are in the size of 700K, but sometimes it fails.
I kept on increasing the frame-size since in my setup there are
messages
with the size of 1.5M but I couldn't read a any of them though i
increase
the frame-size more.
other than changing in IoTransport.java, do I have to change any
other
constant values to sync the maximum-frame-size ?
Regards
Lahiru
On Sat, Nov 27, 2010 at 10:34 PM, Lahiru Gunathilake
<[email protected]
wrote:
Hi Andrew,
Thanks Andrew for the response.
I have doubled the default frame-size which was (64 * 1024) in
IoTransport.java, but didn't worked for me. FYI, activeMQ works
fine in
this
scenario.
On Sat, Nov 27, 2010 at 10:22 PM, Andrew Kennedy <
[email protected]> wrote:
Hi,
The out of order frames only occur in 0-10 and with transports
that
have
no
concept of sequencing, i.e. in-vm or udp, not tcp. Having said
that, a
frame
body being interpreted as a header would give those symptoms.
I will debug and see.
Regards
Lahiru
Test code that
exercises the issue would be illuminating.
Unsure if this helps?
Andrew.
On 26 Nov 2010 16:56, "Marnie McCormack" <
[email protected]
wrote:
Hi Lahiru,
Robbie mentioned earlier when I asked him about this that he
*thinks*
it's
a
bug Andrew might have come across and possibly fixed to do with
OoO
frames.
Certainly the exception showing that the buffer length is 1 might
support
that.
I haven't had a chance to look about for this - Andrew is not
about
today.
I'll check with him when he's back if you don't get a better reply
here
first.
Rgds,
Marnie
On Fri, Nov 26, 2010 at 3:27 PM, Lahiru Gunathilake <
[email protected]
wrote:
Hi Marnie,
Thanks for your prompt response. yes i tried to wait before
consuming,
and
it wo...
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
