[prev in list] [next in list] [prev in thread] [next in thread] 

List:       activemq-dev
Subject:    Re: Suggestion for improvement on ActiveMQ socket buffer sizing.
From:       Paul Gale <paul.n.gale () gmail ! com>
Date:       2016-01-13 23:36:39
Message-ID: CAJ5znhsUwAHZi1bFex6N_E-9TEfrstc0Yphq1a9zh=Ekyvd4Vw () mail ! gmail ! com
[Download RAW message or body]


Rob,

Also, can you think of a reason why the ioBufferSize on the TCP transport
connector should not default to being the same size as the prevailing
socket buffer size when this flag is true?

​Regardless of the inclusion of this flag I don't understand why one would
choose to make the ioBufferSize smaller than socketBufferSize. Can someone
explain that one?

Incidentally the resultant behavior of the TCP transport when the
ioBufferSize is configured to be _larger_ than the socket's buffer size
(accidentally or otherwise) is not defined.
​

Thanks,
Paul

On Tue, Jan 12, 2016 at 3:53 PM, Rob Davies <rajdavies@gmail.com> wrote:

>
> > On 12 Jan 2016, at 12:56, Paul Gale <paul.n.gale@gmail.com> wrote:
> >
> > Hi,
> >
> > I would like to get some feedback on an idea I have for an improvement to
> > ActiveMQ.
> >
> > Currently ActiveMQ programmatically sizes the receive and send socket
> > buffer sizes for the TCP transport according to the transport connector
> > option transport.SocketBufferSize. The default is 64K.
> >
> > On Linux, however, once an application explicitly sets the size of a
> > socket's buffers (via a call to setsockopt) the automatic tuning (owing
> to
> > prevailing conditions) of a socket's buffers sizes is disabled.
> >
> > Therefore I am proposing the inclusion of a Boolean flag on the transport
> > connector to disable explicit socket buffer sizing by the broker. The
> > default would be false for backward compatibility.
> >
> > When this flag is true the kernel parameters net.ipv4.tcp_rmem and
> > net.ipv4.tcp_wmem would govern how each socket's buffers would be
> > dynamically sized at run-time.
> >
> > ​Thoughts?​
> >
> > ​I am happy to create a JIRA ticket for it and supply the relevant patch​
> > ​ if the community approves.
>
> Great suggestion! Jira ticket is always best - thank you for contributing
> to ActiveMQ
>
> Rob
>
> > ​
> >
> > Thanks,
> > Paul
>
>


[prev in list] [next in list] [prev in thread] [next in thread]