Unsuccessfu Low Level Call on Post

Hi all,
I’m having an issue when calling Elastic from a dotnet core web api application. Below is my setup, description of the issue, and debug information.

My Setup

  • Web api built with dotnet core 2.1
  • Class library encapsulating all my NEST logic
  • Testing Console application
  • Both the web api and the testing console are using the class library’s repository to make the call to elastic.
  • I can run the web api service either locally or locally in a docker container (ubuntu)
  • Elasticsearch is running locally, shield is installed with an AD and naitive realm.
  • All my stuff is using the runas header and both the console app and web api are using the same bind and runas user.

When I execute a query from my console application, I get success and results.
When I do the same via the web api I get the following error: “Unsuccessful low level call on POST: /storeinventory/doc/_search”.

The odd part is I’m constructing my query with a builder method (used both for the console and web api), when I take the failing query I built from the web api call and paste it into kibana, it succeeds.
I’ve tested with curl locally using http://localhost:9200 as well as a host name http://mysearch.example.com:9200 (which is configured in my host file) it works on both.

So in short, It appears like making a query from my web api fails, even though the query it builds works in kibana. However it works perfectly from my console application.
I’m not sure what I’m missing and will happily entertain all ideas.

Debug info below
"Unsuccessful low level call on POST: /storeinventory/doc/_search\r\n# Audit trail of this API call:\r\n - [1] BadRequest: Node: http://elasticsearch.example.com:9200/ Took: 00:00:01.3970177\r\n#
OriginalException: System.Net.Http.HttpRequestException: No connection could be made because the target machine actively refused it ---> System.Net.Sockets.SocketException:
No connection could be made because the target machine actively refused it\r\n at System.Net.Http.ConnectHelper.ConnectAsync(String host, Int32 port, CancellationToken cancellationToken)\r\n
--- End of inner exception stack trace ---\r\n at System.Net.Http.ConnectHelper.ConnectAsync(String host, Int32 port, CancellationToken cancellationToken)\r\n at
System.Threading.Tasks.ValueTask1.get_Result()\r\n at System.Net.Http.HttpConnectionPool.CreateConnectionAsync(HttpRequestMessage request, CancellationToken cancellationToken)\r\n at System.Threading.Tasks.ValueTask1.get_Result()\r\n at System.Net.Http.HttpConnectionPool.WaitForCreatedConnectionAsync(ValueTask1 creationTask)\r\n at System.Threading.Tasks.ValueTask1.get_Result()\r\n
at System.Net.Http.HttpConnectionPool.SendWithRetryAsync(HttpRequestMessage request, Boolean doRequestAuth, CancellationToken cancellationToken)\r\n at System.Net.Http.RedirectHandler.SendAsync(HttpRequestMessage request,
CancellationToken cancellationToken)\r\n at System.Net.Http.HttpClient.FinishSendAsyncBuffered(Task`1 sendTask, HttpRequestMessage request, CancellationTokenSource cts, Boolean disposeCts)\r\n at
Elasticsearch.Net.HttpConnection.Request[TResponse](RequestData requestData)\r\n# Request:\r\n{"from":0,"size":10,"query":{"query_string":{"query":"whiskey"}},"highlight":{"fields":{"itemname":{},
"itemlocation":{}}},"aggs":{"source": {"terms": { "field": "_index"}},"Avg_Quantity": {"avg": { "field": "quantity"}}}}\r\n# Response:\r\n\r\n"

And, here is how I’m making the call using the ElasticLowLevelClient
var searchResponse = lowlevelClient.Search(_index, "doc", PostData.String(qJson));

and here is the body of my post for the query, built by my web api application, which works in Kibana
"from": 0,
"size": 10,
"query": {
"query_string": {
"query": "whiskey"
"highlight": {
"fields": {
"itemname": {},
"itemlocation": {}
"aggs": {
"source": {
"terms": {
"field": "_index"
"Avg_Quantity": {
"avg": {
"field": "quantity"

Ok, so I found the fix.

My node url was http://localhost:9200. This works in the console application, but does not work in the webapi project. I changed it to and it worked.

For the record (in case someone is looking at this in the future and is like, “but this doesn’t fix my problem!” – spin up fiddler (or a similar app) and watch the traffic. The error message there was more descriptive. It told me that the error was a timeout. This is a lot more helpful than the error the lowlevelclient returned. Granted that alone didn’t solve my problem, but it made me reevaluate the situation, do a bit more googling and find someone complaining about curl translating localhost to IPv6 and using instead.

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.