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 <[email protected]> wrote: > > > On 12 Jan 2016, at 12:56, Paul Gale <[email protected]> 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 > >
