I’ve been having an issue that began with the update to 1.3.3. When I try to initialize the constructor, it hangs almost all the time. I created a simple test application to test it out, and have verified across two test clusters I setup (with 2 nodes each).
I downloaded the Couchbase .NET SDK source from github and added a test project to it to try tracking down where the issue is occuring, and it looks like it is in
reset.WaitOne() never returns.
I looked at the traffic with fiddler and it looks (to me) like everything is okay:
GET http://:8091/pools/default/bucketsStreaming/syncpuppylocal?bucket_uuid=6f15de18b4417fe24fc907e9dbbf8249 HTTP/1.1
HTTP/1.1 200 OK
Server: Couchbase Server
Date: Sun, 16 Dec 2007 21:49:24 GMT
Content-Type: application/json; charset=utf-8
The test cluster is running the latest version of Couchbase server version: 2.5.0 enterprise edition (build-1059-rel)
Any help would be appreciated!
Digging deeper, I saw that the issue was in
Couchbase.MessageStreamListener.ReadMessages(Uri heartBeatUrl, Uri configUrl). It looks like
this.response = this.request.GetResponse(); (line 395) is what is hanging, then timing out, and throwing an exception.
Also, created as a question on StackExchange at http://stackoverflow.com/questions/21869289/couchbase-net-client-constructor-fails-to-initialize-properly
Hi ajebasingh -
Can you post the exception + stacktrace? Also, what happens when you downgrade to version 1.3.1 of the client?
This shows you how to enable logging: http://docs.couchbase.com/couchbase-sdk-net-1.3/#appendix-configuring-logging
With 1.3.1, no exceptions are thrown, and the store fails. Nothing is logged either (it creates the log file, but it is empty, the log level is set to DEBUG). Also tried it with 1.2.9, same results
With log level set to DEBUG, you should see all kinds of stuff in the file. Did you add this line to your program?
Add that line of code somewhere above where the client gets instantiated. Also, have you tried pinging your cluster directly from a browser or using curl? It could be a network (firewall) issue or something - or perhaps a cluster issue.
Yes - I can get to the cluster via the browser (it’s on the local network, and I also tried with a second cluster on a remote network over a VPN - same results). Also, logging is configured and initialized - I added a log statement of my own in the test app, and it worked fine. Is there a way I can send over my sample solution to you? Don’t know that it will help though - it’s pretty basic and just fails on the constructor as I mentioned.
Have you tried testing it out with a 2 node cluster running v2.5? I’m working on installing 2.2 on my laptop and will try it on localhost as well to see if there is any difference.
Yeah, I can try it out. If you could create jira ticket and attach your project as a zip that would be the best: http://www.couchbase.com/issues/browse/NCBC
I did indeed try it out on a two node cluster running Version: 2.5.0 enterprise edition (build-1059)
I didn’t run into the issue, which makes me think it’s something environment specific. Create the ticket and I’ll check it out!
Done - created NCBC-400, at http://www.couchbase.com/issues/browse/NCBC-400
Also, as I was looking at the response from the server in fiddler, I noticed that there is no json body returned - it only sent the HTTP headers in that final call to bucketStreaming.
"Okay I got it figured out finally and can reproduce it all the time on demand now. It’s fiddler2. If I have fiddler running, then it hangs on the streaming connection (which is to be expected I guess!)
However, when I close fiddler2 and then try running it, it works great and returns from the constructor immediately.
Thanks for your help in resolving this issue, and hope this helps anyone else who has this problem!"
Solution: disable the HTTP proxy, in this case Fiddler.