[JCBC-19] client can fail to reconnect to the cluster if the place it's currently connected fails

Thu, 5 Apr 2012 20:32:30 -0500

client can fail to reconnect to the cluster if the place it's currently connected fails

[JCBC-16] client can OOM due to a bug in netty

Thu, 5 Apr 2012 20:33:50 -0500

According to the bug reporter, the client can OOM leaking vbucket objects, and those owing (likely) to a bug in Netty.

From the bug reporter:
Using sdk 1.0.1 and couchbase (enterprise) 1.8, my application
(basically a TapClient which runs "dump" method) had OutOfMemory and
"Too many open files" issues.
By dumping memory with jmap, it seemed that jvm memory was full of
VBucket object, also there was a correlation between the number of
VBucket and each tapclient.dump call (each calls brings like 2048 new
elements).

This is surely related to some changes in
spymemcached2.8+couchbase1.0.1 as I had no issue with spymemcached
2.7.3.
It seems that those VBucket where related to CouchbaseConnection
object, which were (at least) referenced in some org.jboss.netty
classes, like org.jboss.netty.channel.AbstractChannel.
I had no time to check in the Netty community, but it seems that
replacing sdk default netty jar with the latest 3.3.1 solves the
issue, as the number of
Vbucket is no longer running up.

Anyone facing the same issue? Is it safe to use this netty version?
Eventually, if this issue is confirmed, it could be time to update the
sdk zip file downloadable by the site.