I’m seeing a sporadic error when doing a remove with the message: “Value cannot be null \n Parameter name: dst”. Digging through the source code, I found this parameter in the DefaultConverter.cs class. Any thoughts on why this might be happening?
Patrick Davis
@pdavis -
I suspect its a bug. Can you provide steps to reproduce and create a Jira ticket for tracking? If you have logs, add those as well.
Also, which version of the SDK and Couchbase Server are you using?
-Jeff
Hey @jmorris,
Sorry I’m getting back to you so late on this, but we haven’t actually been able to reproduce this successfully. We’ve been seeing this in our logs after a call to CouchbaseBucket.Remove(). After looking more into the logs, I noticed that the ResponseStatus returned is “ClientFailure” and I was able to retrieve this partial stack trace:
StackTrace : " at System.Buffer.BlockCopy(Array src, Int32 srcOffset, Array dst, Int32 dstOffset, Int32 count) at Couchbase.IO.Connection.Send(Byte[] buffer) at Couchbase.IO.Strategies.DefaultIOStrategy.Execute[T](IOperation1 operation, IConnection connection) at Couchbase.Authentication.SASL.CramMd5Mechanism.Authenticate(IConnection connection, String username, String password) at Couchbase.Authentication.SASL.CramMd5Mechanism.Authenticate(IConnection connection) at Couchbase.IO.Strategies.DefaultIOStrategy.Authenticate(IConnection connection) at Couchbase.IO.Strategies.DefaultIOStrategy.Execute(IOperation operation)"
@jmorris -
Ah, sorry, it’s the .NET sdk version 2.2.2
@pdavis -
I think it might be a bug fixed around v2.2.2, try upgrading to a later version and see what happens.
-Jeff
Update: we updated the SDK version up to 2.2.7 and we’re still seeing the error.
-Patrick
@pdavis -
I created a Jira ticket for tracking: Loading...
Can you provide steps to reproduce or any other information that may help us to resolve it?
Thanks,
Jeff
I’m still not able to reproduce this. It’s a sporadic error that only pops up in our logs and does not seem to affect our application (at least as far as we can tell). The error is much more frequent when there is a lot of load on the application, but that’s most likely a correlation and not causation. Sorry for the lack of information, this is all I’ve been able to find.
Thanks,
Patrick
Based on the exception and stack trace, I’ve come up with a possible explanation for your error. If a connection in the connection pool had trouble shutting down, it might fail to release its buffer back to the buffer pool. Later, when the connection pool scaled back up to its maximum size, there would be insufficient available buffers for the number of connections.
I’ve submitted a change which will hopefully fix this issue. At the very least, it will trap it before it gets to the somewhat confusing exception you were seeing earlier, and make it easier to diagnose. You can watch the change here:
http://review.couchbase.org/#/c/63214/
Thanks,
Brant
Thanks for the (hopeful) fix! Just noticed it got merged into master. Any idea when this will be released?
Thanks again,
Patrick
Unfortunately I’m not sure what the current release schedule for the SDK is looking like. Hopefully @jmorris will be able to answer your question.
Brant
Perfect, thank you!
@jmorris, @btburnett3 Thanks for getting this out.
We did notice the following line:
https://github.com/couchbase/couchbase-net-client/blob/master/Src/Couchbase/IO/Connection.cs#L332
Which only includes the destructor in #DEBUG mode… Should this be included for all cases?
Or, was this just included to highlight any misses of Dispose() during development?
The latter, just to highlight misses during development. There are various reasons why finalizers are avoided, @jmorris knows more of the details. I know that one is that exceptions in a finalizer will crash the whole process.
Brant
@unhuman - yes, the finalizers are only in place to track if a dispose was not called properly while developing and testing. As @btburnett3 mentioned, if an exception is thrown within a finalizer the entire host process will crash…since finalization is non-deterministic, objects that you expect to be in scope may have already been reclaimed, etc.
Also, thanks for the feedback!
-Jeff