ViewQuery with multiple keys leads to WebException/HttpRequestException

.NET SDK
,
1

Hi,

We’re using the latest .Net SDK v2.4.8 and server-side 4.6.1-3652 Enterprise Edition.

I need to query a view with multiple keys (range not possible, I need to specifiy the single keys). Doing so with a couple of keys works fine. However with many keys (in my case 380) this exception occurs:

"InnerExceptions": [{
		"ClassName": "System.Net.Http.HttpRequestException",
		"Message": "An error occurred while sending the request.",
		"Data": null,
		"InnerException": {
			"ClassName": "System.Net.WebException",
			"Message": "The underlying connection was closed: An unexpected error occurred on a receive.",
			"Data": null,
			"InnerException": {
				"ClassName": "System.IO.IOException",
				"Message": "Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.",
				"Data": null,
				"InnerException": {
					"NativeErrorCode": 10054,
					"ClassName": "System.Net.Sockets.SocketException",
					"Message": "An existing connection was forcibly closed by the remote host",
					"Data": null,
					"InnerException": null,
					"HelpURL": null,
					"StackTraceString": "   at System.Net.Sockets.Socket.EndReceive(IAsyncResult asyncResult)\r\n   at System.Net.Sockets.NetworkStream.EndRead(IAsyncResult asyncResult)",
					"RemoteStackTraceString": null,
					"RemoteStackIndex": 0,
					"ExceptionMethod": "8\nEndReceive\nSystem, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089\nSystem.Net.Sockets.Socket\nInt32 EndReceive(System.IAsyncResult)",
					"HResult": -2147467259,
					"Source": "System",
					"WatsonBuckets": null
				},
				"HelpURL": null,
				"StackTraceString": "   at System.Net.Sockets.NetworkStream.EndRead(IAsyncResult asyncResult)\r\n   at System.Net.Connection.ReadCallback(IAsyncResult asyncResult)",
				"RemoteStackTraceString": null,
				"RemoteStackIndex": 0,
				"ExceptionMethod": "8\nEndRead\nSystem, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089\nSystem.Net.Sockets.NetworkStream\nInt32 EndRead(System.IAsyncResult)",
				"HResult": -2146232800,
				"Source": "System",
				"WatsonBuckets": null
			},
			"HelpURL": null,
			"StackTraceString": "   at System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult)\r\n   at System.Net.Http.HttpClientHandler.GetResponseCallback(IAsyncResult ar)",
			"RemoteStackTraceString": null,
			"RemoteStackIndex": 0,
			"ExceptionMethod": "8\nEndGetResponse\nSystem, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089\nSystem.Net.HttpWebRequest\nSystem.Net.WebResponse EndGetResponse(System.IAsyncResult)",
			"HResult": -2146233079,
			"Source": "System",
			"WatsonBuckets": null
		},
		"HelpURL": null,
		"StackTraceString": "   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)\r\n   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n   at System.Net.Http.HttpClient.<FinishSendAsync>d__58.MoveNext()\r\n--- End of stack trace from previous location where exception was thrown ---\r\n   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)\r\n   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n   at Couchbase.Views.ViewClient.<ExecuteAsync>d__2`1.MoveNext()",
		"RemoteStackTraceString": null,
		"RemoteStackIndex": 0,
		"ExceptionMethod": "8\nThrowForNonSuccess\nmscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089\nSystem.Runtime.CompilerServices.TaskAwaiter\nVoid ThrowForNonSuccess(System.Threading.Tasks.Task)",
		"HResult": -2146233079,
		"Source": "mscorlib",
		"WatsonBuckets": null
	}

This topic seems to describe the same problem. Unfortunately it’s from 2015 and there’s no solution posted. Therefore I created a new topic.

There’s another one for the java client which had the same problem. Obviously they solved it.

Judging from the comments I suspect it has something to do with the query beeing sent with GET, which has a limit of 2048 characters. Using POST would solve the problem.

Is it a known bug?
Is there any workaround?

Kind Regards,
Michael

2

@zagel -

I believe you are correct here in that he max size of the querystring is hit; the good news is that we have a ticket for fixing this in the next release (likely 2.5.1).

-Jeff

3

OK. Good to hear that.

Is there any workaraound I can use until the problem is fixed?

4

@zagel -

The work-around would be to partition the requests using a smaller number of keys. If you take this route, I would use the async API and send them concurrently.

-Jeff