qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Kennedy <andrewinternatio...@gmail.com>
Subject Re: How to handle large messages in Qpid Java client
Date Thu, 02 Dec 2010 15:53:46 GMT
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?


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):

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 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 <
> marnie.mccormack@googlemail.com> 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  
>> <glahiru@gmail.com
>>> 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  
>>> <glahiru@gmail.com
>>>> 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 <
>>>> andrewinternational@gmail.com> 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" <
>>> marnie.mccormack@googlemail.com
>>>>> 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 <
>> glahiru@gmail.com
>>>>>> 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:dev-subscribe@qpid.apache.org

View raw message