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
This is surely related to some changes in
spymemcached2.8+couchbase1.0.1 as I had no issue with spymemcached
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.
|Status||Open [ 1 ]||Closed [ 6 ]|
|Resolution||Fixed [ 1 ]|
|Workflow||jira [ 16218 ]||Couchbase SDK Workflow [ 38304 ]|