.NET client hangs on client create

Have you tried the logging assemblies packaged at http://www.couchbase.com/develop/net/current - "Logging Assemblies" link on right sidebar (direct link below too).

The client should certainly timeout before 10 hours. Could you try logging with these signed assemblies and share the results?

http://packages.couchbase.com/clients/net/1.1/Couchbase-Net-Client-Loggi...?

Actually, I don't know if I've tried those. I tried a number of things before posting. I see there are some fresh posts and publishes regarding logging assemblies since Saturday. I'll give one (or all) of them a try and post again.

Here's a log output from the problem I mentioned (c# .net client just hangs forever in the constructor call). anything apparently wrong here?

2012-06-22 16:01:24.8647|DEBUG|Couchbase.MessageStreamListener|Starting the listener. Queue=True
2012-06-22 16:01:24.8647|DEBUG|Couchbase.MessageStreamListener|Started working.
2012-06-22 16:01:24.8757|DEBUG|Couchbase.MessageStreamListener|Looking for the first working node.
2012-06-22 16:01:24.9777|DEBUG|Couchbase.ConfigHelper|Found config for bucket default.
2012-06-22 16:01:24.9777|DEBUG|Couchbase.MessageStreamListener|Resolved pool url http://127.0.0.1:8091/pools to http://127.0.0.1:8091/pools/default/bucketsStreaming/default
2012-06-22 16:01:24.9777|DEBUG|Couchbase.MessageStreamListener|Start receiving messages.
2012-06-22 16:01:34.9973|DEBUG|Couchbase.MessageStreamListener|HB: Pinging current node 'http://127.0.0.1:8091/pools' to check if it's still alive.
2012-06-22 16:01:34.9973|DEBUG|Couchbase.MessageStreamListener|HB: Trying 'http://127.0.0.1:8091/pools'
2012-06-22 16:01:34.9973|DEBUG|Couchbase.MessageStreamListener|HB: Node 'http://127.0.0.1:8091/pools' is OK
2012-06-22 16:01:44.9979|DEBUG|Couchbase.MessageStreamListener|HB: Pinging current node 'http://127.0.0.1:8091/pools' to check if it's still alive.
2012-06-22 16:01:44.9979|DEBUG|Couchbase.MessageStreamListener|HB: Trying 'http://127.0.0.1:8091/pools'
2012-06-22 16:01:44.9979|DEBUG|Couchbase.MessageStreamListener|HB: Node 'http://127.0.0.1:8091/pools' is OK
2012-06-22 16:01:55.0114|DEBUG|Couchbase.MessageStreamListener|HB: Pinging current

And then it repeats the repetitive part as long as I let it.

The repeated code is actually on a separate thread, so it shouldn't be blocking your main thread (i.e., client). It's checking to see the health of the configuration node. I don't see any calls being made to store/get from the server in the log.

Just to confirm, you're using this tutorial? http://www.couchbase.com/docs/couchbase-sdk-net-1.1/getting-started-hell...

Hi John,

Actually that log was produced from the tutorial here: http://www.couchbase.com/develop/net/current
However, I've also done the tutorial you cited with the same results. This is the minimum code it takes to replicate the problem I'm having:

static void Main(string[] args)
{
using (var client = new CouchbaseClient())
{
}
}

The instantiation of the CouchbaseClient never completes. And I let it sit for days once. If I supply bad parameters, like misspelling the URI, it completes instantly.

Java clients aren't experiencing this issue. I haven't tried another .NET language yet.

I recognized those repetitious messages as heartbeats and they work as expected (as in I can control their frequency in the config file).

Any ideas how best to diagnose this?

In my testing, I saw the same exact behavior... Putting the client new statement into a using statement causes it to fail after the execution of code. I was able to open the connection, use it a few times and then saw it hang.. Works perfectly without the using statement.

My problems persists whether I have a using statement or not.

My problem appears to be a conflict with other software, presumably something like an anti-virus.

I have been able to instantiate the client on a fresh out of the box Windows 7 machine. Adding on AVG anti-virus caused the problem to re-occur. Turning off (but not uninstalling) AVG made the problem go away. More specifically, AVG only needs to be off during the instantiation of the client. Turning it back on while the applicaiton is running, communicating the server, doesn't cause any issues. Also, it's specifically not the firewall component of AVG, that can be on or off throughout with no change in symptoms.

On three other boxes (W7 32 bit, W7, 64 bit, Windows Server 20008 64 bit) the problem persists even afte turning off firewalls and anti-virus, even uninstalling the antivirus. So there is some, presumably software, conflict I can track down.

And it's specific to the .NET client.

That's really strange about AVG, as that's the anti-virus program I use on top of Windows 7. I have never seen the behavior, but it sounds like a reasonable source of your issues. I've tried to recreate the issue a few times, but no luck so far.

All the clients communicate over the same ports too, so why it's a .NET only problem is truly perplexing. I'll try to think through more about what could cause this behavior.

Okay, after several attempts I found the root cause of the issue. Its AVG. Here is what I am running

Physical Machine = Win7
Virtual Machine Server 2008

I have AVG running on both the VM and the Physical Machine. So, when I disable AVG on both machines It starts working.

Come to find out I had Online-Shield and Surf-Shield Enabled on the physical machine, and this was causing the issue.

There is a bug here though, although I am not quite sure how to fix it. I traced the issue in the code to this
line 376 and line 400 in message stream listener

			this.request = this.requestFactory.GetWebRequest(configUrl, configUrl.GetHashCode().ToString());
			this.response = this.request.GetResponse();
...
while ((line = reader.ReadLine()) != null)

basically, if AVG prevents the response from being returned you get the hang, because the request will wait forever to receive a response.

I opened a ticket on the issue
http://www.couchbase.com/issues/browse/MB-7136