[
https://issues.apache.org/jira/browse/CASSANDRA-6206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800746#comment-13800746
]
Nenad Merdanovic commented on CASSANDRA-6206:
---------------------------------------------
Although I saw no benefit of doing this, as it doesn't relate to the
application's way of handling connections, but to the socket limits that are
handled in-kernel, I have tried to change the RPC server type to 'hsha'. It
didn't help.
Socket limits are set with the listen(2) system call and Java's implementation
sets it to '50' if not specified. This is way too low on any production traffic
that is not using connection pooling (for example PDO-Cassandra doesn't support
it at all). To patch this should be extremely simple and I kindly ask you to
reconsider about fixing this.
> Thrift socket listen backlog
> ----------------------------
>
> Key: CASSANDRA-6206
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6206
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Debian Linux, Java 7
> Reporter: Nenad Merdanovic
> Fix For: 2.0.1
>
> Attachments: cassandra.patch
>
>
> Although Thrift is a depreciated method of accessing Cassandra, default
> backlog is way too low on that socket. It shouldn't be a problem to implement
> it and I am including a POC patch for this (sorry, really low on time with
> limited Java knowledge so just to give an idea).
> This is an old report which was never addressed and the bug remains till this
> day, except in my case I have a much larger scale application with 3rd party
> software which I cannot modify to include connection pooling:
> https://issues.apache.org/jira/browse/CASSANDRA-1663
> There is also a pending change in the Thrift itself which Cassandra should be
> able to use for parts using TServerSocket (SSL):
> https://issues.apache.org/jira/browse/THRIFT-1868
--
This message was sent by Atlassian JIRA
(v6.1#6144)
