使用2.X NEST客户端获取搜索响应的请求正文 [英] Getting the request body of search response with 2.X NEST client

问题描述

我正在使用新的2.X NEST客户端。这个部分很重要，因为有很多突破性的变化会影响这里的潜在答案。

I'm using the new 2.X NEST client. That part is important, because there were a great many breaking changes which will effect potential answers here.

以前，我使用Glimpse Elasticsearch插件来查看正在生成的底层查询由NEST。但是，似乎该插件不再与2.X NEST兼容。因此，我试图找到解决方案来查看JSON查询。这里的问题是，访问 response.RequestInformation 以获取请求体的旧方式已经消失了。似乎已经被 ApiCall ， CallDetails 和 DebugInformation 。这里的问题是，在所有这些中，请求字节数组为null，除非您将 .DisableDirectStreaming（）添加到 ConnectionSettings 您传递到 ElasticClient 的实例。问题在于我正在使用Ninject使用依赖注入来处理所有这些问题，所以在某些控件操作中，我无法访问 ConnectionSettings 实例，更改。我想我可以在全球添加 .DisableDirectStreaming（），但我不知道这是什么潜在的后果，文档在这方面令人沮丧。

Previously, I used the Glimpse Elasticsearch plugin to see the underlying queries being generated by NEST. However, it would appear that that plugin is no longer compatible with 2.X NEST. As a result, I'm trying to find a workaround to see the JSON query. The problem here is that the old way of accessing response.RequestInformation to get at the request body is gone. It seems to have been replaced with a combination of ApiCall, CallDetails, and DebugInformation. The problem here is that in all of these the request byte array is null unless you add .DisableDirectStreaming() to the ConnectionSettings instance you pass into ElasticClient. The problem there is that I'm handling all that using dependency injection with Ninject, so in something like a controller action, I have no access to the ConnectionSettings instance to make such a change. I suppose I could just add .DisableDirectStreaming() globally, but I have no idea what the potential consequences of that is and the documentation on this is frustratingly sparse.

所以，这里有一些答案，其中任何一个我会接受的。首先，如果任何人设法获得与2.X功能的Glimpse插件，我很想知道你做了什么。然而，基于底层API已经发生了巨大的变化，我的假设是，插件基本上被破坏，直到有人分支为2.X或弹性出来，自己的版本（据说是在某个不确定的点在未来）。

So, there's a few avenues for an answer here, any of which I'll accept. First, if anyone has manage to get the Glimpse plugin functioning with 2.X, I'd love to know what you did. However, based on the fact that the underlying API has changed dramatically, my assumption is that the plugin is fundamentally broken until someone branches it for 2.X or Elastic comes out with their own version (which is supposedly coming at some undetermined point in the future).

其次，如果有一些方法来获取请求体，而不会禁用直接流式传输，我只是错过了。我会很感激您的指导。

Second, if there's some way to get at the request body without disabling direct streaming, and I simply missed it. I'd appreciate guidance there.

第三，如果任何人有任何想法，我可以如何在控制器操作级别禁用直接流媒体，而不影响我的Ninject设置或应用它在全球范围内，您可以随时随地进入。

Third, if anyone has any ideas for how I can disable direct streaming at the controller action level, without affecting my Ninject setup or applying it globally, feel free to chime in.

最后，如果弹性团队中的人能够启发我禁用直接流媒体的影响，以及潜在的问题可能会如何因此，我可以确定在全球范围内应用是否明智。

Finally, it would be great if someone from the Elastic team can enlighten me to the effects of disabling direct streaming and what potential problems can arise from that, so I can make a determination about whether it would be wise to apply it globally or not.

推荐答案

code> .DisableDirectStreaming（）设置为true，请求字节和响应字节缓冲在内存流中，以使其能够通过 response.RequestBodyInBytes在响应中可用和 response.ResponseBodyInBytes 。

With .DisableDirectStreaming() set to true, the request bytes and response bytes are buffered in memory streams to enable them to be available on the response via response.RequestBodyInBytes and response.ResponseBodyInBytes, respectively.

默认情况下，它设置为false，因此请求类型例如 SearchDescriptor< T> ， SearchRequest< T> 等被直接序列化到http请求的请求流，类似地，响应类型从响应流反序列化。因此，将其设置为true的开销因此在响应的生命周期内保持请求和响应字节（和GC踢进）。

By default, it is set to false so the request type e.g. SearchDescriptor<T>, SearchRequest<T>, etc. is serialized directly to the request stream of the http request and similarly, the response type is deserialized from the response stream. The overhead of setting it to true is therefore keeping the request and response bytes around in memory for the lifetime of the response (and GC kicking in).

使用连接设置，最好在应用程序的一生中有一个实例;每个连接设置缓存序列化设置以及字段和属性表达式的缓存。目前没有办法在每个请求的基础上保留请求和响应字节，即临时内省，但我认为这将是一个有用的补充;我会为此添加一个问题：）

With Connection Settings, it's best to have one instance for the lifetime of the application; Serialization settings are cached per connection settings as well as caches for field and property expressions. There's no way currently to keep the request and response bytes around on a per request basis i.e. ad-hoc introspection, but I think this would be a useful addition; I'll add an issue for it :)

我不太熟悉Glimpse整合，但我希望它需要更新才能使用NEST 2。 x因为一些变化。简单来说，这些变化看起来很简单。看起来这样可以完成，而不必将 .DisableDirectStreaming（）设置为true，但只有在请求字节写入请求流之前才能抓取。

I'm not personally overly familiar with the Glimpse integration but I would expect it would require updating to work with NEST 2.x because of some of the changes. Having just given it a brief look, the changes look pretty straightforward. Looks like this can be done without having to set .DisableDirectStreaming() to true, but only grabbing the request bytes before they're written to the request stream.

这篇关于使用2.X NEST客户端获取搜索响应的请求正文的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！