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?
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)"
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.
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:
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.
@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.