Reputation: 5393
Context:
I have an n-tier dynamic-ish application that currently builds its elastic indexes at app startup.
While this was ok to get things going, I'd prefer to have a small CLI application/util that I can later re-use in some scripts and or run ad-hoc if I need to do things like, creating a new instance, seeding mock data etc.
Problem:
When I use the exact same code that worked in my dotnetcore web app's startup, in my console app, I get the following issue:
Invalid NEST response built from a unsuccessful low level call on PUT: /jobs-ng
# Audit trail of this API call:
- [1] BadRequest: Node: https://localhost:9200/ Took: 00:00:01.3948230
# OriginalException: System.Net.Http.HttpRequestException: An error occurred while sending the request. ---> System.Net.Http.CurlException: SSL connect error
at System.Net.Http.CurlHandler.ThrowIfCURLEError(CURLcode error)
at System.Net.Http.CurlHandler.MultiAgent.FinishRequest(StrongToWeakReference`1 easyWrapper, CURLcode messageResult)
--- End of inner exception stack trace ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task)
at System.Runtime.CompilerServices.ConfiguredTaskAwaitable`1.ConfiguredTaskAwaiter.GetResult()
at System.Net.Http.HttpClient.<FinishSendAsyncBuffered>d__58.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task)
at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
at Elasticsearch.Net.HttpConnection.Request[TReturn](RequestData requestData) in C:\Users\russ\source\elasticsearch-net-5.x\src\Elasticsearch.Net\Connection\HttpConnection-CoreFx.cs:line 78
# Request:
<Request stream not captured or already read to completion by serializer. Set DisableDirectStreaming() on ConnectionSettings to force it to be set on the response.>
# Response:
<Response stream not captured or already read to completion by serializer. Set DisableDirectStreaming() on ConnectionSettings to force it to be set on the response.>
Additional Info:
Currently my ElasticClient
class only gets set like this:
var uri = new Uri("https://localhost:9200");
services.AddSingleton(new ElasticClient(new ConnectionSettings(uri)));
... thus I don't explicitly set a cert anywhere. (Hasn't been required thus far)
My best guess is that the native console app is missing something that the default web app projects provide, but as to what, I don't know?
I have set DisableDirectStreaming()
as per the error log, but still no change.
I believe this might be a bug within .Net Core, but I'm hoping someone knows of a work around, or way around this issue for the time being (other that having this code be part of the we apps startup? (which is what my current working solution is))
Upvotes: 2
Views: 2423
Reputation: 5393
There is currently a documented issue, within the dotnet-core project's CURL implementation/usage thereof/within CURL on OSX... you get the idea. It seems to have been fixed for 1.1, but as I'm on 2.0 (and I've attempted all of the suggested fixes on the various github threads, to no success), I'm unable to verify if that fix works.
Thus the answer:
There is a bug thats preventing this from working on OSX currently.
Workaround:
Since my console app / cli-tool will run ad hoc internal to our applications network / same machine instance, I don't, in theory need HTTPS for this utility, HTTP should be sufficient. (Once I made that change, the code worked fine across the board)
Upvotes: 2