Получение запроса запроса ответа с клиентом 2.X NEST

Question

Я использую новый клиент 2.X NEST. Эта часть важна, потому что было много изменений, которые будут влиять на потенциальные ответы здесь.

Раньше я использовал плагин Glimpse Elasticsearch, чтобы увидеть базовые запросы, генерируемые NEST. Однако, похоже, что этот плагин больше не совместим с 2.X NEST. В результате я пытаюсь найти обходной путь, чтобы увидеть запрос JSON. Проблема здесь в том, что старый способ доступа к response.RequestInformation, чтобы попасть в тело запроса, исчез. Кажется, что он был заменен на комбинацию ApiCall, CallDetails и DebugInformation. Проблема заключается в том, что во всех этих случаях массив байтов запроса равен null, если вы не добавите .DisableDirectStreaming() в экземпляр ConnectionSettings, который вы передадите в ElasticClient. Проблема в том, что я обрабатываю все, что использует инъекцию зависимостей с Ninject, поэтому в чем-то вроде действия контроллера у меня нет доступа к экземпляру ConnectionSettings, чтобы сделать такое изменение. Полагаю, я мог бы просто добавить .DisableDirectStreaming() во всем мире, но я не знаю, каковы потенциальные последствия этого, и документация по этому поводу расстраивает.

Итак, есть несколько путей для ответа здесь, любой из которых я приму. Во-первых, если кому-то удалось получить плагин Glimpse, работающий с 2.X, мне бы хотелось узнать, что вы сделали. Однако, исходя из того, что базовый API сильно изменился, я полагаю, что плагин принципиально нарушен, пока кто-то не разветвит его на 2.X, или Elastic выходит со своей собственной версией (которая, предположительно, наступает в какой-то неопределенной точке в будущее).

Во-вторых, если есть какой-то способ получить тело запроса без отключения прямой потоковой передачи, и я просто пропустил его. Я был бы признателен за руководство.

В-третьих, если у кого есть какие-либо идеи о том, как я могу отключить прямой потоковой передачи на уровне действия контроллера, не затрагивая мою установку Ninject или ее применения во всем мире, не стесняйтесь звонить в.

Наконец, было бы здорово если кто-то из команды Elastic может рассказать мне о последствиях отключения прямой потоковой передачи и о том, какие потенциальные проблемы могут возникнуть из-за этого, я могу принять решение о том, было бы разумно применять его глобально или нет.

Answer 1

С .DisableDirectStreaming() установлено значение true, байты запроса и байты ответов буферизуются в потоках памяти, чтобы они могли быть доступны в ответ через response.RequestBodyInBytes и response.ResponseBodyInBytes соответственно.

По умолчанию установлено значение false, поэтому тип запроса, например. SearchDescriptor<T>, SearchRequest<T> и т. Д. Сериализуется непосредственно в потоке запроса HTTP-запроса, и аналогичным образом тип ответа десериализуется из потока ответов. Таким образом, накладные расходы, связанные с установлением истины, сохраняют байты запросов и ответов в памяти на протяжении всего времени ответа (и GC-ногами).

С настройками подключения лучше всего иметь один экземпляр для срока службы приложения; Параметры сериализации кэшируются для каждого параметра подключения, а также кэши для выражений полей и свойств. В настоящее время нет возможности хранить байты запросов и ответов вокруг каждого запроса, то есть ad-hoc-интроспекции, но я думаю, что это было бы полезным дополнением; Я добавлю проблему для него :)

Я не слишком лично знаком с интеграцией Glimpse, но я ожидаю, что для работы с NEST 2.x потребуется обновление, из-за некоторых изменений. Просто взглянув на это, изменения выглядят довольно просто.Похоже, это можно сделать без необходимости устанавливать .DisableDirectStreaming() в true, но только хватать байты запроса до того, как они будут записаны в поток запросов.