Done, https://issues.apache.org/jira/browse/CASSANDRA-1188
It was find_all_by_service_id that was the culprit, and it resolves down to a
multiget_slice on a super column family. The super CF is acting as an index
back into a regular CF, thus I'm providing key, supercolumn name, and getting
bac
Can you open a new ticket, then? Preferably with the thrift code
involved, I'm not sure what find_by_natural_key or find_all_by_service
is translating into. (It looks like just one of those is responsible
for the leak.)
On Sun, Jun 13, 2010 at 12:11 PM, Matthew Conway wrote:
> Pretty sure as th
Pretty sure as the list of file descriptors below shows (at this point the
client has exited, so doubly sure its not open sockets):
# lsof -p `ps ax | grep [C]assandraDaemon | awk '{print $1}'` | awk '{print
$9}' | sort | uniq -c | sort -n | tail -n 5
2
/usr/local/apache-cassandra-2010-06
it goes up by exactly 2000, which is the number of loop iterations
exactly? are you sure this isn't just counting your open sockets?
On Fri, Jun 11, 2010 at 1:53 PM, Matthew Conway wrote:
> Thanks, I just tried apache-cassandra-2010-06-11_12-30-33 (hudson 462) but my
> tests ares still reportin
Thanks, I just tried apache-cassandra-2010-06-11_12-30-33 (hudson 462) but my
tests ares still reporting a leak (though not as bad), I do the following (ruby
tests using cassandra_object/cassandra, but you should be able to get the idea):
should "not leak file descriptors" do
cassa
Fixed in https://issues.apache.org/jira/browse/CASSANDRA-1178
On Thu, Jun 10, 2010 at 9:01 AM, Matt Conway wrote:
> Hi All,
> I'm running a small 4-node cluster with minimal load using
> the 2010-06-08_12-31-16 build from trunk, and its exhausting file
> descriptors pretty quickly (65K in less th
