I have only seen the cbc hash command line tool do this. I’d like to use it to add to our internal metrics to detect failures
Generally speaking, that’s the SDK’s job. If you’re looking for metrics on this, you can probably get it from the REST interface from the cluster. That’s covered in the docs.
Generally, I agree but I’m talking specifically;
We’ve had instances where one application node was unable to reach the couchbase cluster, and one where all of the app nodes cannot read a single node in the cluster.
In both scenarios getting that info and recording our instrumentation to flag up problems so we can deal with it.
Do you know what the process of document key to node resolution is called? All my searches are not yielding the kind of documentation you are hinting at.
Further investigation looks like the internal class CouchbaseRequestExecuter.GetServer can do it but that’s internal
Either @jmorris or @MikeGoldsmith can probably identify a way (or help track an improvement request) if there isn’t one. The cluster REST interface does not have a way of doing that hash conversion. The CLI tool cbc hash does, but you’d want to use it carefully since it’ll hash differently depending on what the current topology is.
A simpler thing to do might be to log it and ensure you have INFO and above logging configured anyway. That way you’ll see WARNINGs and ERRORs and can possibly correlate to other events like connections being disrupted/rebuilt or topology changes.
Ok, thanks @ingenthr. I’ll look into hooking into the logging system.
We will have the same issus as with the HttpClient StdLib, parsing log entries via a TraceListener is all rather flaky so any better ideas are welcome.
I don’t know of anything in the client that exposes an API for a consuming application to get the primary (or replica) hosts for a given key, though I can understand the benefits.
A short-term change could be, as Matt suggested, to add a log line in CouchbaseRequestExecutor here that logs the key > server map. I’ve created issue NCBC-1400 to do that log change, we’ll likely have to do it at a low level otherwise we would flood logs.
A larger change would be to expose an API on the client that would provide access to retrieve the primary and replica hosts for a given key. I’ve created NCBC-1401 to track creating a more extensive API to get primary / replica hosts.
@MikeGoldsmith Thanks for that.
re the logging Loading... It would be good enough if the ip address or url was an explicit parameter in the exception/operation result.
We (other may have other requirements) only care in the event of a failure.
Regarding the API for finding the node for a document (Loading...) the CouchbaseRequestExecuter.GetServer looks promising but is internal.
What would be interesting for our scenario is GetFromBucketOrReplica<T> as long as we knew where it came from in the operation response
Thanks
For the logging; I’ve made a note to look at what would be better - logging vs exception parameter.
For the larger improvement; I would expect the API to retrieve the server hostname to be new and not make CouchbaseRequestExecutor public.
Ok, ta. I can do something with the parameter, not so much with the logging.
I’d rather the logging wasn’t there in any client library, hooks for diagnostics is my preference. That might just be me 
@MikeGoldsmith @adam.g.straughan -
I would rather not make the SDK’s public footprint bigger by making CouchbaseRequestExecutor public; instead it would be better if that information was returned back to application via extending IOperationResult. For example:
public interface IOperationResult
{
...
string MappingInfo{get;}
...
}
Or perhaps appending it to the IOperationResult.Message property.
Note that in the end, you’ll only end up with the last node that the operation hit, since the SDK does retries on some operations.
-Jeff